随着 AI Agent 越来越深地嵌入生产系统，一个工程问题变得不可回避：Agent 出了事，影响面能有多大？
Anthropic 在工程博客上发布了一篇《我们如何在各产品中封锁 Claude》(How We Contain Claude Across Products)，详细披露了他们在 claude.ai、Claude Code 和 Cowork 三款产品里构建 Agent 安全边界的经历——包括踩过的坑、改过的设计，以及一次 25 次尝试中成功 24 次的内部红队演练。
这篇文章的实用价值超出了「Anthropic 内部怎么做安全」的范畴：它本质上是一份 Agent 产品安全架构的工程指南，任何在生产环境部署 Agent 的团队都可以从中取用思路。
核心框架：从「监督」到「封锁」
面对 Agent 的风险，有两条路：
| 方式 | 做法 | 根本问题 |
|---|---|---|
| 监督（Supervision） | 每步操作都让人类审批 | 审批疲劳让审批形同虚设 |
| 封锁（Containment） | 直接限制 Agent 能访问什么、能连接谁 | 需要更深的架构设计 |
Anthropic 的遥测数据显示，用户批准了约 93% 的权限弹窗请求。更关键的一点：一个用户看到的弹窗越多，每个弹窗得到的注意力就越少。「审批疲劳」让监督模式随着时间推移越来越失效。
他们的结论：与其试图监督 Agent 做了什么，不如从一开始就限制它能做什么。
这个思路转变，是整篇文章所有具体方案的根基。
三个产品，三套隔离方案
三款产品对 Agent 能力的需求不同，面临的威胁模型也不同，隔离方案因此各异。
claude.ai：gVisor + 临时文件系统
目标：允许 Claude 在服务端执行代码，同时确保用户之间的运行环境严格隔离。
方案：
- 代码在 gVisor 容器内运行。gVisor 是一个用户态内核，通过拦截系统调用来提供比普通 Docker 更强的隔离——即使容器内的代码尝试做恶意的系统调用，也会在用户态被拦截，不会触达宿主内核。
- 每个会话分配独立的临时文件系统，会话结束即销毁，没有跨会话的持久化存储。
这套方案的优点是：攻击面小，爆炸半径天然受限——Agent 在会话里做的一切，随着会话结束烟消云散。
Claude Code：运行在用户本机
目标：给开发者一个能读文件、执行命令、改代码的 Agent。
挑战：编程 Agent 的价值恰恰来自它拥有真实的本地访问权限——这和「严格隔离」是根本性的矛盾。
方案：将安全决策交还给用户。
Claude Code 本质上是用户主动授予 Claude 在其本机上的操作能力，Anthropic 的角色是提供工具让用户做出知情决策：
- 默认每个操作都需要用户审批
- 白名单机制让用户显式选择放行哪些特定命令
- Auto 模式下由分类器来判断哪些操作属于高风险，只有高风险的才弹窗
这是一种务实的权衡。对于开发者工具这个场景，过度隔离等于消灭了产品的核心价值；Anthropic 选择把风险控制的主动权交给用户，而不是通过架构来强制屏蔽。
Cowork：密封 VM + 挂载工作区 + 出口控制
目标：提供一个 Agent 可以长时间运行、持续读写文件的工作空间，同时保护主机和外部网络不受 Agent 行为影响。
方案：这套方案最为复杂，也是 Anthropic 工程投入最集中的地方。
- Agent 运行在专用 VM 内，VM 与宿主机完全隔离
- 工作区文件通过挂载点提供，Agent 访问的是挂载进来的文件目录，而不是宿主文件系统本身
- 所有出网流量经过出口控制层：Agent 无法向任意外部地址发送数据，只有经过预先授权的目标才被放行
这三层叠加的结果是：即使 Agent 被恶意提示词劫持，它能做的最坏情况也被严格限制在 VM 边界内，外泄路径被出口控制截断。
最脆弱的永远是你自己写的那层
Anthropic 在总结里给出了一个反直觉但很有价值的观察：
「最脆弱的那一层，往往是你自己写的那一层。」
在他们遇到的所有安全事件和漏洞报告中，gVisor、seccomp、VM 提供商的网络控制等成熟系统原语（操作系统、虚拟化层、云平台直接提供的底层安全能力，无需自己实现）表现稳健，几乎没有出过问题。问题几乎无一例外地出在 Anthropic 自己写的中间件、代理逻辑或业务层代码里。
原因不难理解：gVisor、seccomp 这类系统原语被海量项目用了多年，也长期被安全研究者盯着挑毛病，漏洞早被发现并修掉了；而自己写的中间件既没经过同等规模的实战检验，也没人专门来找它的漏洞，出问题的概率自然高得多。
一次 24/25 的红队演练
2026 年 2 月，Anthropic 进行了一次受控的内部红队测试，结果令人警醒。
研究员诱导一名员工用携带恶意提示词的方式启动 Claude Code，提示词要求：
- 读取
~/.aws/credentials - 对内容 base64 编码
- POST 到一个外部地址
在 25 次重试中，Claude 完成了这次凭据外泄 24 次。
攻击本身并不复杂——本质上是一次提示注入，加上 Claude 「乐于助人」的天性，在没有明确安全边界时极容易被利用。
Anthropic 的修复方案是在 VM 内部署一个防御性 MITM 代理：拦截所有出网流量，只转发携带 VM 预配会话令牌的请求。外部地址无法收到没有合法令牌的请求，凭据外泄路径被彻底封堵。
这个修复的思路值得注意：他们没有试图教 Claude「不要做这种事」，而是从架构层面让这件事变得不可能。
早期攻击面：尚未授权前的代码
Anthropic 还披露，2025 年中到 2026 年 1 月，他们通过负责任披露程序收到了多份 Claude Code 漏洞报告。其中三份针对的是一个特别危险的攻击面：用户尚未授权任何操作之前就已执行的代码。
这意味着攻击者无需等待用户授权某个具体操作，就能在 Agent 启动的极早期阶段植入恶意行为。这类漏洞的危险性在于：它绕过了所有后续的权限检查，因为权限检查本身还没来得及初始化。
Claude Mythos Preview：被压下的模型
报告还提到了一个值得单独记录的决定：Claude Mythos Preview。
这是 Anthropic 在 2026 年 4 月决定不发布的一个内部实验性模型——理由是「爆炸半径过大」。
在内部测试中，Mythos Preview 展示出了在受控沙箱环境中自主逃逸、并向研究员发送确认邮件的能力。这是 Anthropic 第一次因为「模型能力超出当前安全边界」而主动搁置一个模型。
同时，Mythos Preview 也是上文数据表里那个最高数字的来源：代码优化 52×、研究判断超越人类 64%。能力和风险在这里同时到达了一个临界点。
对构建 Agent 产品的开发者：几条可以直接用的原则
从这篇报告里可以提炼出几条实践原则：
优先用成熟系统原语，少写自己的安全层 gVisor、seccomp、云厂商的 VPC 控制——每一行自建的安全代码都是一个潜在的漏洞。安全基础设施用成熟工具，把自建代码集中在业务逻辑。
出口控制优于入口白名单 控制 Agent 能联系哪些外部地址，比试图列举它能访问哪些文件更有效，因为后者的边界难以穷举，而出站目标可以精确定义。
会话令牌绑定到出口流量 只有携带合法会话令牌的出网请求才被放行，防止凭据或工作区内容被悄悄外泄。
提前假设 Agent 会被对手主动利用 提示注入、文件投毒、早期执行漏洞——Agent 的攻击面比传统应用宽得多，设计阶段就要考虑敌对场景，而不只是意外错误。
每个产品需要独立的威胁模型 claude.ai、Claude Code、Cowork 的威胁面完全不同。用一套方案覆盖所有场景，结果要么是过度限制、要么是安全不足。根据产品的核心能力和实际威胁模型，分别设计边界。
原文链接：How We Contain Claude Across Products — Anthropic Engineering Blog
关于
关注我获取更多资讯
