当 Claude Code 从个人工具升级为团队协作平台时，安全边界的设计变得至关重要。本文聚焦 Claude Code 在团队场景下的两个关键安全机制：MCP 服务器审批流程和工作区信任模型，帮助团队在享受自动化便利的同时不引入供应链风险。
问题的根源：克隆的仓库不该自动获得权限
设想这样一个场景：你的团队在 .claude/settings.json 中提交了一个 MCP 服务器配置，并设置了 enableAllProjectMcpServers: true。如果这个仓库被克隆到一台新机器上，Claude Code 不应该自动信任并连接这个 MCP 服务器——因为攻击者完全可以 fork 一个恶意仓库，在 .claude/settings.json 里塞入一个指向恶意服务器的配置，诱导受害者克隆并直接获得工具执行权限。
Claude Code 的解决方案：工作区信任 + 审批状态
从 v2.1.196 起，Claude Code 引入了明确的信任边界：
# 查看当前项目的 MCP 服务器状态
claude mcp list
# 待审批的服务器会显示为：
⏸ Pending approval
# 已拒绝的服务器会显示为：
✗ Rejected核心规则：claude mcp list 和 claude mcp get 只从未提交到仓库的设置文件中读取 .mcp.json 的审批状态。也就是说：
✅ 有效的审批来源：
- 本地未提交的 .claude/settings.local.json
- 用户级 ~/.claude/settings.json
- 你手动在交互式会话中批准的记录
❌ 无效的审批来源（在不受信任的目录中）：
- 提交到仓库的 .claude/settings.json 中的 enableAllProjectMcpServers
- 提交到仓库的 .claude/settings.json 中的 enabledMcpjsonServers
如何建立工作区信任
# 1. 在项目目录中交互式运行 claude
cd my-project
claude
# 2. 首次运行时会弹出工作区信任对话框
# 阅读并确认该目录是可信的
# 3. 确认信任后，审查待批准的 MCP 服务器
/mcp
# 4. 逐个批准需要的服务器重要：只有当你主动完成了工作区信任流程，仓库提交的 MCP 服务器审批配置才会生效。一个克隆下来但从未被你交互式打开过的仓库，其 MCP 服务器会一直停留在 ⏸ Pending approval，不会被连接，也不会被健康检查。
团队推荐实践
1. 仓库中只提交「意图」，不提交「自动批准」
// .claude/settings.json（提交到仓库，团队共享）
{
"enabledMcpjsonServers": ["jira", "sentry"]
}这只是声明「这个项目建议使用哪些 MCP 服务器」，真正的连接仍需每个开发者在自己机器上完成工作区信任 + 手动审批。
2. 新成员 Onboarding 检查清单
# 新成员加入项目后应执行的步骤
git clone <repo>
cd <repo>
claude # 触发工作区信任对话框，确认信任
/mcp # 查看待审批的 MCP 服务器列表
# 逐个审查每个服务器的 URL/命令是否符合预期，再批准3. 结合参数级权限控制加固
配合 Claude Code Week 25 引入的参数级权限规则，进一步限制敏感操作：
{
"permissions": {
"deny": [
"Agent(model:opus)"
],
"ask": [
"Bash(git push*)"
]
}
}为什么这套机制值得信赖
这套「工作区信任 + 本地审批状态不可通过仓库提交绕过」的设计，本质上解决了供应链投毒的问题：即使攻击者完全控制了仓库内容，也无法让受害者的 Claude Code 在毫无察觉的情况下连接恶意 MCP 服务器——审批这一步骤永远需要人在本地机器上主动确认。
总结
Claude Code 的 MCP 审批机制体现了「Trust but Verify」的安全设计理念：团队可以在仓库中共享 MCP 配置意图，但实际的信任决策——是否连接、是否执行——始终掌握在每个使用者手中，不会因为克隆了一个仓库就被动继承风险。对团队负责人来说，在 Onboarding 流程中加入「审查待批准 MCP 服务器」这一步，是值得强调的安全实践。
来源：Connect Claude Code to tools via MCP — Anthropic 官方文档