2026年团队使用的Claude Code安全最佳实践指南

最后更新时间: July 26, 2026

一个能够读取你的 repo、运行 shell 命令并调用外部服务的 AI coding agent，之所以有用，正是因为它拥有广阔的覆盖范围。而这种广阔的覆盖范围，也是风险所在。一次误读的提示词、一个疏忽的白名单设置，或一个不信任的 MCP server 都可能泄露 token 或擦除分支。本指南是为那些希望在日常工作和 CI 中使用 Claude Code，但又不想将生产环境钥匙交给它的开发者或平台负责人准备的。

快速答案：团队如何确保 Claude Code 安全？

以最小权限运行 agent 并审查其行为。实际上这意味着五件事：

• 从限制性权限模式开始，通过狭窄的白名单授予工具，而不是采用“总是允许”的全面授权。
• 将密钥排除在模型的上下文之外：不要粘贴密钥，并在 .env 和 secret 路径上设置 deny 规则。
• 在连接任何 MCP server 之前进行审查，因为不受信任的服务器可以读取数据并代表你执行操作。
• 将获取的网络内容视为不可信输入，它可能携带提示注入指令。
• 在 CI 中，给 agent 一个短期、只读范围的 token，绝不暴露生产凭证。

本文其余部分将把这些点转化为具体的设置、风险表、权限参考和可复制的 CI 场景。

权限模式和白名单实际如何工作？

Claude Code 在首次运行工具之前会询问你。你决定了这次决策是需要被记住、限定范围还是跳过。权限模式设定了基础：

• default 在每次使用每个工具或命令时都会提示。
• plan 是只读的：agent 可以读取文件并提出计划，但不能编辑或运行命令。适用于审查。
• acceptEdits 会自动接受文件编辑，但仍会提示 shell 命令。
• bypassPermissions 跳过所有提示。应将其视为沙盒专用模式。

持久化的控制权位于 .claude/settings.json 的 permissions 下，包含 allow、ask 和 deny 规则。规则按工具和模式限定范围，因此你只授予任务实际需要的权限：

{
  "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:*)"]
  }
}

deny 规则总是优先于 allow，这就是为什么上述的 secret paths 即使存在广泛的 Read 规则也无法被读取。Anthropic 在 Claude Code identity and access management docs 中记录了完整的规则语法和优先级。

避免在可丢弃的容器之外使用 --dangerously-skip-permissions。它移除了唯一能捕获到错误的 rm 或意外网络调用的人工检查点。如果你想要速度但又不想承担这种风险，最好采用严格的白名单机制，这样日常命令可以无人值守运行，而任何新事物仍然会暂停等待你的确认。

风险和缓解参考

大多数事件都可以追溯到少数几种模式。在将 agent 扩展到整个团队之前，请将每种风险映射到一个控制措施上。

这里的框架遵循了 OWASP Top 10 for LLM Applications，该项目将提示注入、不安全输出处理和过度代理能力列为主要的 agent 风险。

权限和范围参考

这是我给新团队成员的速查表。它涵盖了改变单次运行“爆炸半径”的设置。

连接 MCP server 之前进行审查

MCP servers 为 agent 添加了新的工具：数据库客户端、票务集成、浏览器。你添加的每一个都是可以读取上下文并执行操作的代码。不受信任的服务器是将一个有用的 agent 变成数据外泄路径的最快方式，因此连接它的门槛应该和你对任何具有网络访问权限的依赖项应用的门槛一样高。

在添加 server 之前，请回答五个问题：

1. 它由谁发布，其来源是否公开且维护良好？
2. 它请求哪些范围：只读，还是写入和网络？
3. 连接后它能看到什么数据：只是这个 repo，还是你的整个机器？
4. 凭证是限定范围的、短期有效的，还是长期管理员 token？
5. 你能否固定一个版本，以防止自动更新悄无声息地扩大其访问权限？

连接具有最小范围且能够完成任务的 server，并将写入能力或面向生产环境的 server 排除在共享或 CI 配置之外。有关设置机制和更深入的指南，请参阅我们的 Claude Code MCP integration guide。Claude Code productivity tips 文章介绍了如何在不减慢速度的情况下保持最小足迹。

将密钥排除在模型范围之外

最干净的秘密是模型从未见过它。不要将 API 密钥粘贴到提示词中，也不要让 agent “读取配置中的密钥并使用它”。让凭证存在于环境中，并通过名称引用它们，这样值就会留在记录之外。

三个习惯涵盖了大部分风险：

• 为 .env、*.pem 和任何 secrets/ 目录添加 deny 规则，以防 agent 不知不觉地读取它们。
• 使用预提交的 secret scanner（例如 gitleaks 或 git secrets），这样泄露的密钥就会导致 commit 失败，而不是审计失败。
• 对任何意外暴露的凭证立即进行轮换，然后检查日志和历史记录。轮换是唯一真正关闭时间窗口的修复方法。

如果一个密钥已经进入了记录或提交，请假设它已被泄露并对其进行轮换。使用 git log -S 搜索 git 历史记录可以帮助你找到它落点的位置。

场景：在没有生产凭证的情况下在 CI 中启用 Claude Code

一个团队希望 Claude Code 在 GitHub Actions 中审查 pull requests。目标是自动化的评论，但没有任何部署、写入 main 或触碰生产数据库的能力。

这是保持工作实用但又被限制的设置：

• 使用 claude -p 在 plan 模式下无头运行，让 agent 读取 diff 并写入评论，但绝不编辑文件或运行 build 命令。
• 只授予工作流 contents: read 和 pull-requests: write 的权限。没有部署 job，没有基础设施范围。
• 使用 job 的短期 GITHUB_TOKEN，而不是个人 token，并且绝不在该 job 的环境中放入数据库或云生产密钥。
• 为 secret paths 和出站 curl 添加 deny 列表，这样 PR diff 中的提示注入尝试就无法泄露任何东西。
• 固定 action 和 Claude Code 版本，并将任何部署步骤设置在另一个需要人工批准的环境之后。

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 可以看到代码并发布反馈。它无法触及生产环境，因为生产凭证从未在作用域内。Anthropic 的 Claude Code security overview 描述了这种用于自动化和无头运行的最小权限姿态。

延伸阅读：DevOps中的AI应用：自动化CI/CD、事件管理与基础设施

你绝不应该将什么粘贴到 AI coding agent 中？

某些输入不应出现在记录中，因为上下文窗口中的任何内容都可能被回显、记录或执行操作：

• 实时 API keys、带有密码的数据库 URL 或云根凭证。
• 客户 PII 或你不会放入支持工单的受监管数据。
• 私有签名密钥、证书或 .pem 文件。
• 当使用只读副本或本地 fixture 可以完成任务时，完整的生产连接字符串。

当 agent 需要访问权限时，应该通过环境提供指向限定范围凭证的路径，而不是秘密本身。结果相同，但爆炸半径小得多。

审计、钩子和持续审查

最小权限设定了底线；而审查让你保持在底线上。在批准有风险的步骤之前，阅读 agent 的计划；在提交之前，阅读 diff。对于更大的更改，与使 AI-assisted refactoring 安全的相同纪律在这里适用：小、可审查的步骤胜过一次巨大的无人值守运行。

使用钩子添加确定性护栏。PreToolUse 钩子可以检查命令并在其运行前阻止它，这就是你强制执行模型绝不应该覆盖的规则的方式，例如拒绝写入受保护的路径。将其与审计跟踪结合使用，这样你就可以回答 agent 何时、在谁的名义下做了什么。

一个快速的团队定期检查清单：

• 定期审查 .claude/settings.json 的 allow 和 deny 列表，而不仅仅是在设置时进行。
• 在主要版本升级后重新审查 MCP server。
• 确认 CI job 仍然以 plan 模式运行，并且不携带生产密钥。
• 按周期和任何可疑泄露后轮换 token。
• 保留一个 CLAUDE.md 文件，说明不可协商的规则：不得 force-push 到 main，不得直接访问 prod DB，提示词中不得包含 secret。

对于围绕所有这些内容的更广泛工作流程，Claude Code ultimate guide 提供了从头到尾的配置指南。

关键要点

AI coding agent 的安全性与你已经应用于服务账户的最小权限思维方式相同，只是将其写成了权限规则。从限制性开始，通过狭窄的白名单扩大范围，拒绝 secret paths，像对待依赖项一样审查 MCP server，将获取的内容视为不可信输入，并将生产凭证排除在任何 agent 可以触及的工作流之外。做到这一点，Claude Code 就会保持为一双快速的手，而不是一个敞开的大门。