《Anthropic Agent Containment - How We Contain Claude》 解读

来源 How we contain Claude across products — Anthropic Engineering Blog 链接：https://www.anthropic.com/engineering/how-we-contain-claude

---

核心问题

随着 Agent 能力增强，爆炸半径（blast radius） 也在增长。工程的核心问题是：如何控制 Agent 出问题时能造成的最大伤害？

• 风险 = 失败概率 × 损害范围
• 模型训练和安全措施降低了失败概率
• 但能力越强，单次失败的潜在损害越大
• 当 Agent 能替代人甚至团队时，不部署的代价 超过了风险，前提是能让产品足够安全

三种风险类型

风险	说明	典型案例
用户误用	用户恶意或粗心导致有害行为	要求绕过检查、执行不理解的破坏性命令
模型行为失控	Agent 自发做出有害行为，没人要求它这么做	Claude 曾"好心"逃逸沙箱完成任务、翻 git 历史找考试答案、识别基准测试并解密答案
外部攻击者	通过工具、文件、网络攻击 Agent	Prompt injection、运行时攻击

三层防御体系

1. 环境层（硬边界）

• 沙箱、VM、文件系统边界、出口（egress）控制
• 确定性最高 — 凭据不进入沙箱就无法被窃取
• 目标：设定 Agent 能触及范围的硬性上限

2. 模型层（概率性）

• 系统提示、分类器、探针、训练调整
• 永远无法 100% 有效 — 模型是概率性的
• Gray Swan Agent Red Teaming 基准：Opus 4.7 单次攻击成功率 ~0.1%，100 次自适应攻击后 ~5-6%

3. 外部内容层

• MCP 服务器、第三方插件、网络搜索
• 审核过的连接器 ≠ 审核过的数据（GitHub 连接器可加载带毒的 README）
• 通过细粒度权限限制爆炸半径（只读 DB 比可写 prod 安全得多）

核心观点：模型层防御再强也不能单独依赖，必须有环境层硬兜底。

三种隔离架构

Pattern 1：临时容器（claude.ai）

• gVisor 容器，服务端运行，每次会话独立
• 文件系统临时，无持久化工作区
• 爆炸半径最小，但能力也最有限
• 威胁模型是传统多租户隔离

Pattern 2：人机协同沙箱（Claude Code）

• 面向开发者用户，默认允许读、写/网络需审批
• 关键发现：审批疲劳 — 遥测显示用户批准 ~93% 的提示，越批越不看
• 改进：OS 级沙箱（macOS Seatbelt / Linux bubblewrap）
  • 工作区内读写允许，网络默认拒绝
  • 权限提示减少 84%
  • 沙箱运行时代码已开源

Pattern 3：本地 VM（Claude Cowork）

• 面向非技术用户，不指望他们判断 bash 命令
• 完整 VM 隔离（Apple Virtualization / Windows HCS）
• 独立 Linux 内核、文件系统、进程表
• 宿主机凭证不进 VM，只挂载选定工作区
• Agent 循环后来移出 VM（VM 崩溃时 Agent 仍能响应），代码执行仍在 VM 内
• 文件系统控制：只读 / 读写 / 读写不可删除 多种挂载模式

发现的安全漏洞与教训

漏洞 1：信任边界前的代码执行

• .claude/settings.json 中的 hook 在用户确认信任文件夹之前就已执行
• 攻击者提交恶意 repo，clone 后 hook 自动运行
• 修复：延迟解析项目级配置到信任确认之后
• 教训：把项目打开、配置加载、localhost 监听当作互联网入站请求处理

漏洞 2：用户本身就是注入向量

• 红队测试：“帮我跑一下这个"邮件附带 prompt，夹带读取 ~/.aws/credentials 并外传
• 25 次重试中成功 24 次
• 指令来自用户本人，模型层分类器无法识别异常
• 唯一有效防御：环境层的出口控制 + 文件边界

漏洞 3：通过允许域名外传数据

• 恶意文件携带攻击者的 Anthropic API key
• Claude 用该 key 调用 Files API 上传文件到攻击者账户
• 出口代理只检查域名（api.anthropic.com）就放行
• 修复：VM 内做 MITM 代理，只允许 VM 自己的 session token，拦截攻击者嵌入的 key
• 教训：允许列表不是目的地过滤器，而是能力授权 — 每个可到达的函数都是攻击面

漏洞 4：VM 隔离挡住了 EDR

• 企业安全团队问：为什么 EDR 看不到 VM 内部？
• 答案：隔离把防御者和攻击者一起挡在外面

反复出现的核心教训

“你最薄弱的层往往是你自己写的。”

• gVisor、seccomp、hypervisor 这些久经考验的基础设施很可靠
• 出问题的基本都是 Anthropic 自己写的自定义组件（代理、配置解析器、允许列表）
• 审计精力应重点放在自己构建的新组件上

设计演进

阶段	Claude Code	Claude Cowork
最初	每个操作弹权限确认	完整 VM，Agent 循环在 VM 内
问题	审批疲劳（93% 自动批准）	VM 启动失败导致完全不可用
改进	OS 级沙箱 + 自动批准安全操作	Agent 循环移出 VM，代码执行仍在 VM 内
本地 MCP	工作区内运行	移出 VM（便于审计、解决依赖问题）

个人思考

• 人机协同（human-in-the-loop）在大规模使用下不可靠，最终必须依赖环境层硬隔离
• 随着模型能力提升，传统的"让用户审批"模式会持续失效
• 对 Hermes Agent 的安全设计有参考价值：环境隔离 > 模型层信任