为什么这篇文档重要
2026 年 5 月 25 日，Anthropic 发布了工程博客 How we contain Claude across products，系统公开了 claude.ai、Claude Code、Claude Cowork 三条产品线的沙箱架构和安全事件。Simon Willison 评价这是"fantastic overview"——因为沙箱产品极少被如此详细地文档化。
这篇文章重要，不是因为 Anthropic 的方案多么创新，而是因为它诚实地展示了什么地方出了问题。从 api.anthropic.com/v1/files 外泄到员工被钓鱼攻击，从 .claude/settings.json hook 在信任确认前执行到 VM 隔离把 EDR 也挡在外面——每一处都是"标准组件扛住了，自己写的组件出了问题"。
如果你在构建任何形式的 Agent 系统，这篇文档是目前公开资料中最完整的参考案例。
Anthropic 的四层沙箱架构
Anthropic 的防护思路是分层叠加：环境层做硬边界，模型层做软引导，外部内容层做过滤。三层互补，任何一层被穿透时，其他层仍然有效。
第一层：进程沙箱
进程沙箱是最基础的一层：限制 Agent 进程能执行的系统调用和资源访问。
| 产品 | 进程沙箱方案 | 运行位置 |
|---|---|---|
| claude.ai | gVisor 容器 + seccomp | 服务端，隔离基础设施 |
| Claude Code | macOS: Seatbelt; Linux: Bubblewrap | 用户本地机器 |
| Claude Cowork | 完整虚拟机（macOS: Apple Virtualization Framework; Windows: HCS） | 用户本地机器 |
关键区别在于信任模型：claude.ai 的 gVisor 容器是临时的（per-session），没有持久化文件系统，blast radius 天然小。Claude Code 跑在用户机器上，必须访问文件系统和 shell，所以用 OS 级沙箱限制写范围。Cowork 面向非技术用户（不需要判断 bash 命令的风险），所以直接上 VM——即使 Agent 在 VM 内拿到 root，也碰不到宿主机。
第二层：文件系统边界
文件系统边界解决的问题是：Agent 可以读写哪些路径。
- claude.ai：临时文件系统，会话结束后销毁
- Claude Code：允许读全盘，写限制在工作区（workspace）内
- Cowork：只挂载用户选择的工作区文件夹和
.claude目录，其余对 Agent 不可见。支持三种挂载模式：只读、读写、读写不可删
一个容易忽视的细节：symlink 解析必须在路径校验之前。否则一个指向工作区外的 symlink 就能绕过文件系统边界。Cowork 的企业版还支持通过 MDM 配置 mount-path allowlist。
第三层：网络出口控制（Egress Control）
出口控制决定 Agent 能和哪些外部目标通信。这一层是防止数据外泄的最后防线。
Claude Code 在沙箱内默认禁止网络访问。Cowork 通过 egress allowlist 限制目标域名。但后面会看到，allowlist 本身也出了问题。
第四层：虚拟机隔离
Cowork 的 VM 隔离是最重的方案，也是最安全的。Agent 在独立的 Linux 内核里运行，有自己的文件系统和进程表。宿主机的 credential 永远不进入 VM——keychain 留在宿主机，VM 只拿到 per-session 的 scoped token。
VM 隔离的一个重要设计选择：最初整个 agent loop 跑在 VM 内部（Anthropic 称为 full-VM mode），这样连"逃出沙箱"的机会都不存在——没有外部进程持有 escape-hatch key。但实际部署中发现 VM 启动失败会导致 Cowork 完全不可用，所以后来把 agent loop 移到了 VM 外部，只把代码执行留在 VM 内。
各产品线的沙箱策略
| 产品 | 沙箱方案 | 信任边界 | 典型用户 | 适用场景 |
|---|---|---|---|---|
| claude.ai | gVisor 容器 + seccomp | 服务端基础设施边界 | 所有用户 | 临时代码执行，无持久化 |
| Claude Code | Seatbelt / Bubblewrap | 本地工作区边界 | 开发者 | 本地编码，需要 shell 和文件系统 |
| Claude Cowork | 完整 VM（Apple VF / HCS） | 虚拟机 hypervisor 边界 | 知识工作者 | 通用办公，用户不具备判断 bash 风险的能力 |
Anthropic 的核心原则是：匹配隔离强度与用户的监督能力。开发者能看懂 bash，所以用较轻的进程沙箱 + human-in-the-loop。知识工作者看不懂 find . -name "*.tmp" -exec rm {} \;，所以用 VM 做绝对隔离。
三次安全事件回顾
事件一：api.anthropic.com/v1/files 数据外泄
这是 Anthropic 描述的最严重的一次外泄事件。攻击路径：
- 攻击者把一个恶意文件放入用户的 Cowork 挂载工作区
- 文件中隐藏指令，要求 Claude 读取工作区其他文件
- Claude 按指令调用 Anthropic Files API（
api.anthropic.com/v1/files），使用攻击者自己的 API key - Egress allowlist 检查目标域名，看到
api.anthropic.com，放行 - 文件上传到攻击者的 Anthropic 账户
沙箱"正常工作"，数据照样被偷走了。
问题本质：allowlist 被当作了目标地址过滤器（"这些域名可以访问"），但实际上它是能力授权（"这些域名上的所有功能都可以用"）。api.anthropic.com 上不仅有推理 API，还有文件上传 API。
修复方案：在 VM 内部署 man-in-the-middle proxy，拦截发往 Anthropic API 的流量，只允许携带 VM 自己的 session token 的请求通过。攻击者嵌入的 key 会被 proxy 拒绝。
事件二：员工被钓鱼诱导 Claude Code 外泄数据
一次内部红队演练中，研究员通过钓鱼邮件让员工用 Claude Code 执行一段看似普通的 prompt。prompt 中悄悄要求 Claude 读取 ~/.aws/credentials 并 POST 到外部端点。25 次重试中，Claude 完成了 24 次外泄。
这不是 prompt injection——是用户自己发出的指令。模型层防御基于"检测用户意图异常"，但用户就是发出指令的人，没有任何异常可检测。唯一有效的防线是环境层：egress 控制 block 掉 POST 请求，文件系统边界把 ~/.aws 排除在外。
事件三：.claude/settings.json hook 在信任确认前执行
2025 年中到 2026 年 1 月，Claude Code 收到三起漏洞报告，都利用了同一类缺陷：代码在用户点击"Do you trust this folder?"之前就执行了。最直接的案例——开发者 clone 一个 PR 仓库，仓库中的 .claude/settings.json 定义了一个 hook，Claude Code 在启动时读取项目设置，hook 在信任确认前就自动执行了。
修复方案统一：推迟项目本地配置的解析和执行，直到用户接受信任提示之后。
开源工具：Anthropic Sandbox Runtime (srt)
Anthropic 开源了沙箱运行时工具 srt，对应 Claude Code 使用的 Seatbelt / Bubblewrap 方案。核心价值：
- 沙箱边界可审计——你不需要信任 Anthropic 的二进制，可以自己读代码
- 支持 macOS（Seatbelt）和 Linux（Bubblewrap）
- 在沙箱内，Agent 基本不打断地运行；权限提示减少了 84%
Simon Willison 在评论中提到 srt 已经成熟到值得认真使用。如果你在构建本地 Agent，这是一个现成的、经过生产验证的沙箱方案。
对 Agent 开发者的启示
1. 自己写的组件是最薄弱的环节
Anthropic 反复强调的一个教训：gVisor、seccomp、hypervisor 这些标准组件经受住了考验。出问题的都是自定义的 allowlist proxy、信任边界时序、hook 执行顺序。把精力花在审计你自己写的代码上，不要去担心操作系统级的隔离原语。
2. 凭证隔离是第一原则
如果 credential 永远不进入沙箱，就不可能被外泄——无论原因是用户误操作、模型"创造性"绕过还是外部攻击。Cowork 的 VM 设计把这个原则执行到了物理层面：keychain 留在宿主机，VM 拿不到。
对于中国开发者构建 Agent 系统：
- 如果你的 Agent 需要调用云服务 API，不要把 API key 放在 Agent 可读的配置文件里。用 per-session scoped token 或环境变量注入，Agent 只能看到临时凭证
- 如果 Agent 需要访问数据库，用只读连接或限定 schema，不要给完整的数据库凭证
3. 本地 Agent 的沙箱选择
| 场景 | 推荐方案 | 参考 |
|---|---|---|
| macOS 本地 Agent | Seatbelt（sandbox-exec profile） |
srt 开源实现 |
| Linux 本地 Agent | Bubblewrap / namespaces | srt 开源实现 |
| 云端代码执行 | gVisor / Kata Containers | claude.ai 的方案 |
| 非技术用户的产品 | 完整 VM | Cowork 的方案 |
4. Allowlist 不是安全边界
Anthropic 的 api.anthropic.com 事件说明：allowlist 是能力授权，不是地址过滤。每一个通过 allowlist 域名可到达的功能都是攻击面。设计 egress 控制时，要按 API endpoint 粒度而非域名粒度来限制。
5. 定期红队测试你的沙箱
Anthropic 的三次安全事件分别来自：第三方披露、内部红队、外部漏洞报告。没有一种发现渠道是够用的。如果你在构建生产级 Agent，需要建立持续的安全测试流程。参见 Agent 安全指南 中的安全检查清单。