Các Thực Hành Tốt Nhất về Bảo Mật Claude Code cho Đội Nhóm năm 2026

Cập nhật lần cuối: June 28, 2026

Một tác nhân coding AI có thể đọc repo của bạn, chạy các lệnh shell và gọi các dịch vụ bên ngoài rất hữu ích chính vì nó có phạm vi tiếp cận rộng. Phạm vi tiếp cận đó cũng là rủi ro. Một prompt bị hiểu sai, một allowlist lỏng lẻo, hoặc một máy chủ MCP không đáng tin cậy có thể làm rò rỉ token hoặc xóa một branch. Hướng dẫn này dành cho nhà phát triển hoặc trưởng nhóm nền tảng muốn sử dụng Claude Code trong công việc hàng ngày và trong CI mà không trao chìa khóa sản xuất cho nó.

Câu trả lời nhanh: các đội nhóm giữ an toàn cho Claude Code như thế nào?

Chạy tác nhân với đặc quyền tối thiểu (least privilege) và xem xét những gì nó làm. Trên thực tế, điều đó có nghĩa là năm điều sau:

• Bắt đầu ở chế độ quyền hạn hạn chế và cấp công cụ thông qua một allowlist hẹp, chứ không phải cho phép "luôn luôn" chung chung.
• Giữ bí mật ra khỏi context của model: không dán các key, và quy tắc deny trên .env và các đường dẫn secret.
• Kiểm tra mọi máy chủ MCP trước khi kết nối nó, vì một máy chủ không đáng tin cậy có thể đọc dữ liệu và hành động thay mặt bạn.
• Coi nội dung web được lấy về là input không đáng tin cậy, có thể mang theo các chỉ thị prompt-injection.
• Trong CI, cấp cho tác nhân một token ngắn hạn, giới hạn quyền đọc và không bao giờ để lộ thông tin đăng nhập sản xuất.

Phần còn lại của bài viết này biến mỗi điểm đó thành các cài đặt cụ thể, cùng với bảng rủi ro, tài liệu tham khảo về quyền hạn, và kịch bản CI mà bạn có thể sao chép.

Các chế độ quyền hạn và allowlist hoạt động như thế nào?

Claude Code sẽ hỏi trước khi nó chạy một công cụ lần đầu tiên. Bạn quyết định xem quyết định đó được ghi nhớ, giới hạn phạm vi hay bỏ qua. Chế độ quyền hạn thiết lập mức cơ bản:

• default nhắc nhở khi sử dụng mỗi công cụ hoặc lệnh lần đầu tiên.
• plan chỉ đọc (read-only): tác nhân có thể đọc các tệp và đề xuất một kế hoạch nhưng không thể chỉnh sửa hoặc chạy lệnh. Sử dụng nó để xem xét.
• acceptEdits tự động chấp nhận việc chỉnh sửa tệp nhưng vẫn nhắc nhở đối với các lệnh shell.
• bypassPermissions bỏ qua mọi lời nhắc. Hãy coi nó như chỉ dành cho sandbox.

Các kiểm soát bền vững nằm trong .claude/settings.json dưới mục permissions, với các quy tắc allow, ask, và deny. Các quy tắc được giới hạn phạm vi theo công cụ và mẫu, vì vậy bạn cấp chính xác những gì một tác vụ cần:

{
  "permissions": {
    "allow": ["Read", "Edit", "Bash(npm test:*)", "Bash(git diff:*)"],
    "ask": ["Bash(git push:*)", "WebFetch"],
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(curl:*)", "Bash(rm -rf:*)"]
  }
}

Một quy tắc deny luôn thắng hơn allow, đó là lý do tại sao các đường dẫn secret ở trên vẫn không thể đọc được ngay cả khi có một quy tắc Read rộng. Anthropic tài liệu hóa cú pháp và thứ tự ưu tiên đầy đủ của quy tắc trong identity and access management docs của Claude Code.

Hãy tránh sử dụng --dangerously-skip-permissions bên ngoài một container có thể loại bỏ. Nó loại bỏ điểm kiểm tra thủ công duy nhất giúp phát hiện lỗi rm hoặc cuộc gọi mạng bất ngờ. Nếu bạn muốn tốc độ mà không có rủi ro đó, hãy ưu tiên một allowlist chặt chẽ để các lệnh thường xuyên chạy tự động trong khi mọi thứ mới vẫn tạm dừng để bạn xem xét.

Tài liệu tham khảo về Rủi ro và Giảm thiểu

Hầu hết các sự cố đều bắt nguồn từ một số mẫu nhất định. Hãy ánh xạ từng rủi ro tới một biện pháp kiểm soát trước khi mở rộng tác nhân trên toàn đội nhóm.

Khung này tuân theo OWASP Top 10 for LLM Applications, nơi gọi tên prompt injection, xử lý output không an toàn và tính tự chủ quá mức là các rủi ro tác nhân hàng đầu.

Tài liệu tham khảo về Quyền hạn và Phạm vi

Bảng này là tài liệu cheat sheet tôi đưa cho thành viên mới của đội nhóm. Nó bao gồm các cài đặt thay đổi bán kính thiệt hại (blast radius) của một lần chạy.

Kiểm tra máy chủ MCP trước khi kết nối chúng

Các máy chủ MCP mở rộng tác nhân bằng các công cụ mới: một client cơ sở dữ liệu, tích hợp ticketing, một trình duyệt. Mỗi cái bạn thêm vào là mã có thể đọc context và thực hiện hành động. Một máy chủ không đáng tin cậy là cách nhanh nhất để biến một tác nhân hữu ích thành đường dẫn rò rỉ dữ liệu, vì vậy tiêu chuẩn kết nối nó phải giống như tiêu chuẩn bạn áp dụng cho bất kỳ dependency nào có quyền truy cập mạng.

Trước khi thêm một máy chủ, hãy trả lời năm câu hỏi:

1. Ai xuất bản nó, và nguồn đó có công khai và được duy trì không?
2. Nó yêu cầu những phạm vi gì: chỉ đọc, hay ghi và mạng?
3. Nó có thể thấy dữ liệu nào sau khi kết nối: chỉ repo này, hay toàn bộ máy của bạn?
4. Thông tin đăng nhập có giới hạn phạm vi và ngắn hạn, hay là một token admin dài hạn?
5. Bạn có thể ghim (pin) một phiên bản để việc tự động cập nhật không thể mở rộng quyền truy cập của nó một cách im lặng không?

Hãy kết nối các máy chủ với phạm vi tối thiểu cần thiết để hoàn thành công việc, và giữ các máy chủ có khả năng ghi hoặc liên quan đến sản xuất ra khỏi cấu hình chia sẻ hoặc CI. Để biết cơ chế thiết lập và hướng dẫn chi tiết hơn, hãy xem Claude Code MCP integration guide của chúng tôi. Bài viết Claude Code productivity tips đề cập đến cách giữ dấu chân đó nhỏ mà không làm chậm tốc độ của bạn.

Giữ bí mật ra khỏi tầm với của model

Bí mật sạch nhất là bí mật mà model không bao giờ nhìn thấy. Đừng dán các API key vào prompt, và đừng yêu cầu tác nhân "đọc key từ config và sử dụng nó." Hãy để thông tin đăng nhập tồn tại trong môi trường và tham chiếu chúng bằng tên để giá trị nằm ngoài bản ghi (transcript).

Ba thói quen bao gồm hầu hết rủi ro:

• Thêm quy tắc deny cho .env, *.pem, và bất kỳ thư mục secrets/ nào để tác nhân không thể đọc chúng ngay cả khi vô tình.
• Sử dụng trình quét secret pre-commit (như gitleaks hoặc git secrets) để key bị rò rỉ sẽ thất bại commit, chứ không phải audit.
• Xoay vòng bất cứ thứ gì bị lộ ngay lập tức, sau đó kiểm tra logs và lịch sử. Xoay vòng là cách khắc phục duy nhất thực sự đóng cửa lỗ hổng.

Nếu một key đã đến bản ghi hoặc một commit, hãy giả định nó đã bị xâm phạm và xoay vòng nó. Tìm kiếm lịch sử git bằng git log -S giúp bạn tìm ra nơi nó đã rơi vào.

Kịch bản: kích hoạt Claude Code trong CI mà không có credential sản xuất

Một đội nhóm muốn Claude Code xem xét các pull request trong GitHub Actions. Mục tiêu là bình luận đánh giá tự động, với khả năng bằng 0 để triển khai, ghi vào main, hoặc chạm vào cơ sở dữ liệu sản xuất.

Đây là thiết lập giữ cho công việc hữu ích nhưng bị giới hạn:

• Chạy headless với claude -p ở chế độ plan để tác nhân đọc diff và viết bình luận, nhưng không bao giờ chỉnh sửa tệp hoặc chạy lệnh build.
• Chỉ cấp quyền workflow contents: read và pull-requests: write. Không có job deploy, không phạm vi cơ sở hạ tầng (infrastructure scope).
• Sử dụng GITHUB_TOKEN ngắn hạn của job, chứ không phải token cá nhân, và không bao giờ đặt các key sản xuất database hoặc cloud vào môi trường của job đó.
• Thêm danh sách deny cho các đường dẫn secret và curl đi ra ngoài, để một nỗ lực prompt-injection bên trong diff PR không thể rò rỉ bất cứ thứ gì.
• Ghim phiên bản action và Claude Code, và giới hạn mọi bước deploy đằng sau một môi trường riêng biệt được con người phê duyệt.

permissions:
  contents: read
  pull-requests: write
steps:
  - run: claude -p "Review the diff for security issues" --permission-mode plan
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Job review thấy mã và đăng phản hồi. Nó không thể chạm tới sản xuất vì các credential sản xuất chưa bao giờ nằm trong phạm vi (scope). Claude Code security overview của Anthropic mô tả tư thế đặc quyền tối thiểu này cho các lần chạy tự động và headless.

Bạn không bao giờ nên dán gì vào một tác nhân coding AI?

Một số input không thuộc về bất cứ đâu gần bản ghi, bởi vì bất cứ thứ gì trong context window đều có thể được phản hồi lại, ghi nhật ký hoặc hành động:

• Các API key trực tiếp, URL database kèm mật khẩu, hoặc root credentials cloud.
• PII khách hàng hoặc dữ liệu được quản lý mà bạn sẽ không đưa vào ticket hỗ trợ.
• Private signing keys, certificates, hoặc các tệp .pem.
• Chuỗi kết nối sản xuất đầy đủ khi một read replica hoặc fixture cục bộ là đủ.

Khi tác nhân cần truy cập, hãy cung cấp cho nó đường dẫn đến credential có phạm vi giới hạn thông qua môi trường thay vì bản thân secret. Kết quả tương tự, bán kính thiệt hại nhỏ hơn nhiều.

Kiểm toán, hooks và xem xét liên tục

Đặc quyền tối thiểu đặt ra mức sàn; việc xem xét giữ bạn ở đó. Hãy đọc kế hoạch của tác nhân trước khi phê duyệt một bước rủi ro, và đọc diff trước khi commit. Đối với các thay đổi lớn hơn, kỷ luật tương tự giúp AI-assisted refactoring an toàn cũng áp dụng ở đây: các bước nhỏ, có thể xem xét tốt hơn một lần chạy khổng lồ không giám sát.

Thêm các rào chắn xác định bằng hooks. Một hook PreToolUse có thể kiểm tra một lệnh và chặn nó trước khi nó chạy, đó là cách bạn thực thi các quy tắc mà model không bao giờ được ghi đè, như từ chối bất kỳ thao tác ghi nào vào đường dẫn được bảo vệ. Kết hợp điều đó với một chuỗi kiểm toán để bạn có thể trả lời tác nhân đã làm gì, khi nào và thay mặt ai.

Một checklist định kỳ nhanh cho đội nhóm:

• Xem xét danh sách allow và deny trong .claude/settings.json theo lịch trình, không chỉ lúc thiết lập.
• Kiểm tra lại các máy chủ MCP sau các lần nâng cấp phiên bản lớn.
• Xác nhận rằng các job CI vẫn chạy ở chế độ plan và không mang bí mật sản xuất nào.
• Xoay vòng token theo chu kỳ và sau bất kỳ sự lộ diện nghi ngờ nào.
• Giữ một tệp CLAUDE.md nêu rõ những điều không thể thương lượng: không force-push lên main, không truy cập DB prod trực tiếp, không secret trong prompts.

Đối với quy trình làm việc rộng hơn xung quanh tất cả những điều này, Claude Code ultimate guide hướng dẫn cấu hình từ đầu đến cuối.

Bài học chính

Bảo mật cho các tác nhân coding AI là tư duy đặc quyền tối thiểu tương tự mà bạn đã áp dụng cho service accounts, được viết ra dưới dạng các quy tắc quyền hạn. Bắt đầu với chế độ hạn chế, mở rộng bằng một allowlist hẹp, từ chối các đường dẫn secret, kiểm tra máy chủ MCP như dependencies, coi nội dung được lấy về là không đáng tin cậy, và giữ thông tin đăng nhập sản xuất ra khỏi bất kỳ job nào mà tác nhân có thể tiếp cận. Làm điều đó và Claude Code sẽ vẫn là một cặp tay nhanh nhẹn, chứ không phải một cánh cửa mở.