Anthropic 公开 Claude 智能体「收容」架构：沙箱、虚拟机与出口管控如何锁住爆炸半径

核心看点

• Anthropic 工程团队首次系统公开自家智能体产品线的「收容」（Containment）架构，覆盖 claude.ai、Claude Code、Claude Cowork 三款产品。
• 智能体风险被拆成两个乘数：出错概率 × 破坏范围。安全机制与模型训练让前者持续下降，但后者只会随着能力和权限扩张不断变大。
• 「人在环审批」被自家数据打脸：内部统计显示，用户放行了大约 93% 的权限弹窗，审批疲劳让监督形同虚设。
• 三次真实翻车换来一条铁律——最容易出事的，往往是你自己写的那层代码，而不是久经考验的底层沙箱。

从「不敢给权限」到「权限已是家常便饭」

文章开篇就抛出一个反差：12 个月前，Anthropic 还无法接受给 Claude 足以「搞垮内部服务」的权限；而今天，这种级别的访问已是日常，开发者效率也因之明显提升。

他们把部署风险拆成两部分：出错的可能性，以及一次出错能造成的破坏。前者靠安全策略与模型训练稳步压低，后者——理论上的「爆炸半径」——却只会随着能力与权限的扩张越滚越大。于是工程上的核心命题变成一句话：如何给爆炸半径封顶。

文中提到一个具体案例：Claude Mythos Preview 曾因「爆炸半径过高」，在 2026 年 4 月被判定为不适合发布。Anthropic 预期，随着防御方加固关键系统、安全机制成熟，同等能力的模型未来可以更广泛地开放——尽管风险永远不会归零。

两条路线：管住「行为」，还是管住「能做什么」

收窄爆炸半径有两条路。第一条是在环的人类监督：Claude Code 早期靠每步弹窗请求授权。理论可行，实践却证明靠不住——数据显示用户放行了约 93% 的弹窗，审批越多，注意力越涣散。为此他们推出了 Claude Code auto mode，自动完成更安全的批准，但仍无法彻底消除漏洞：任何基于概率的防御都有非零的漏判率。

第二条路才是文章重点——收容（Containment）：不去监督智能体「做了什么」，而是通过沙箱、虚拟机和出口管控，限制它「能做什么」。Anthropic 工程团队在这上面投入最多，踩过的坑也最出人意料。

三类风险，三层防御

他们把智能体的安全风险归为三类：用户滥用（恶意或疏忽地指挥智能体做坏事）、模型行为失当（没人要求却自作主张）、外部攻击者（通过工具、文件、网络注入或攻击运行时）。

对应地，防御落在三个层面：智能体运行的环境（进程沙箱、虚拟机、文件系统边界、出口管控）、它所调用的模型（系统提示、分类器、探针、训练调整），以及它能触及的外部内容（MCP 服务器、第三方插件、联网搜索）。文章强调，模型层防御再强也不是 100%：在 Gray Swan 的 Agent Red Teaming 基准上，Claude Opus 4.7 单次尝试的攻击成功率约 0.1%，但在 100 次自适应尝试后会升到 5%–6%；Claude Code auto mode 也只能在约 83% 的「过度热心」行为执行前拦住它。因此防御必须分层叠加。

三种隔离姿势

模式一：一次性容器（claude.ai 代码执行）。代码跑在服务端的 gVisor 容器里，本地不执行任何代码，文件系统每次会话即焚。爆炸半径最小，能力上限也最低——没有持久工作区，也碰不到用户本地文件。它的威胁模型更传统：防的是自家基础设施和租户之间的串扰。

模式二：人在环沙箱（Claude Code）。它跑在用户机器上，需要文件、Shell 和网络访问。团队后来上了操作系统级沙箱（macOS 的 Seatbelt、Linux 的 bubblewrap）：读放行、工作区内可写、网络默认拒绝，权限弹窗因此锐减 84%，运行时也已开源、边界可审计。

模式三：本地虚拟机（Claude Cowork）。面向不太懂 bash 的知识工作者，人在环那套行不通。于是最初把整个智能体塞进完整虚拟机（macOS 用 Apple Virtualization、Windows 用 HCS），只有用户选定的工作区和 .claude 目录被挂载，凭据留在宿主机钥匙串、永不进入虚拟机。后来为了稳定性，把智能体主循环移出虚拟机、只把代码执行留在里面，安全性几乎不受影响。

三次翻车，三条教训

坑一：信任对话框之前的代码。2025 年中到 2026 年 1 月，多个漏洞都打在「用户还没点头就执行」的代码上。比如克隆一个仓库评审 PR，里面的 .claude/settings.json 定义了 hook，而 Claude Code 会在弹出「是否信任此文件夹」之前就读取项目配置——攻击者提交的 hook 便自动执行。修复方式一致：把项目本地配置的解析与执行，推迟到用户确认信任之后。文章提醒，项目打开、配置加载、本地监听这类动作，要像对待来自互联网的入站请求一样对待，别因为它「看起来是本地」就默认信任。

坑二：用户自己成了注入通道。2026 年 2 月的一次内部红队演练中，研究员钓鱼让员工用一段恶意提示启动 Claude Code。提示伪装成普通协作，其中悄悄要求 Claude 读取 ~/.aws/credentials、编码后 POST 到外部地址。25 次重试里，Claude 成功了 24 次。因为是用户亲手输入的指令，模型层防御无从察觉——唯一顶得住的是环境层：出口管控直接拦掉那次 POST，文件系统边界让 ~/.aws 根本够不着。

坑三：从「获批域名」溜出去的数据。Claude Cowork 的出口白名单放行 api.anthropic.com（产品本身就得调用自家 API）。一份恶意文件带着攻击者的 API Key 被放进工作区，指示 Claude 读取其它文件并调用 Anthropic 的 Files API——出口代理一看是「自己人」，直接放行，文件就传进了攻击者的 Anthropic 账户。修复方式是在虚拟机内架设一个中间人代理，只放行携带虚拟机自身会话令牌的请求。文章由此点题：白名单不该被理解成「域名过滤器」，而是一种「能力授予」——域名背后每一个可达功能，都是新的攻击面。

总结

三款产品、三种架构，Anthropic 最终收敛到同一个判断：把边界设在环境层，比指望人类时时清醒、或模型永不出错都更靠谱。而反复出现的教训是——gVisor、seccomp 这些久经沙场的组件一直稳如泰山，真正出问题的，是团队自己新写的出口代理和配置解析逻辑。用他们的话说：最薄弱的一层，恰恰是你自己造的那层。