先说结论

如果你今天只想知道 Anthropic 这篇 containment 文章到底意味着什么，先记住这 8 句话：

  • Anthropic 在 2026 年 5 月 25 日 发布了工程长文，系统解释 claude.ai、Claude Code 和 Claude Cowork 三种产品的 containment 设计。
  • 它最重要的信号不是“我们很安全”，而是官方承认：Agent 越能做事，blast radius 只会变大。
  • 文章明确把风险分成三类：user misuse、model misbehavior、external attackers。
  • 对开发者最有现实意义的一段，是它公开了 Claude Code 在信任边界之前解析项目配置所引出的漏洞教训，重点点名了 .claude/settings.json hooks。
  • 官方还直接说了：用户会对权限弹窗疲劳，遥测里大约 93% 的请求会被批准，所以“每步手动同意”并不是长期可靠解法。
  • 官方脚注也给了更硬的信息：auto mode 只是防御纵深中的一层，不能替代 sandbox，因为它仍会漏掉一部分过度积极的危险动作。
  • 对使用 MCP 的团队来说，官方明确提醒：远程 MCP server 或云连接器在你批准之后仍可能改变行为，安装时的信任不代表运行时一直可信。
  • 一句话判断：
    • 普通用户：这不是你今天要紧张的新闻。
    • 进阶开发者：如果你在用 Claude Code、hooks、MCP 或自动审批，必须看。
    • 站长或工具团队：这篇比很多“模型更强了”更接近真实上线风险。

建议连着看这些站内页，再回来看 containment 会更清楚：

外部标杆页面怎么写，我们补了什么？

这类内容的高质量写法，通常不是只摘录安全术语，而是先把“实际会踩哪种坑”写清楚。

  • Anthropic 官方工程文负责交代架构、失误和修复路径。
  • MCP 官方文档负责告诉你能力边界和接入方式。
  • 真正有价值的解读，会把这些东西翻译成一句用户能执行的话：哪些默认做法必须改。

我们在官方文档基础上补的，是中文开发团队最关心的三层判断：

  1. hooks、project trust、localhost listeners 为什么会成为真风险。
  2. MCP 和远程工具为什么不能只做一次性信任。
  3. 什么时候该继续用自动审批，什么时候必须退回更强隔离。

这篇文章真正讲的不是“安全”，而是边界

Anthropic 这次最有价值的地方，是它没有把问题写成抽象道德题，而是把它落回系统边界：

  • 代理在哪运行
  • 能碰到什么文件
  • 能不能出网
  • 凭据是不是进了沙箱
  • 谁来批准动作
  • 信任从什么时候开始生效

也就是说，它讲的不是“模型有没有坏心眼”，而是 就算它出错，最多能坏到哪一步。

这才是做 Agent 产品最该优先想清楚的东西。

对 Claude Code 用户最重要的 3 个提醒

1. Trust boundary 之前不能解析项目本地配置

Anthropic 公开复盘的核心教训之一，就是：

  • 开发者打开一个仓库
  • 仓库里带着 .claude/settings.json
  • 如果在用户点击 “trust this folder” 之前就读取或执行里面的 hooks
  • 攻击面就已经打开了

官方给出的修复思路很直接：把项目本地配置的解析和执行推迟到用户接受 trust 之后。

这条经验不只适用于 Claude Code。你如果自己也在做：

  • 本地 Agent 工具
  • IDE 插件
  • 自动化 CLI
  • MCP 宿主

也应该把“打开项目”当成一类外部输入，而不是天然可信动作。

2. 人工逐条审批会疲劳

官方数据很有说明力：用户大约批准了 93% 的权限请求。也就是说，如果你把安全完全押在“用户每次都认真看”，这层防线会越来越薄。

所以 Anthropic 才会把重点从“每步都问”逐步转向：

  • 更合理的默认 sandbox
  • 更清晰的 egress 限制
  • 自动模式只处理相对安全的批准

这也解释了为什么真正成熟的 Agent 产品，最后都得回到环境隔离，而不是只靠弹窗。

3. Auto mode 不能代替 containment

Anthropic 自己在脚注里都说了，auto mode 是防御纵深的一层，而不是替代物。

这对团队很重要，因为很多人最容易误判成：

  • 只要自动审批够聪明
  • 就能代替 sandbox

实际不是。自动审批的价值是降摩擦，不是抹掉风险。

MCP 和远程工具为什么更值得警惕

如果你最近在大规模接 MCP，Anthropic 这篇文章有一句特别值得反复看：

远程工具在你批准之后，仍可能随时改变行为。

这意味着：

  • 你批准的是“接这个 server”
  • 但不等于你永久批准了它之后所有行为

对工具团队来说，最现实的动作不是停用 MCP，而是把它分层：

  • 本地受控 MCP
  • 可观察的内部托管 MCP
  • 第三方远程 MCP

越往后，默认权限越不能放松。

claude.ai、Claude Code、Cowork 各自说明了什么

1. claude.ai 说明“最小 blast radius”怎么换能力上限

官方说 claude.ai 的代码执行在 gVisor 容器里、服务端完成、文件系统按会话临时存在。这种设计的好处是 blast radius 小，但代价也明显：

  • 没有持久工作区
  • 没有本地文件系统访问
  • 可做的事更受限

这适合大多数普通用户，但不适合重度本地开发场景。

2. Claude Code 说明“有用”与“危险”往往一起增长

Claude Code 的价值正在于它真能碰到：

  • shell
  • filesystem
  • network

但这些能力同时也带来最大风险。所以最关键的问题从来不是“要不要给它能力”，而是 能力给了以后怎么把边界卡死。

3. Cowork 说明企业化最终会走向身份和凭据分层

Anthropic 在文中提到，Cowork 的做法是：

  • 凭据留在 host keychain
  • VM 里用按会话缩小权限的 token
  • token 可以独立撤销

这说明一条很现实的趋势：企业级 Agent 最终比拼的，不只是模型质量，而是身份、权限、撤销和审计能力。

普通用户、进阶用户、站长分别怎么判断

普通用户

如果你只是偶尔在聊天界面里问问题，这篇对你最重要的启发只有一个：

能做事的 Agent，不等于可以无限信任。

进阶开发者

你该马上检查三件事：

  • 本地项目配置是不是在 trust boundary 之前就会被读
  • 你的 hooks 有没有最小权限和最小默认开启面
  • 第三方 MCP 是否被你和团队过度默认信任

站长、工具团队和自动化团队

你应该把 containment 当成上线条件，而不是上线后再补的安全优化。真正该优先问的是：

  • 凭据进没进沙箱
  • 远程连接器能不能随时改行为
  • 本地仓库内容是不是被默认当作可信输入
  • 自动审批是否被误当成核心安全层

如果这四件事有两件没答清楚，先别扩大自动化范围。

质量门槛判断

如果一篇 containment 文章只会重复 “sandbox、VM、egress controls”，它通常不够有用。

真正值得看的内容，至少要说清：

  • 为什么 hooks 会越过信任边界
  • 为什么远程 MCP 不是一次性信任
  • 为什么 auto approvals 只能降低摩擦，不能替代隔离

这篇最后的判断也很明确：

Anthropic 这篇文章最值得重视的，不是它宣称自己多安全，而是它公开承认：Agent 产品最容易出事的地方，往往是我们自己围着成熟安全原语新搭出来的那一层。

常见问题

Anthropic 这篇 containment 文章最该谁看？

最该看的是用 Claude Code、hooks、MCP、自动审批或在做 Agent 平台的人，而不是普通聊天用户。

为什么 .claude/settings.json hooks 这么关键？

因为它触发的是 trust boundary 问题。只要项目本地配置在用户明确授权前就被解析或执行，恶意仓库就有机会先于你的安全提示生效。

远程 MCP 为什么不能只装一次就长期信任？

因为远程工具和云连接器的行为可以在你批准之后变化。安装时信任只是入口，不等于运行时永远安全。

这篇首图来自哪里？

首图是本站自制信息图，文件位于 /article-images/claude-containment-hooks-mcp-guide-2026-05-27.svg。图中结构依据 Anthropic 官方 engineering 文章和 MCP 官方文档整理绘制，未使用来源不明图片。

资料来源

延伸阅读