Trail of Bits 开源 Coop:为 Claude Code 和 Codex 提供隔离 VM 沙箱的工程实践 2026 年 9 月初,Trail of Bits 在 GitHub 上以 Apache 2.0 协议开源了 Coop ——一个面向 Claude Code、Codex、Cursor 等 Coding Agent 的隔离 VM 沙箱。Coop 的设计目标不是"拦截危险命令"或"拦
Trail of Bits 开源 Coop:为 Claude Code 和 Codex 提供隔离 VM 沙箱的工程实践
2026 年 9 月初,Trail of Bits 在 GitHub 上以 Apache 2.0 协议开源了 Coop ——一个面向 Claude Code、Codex、Cursor 等 Coding Agent 的隔离 VM 沙箱。Coop 的设计目标不是"拦截危险命令"或"拦截 prompt injection",而是把 Agent 跑在一个一次性 microVM 里,Agent 在 VM 内部完成所有工作,VM 销毁时所有状态随之消失。这条设计思路与 Anthropic 在 2026-07-30 containment 报告里提出的"defense-in-depth"原则、AISI 9 月发布的 Agent Sandbox Escape Benchmark、Manifold Security 的 GitSpawn 披露共同构成 2026 年下半年 Agent 安全工程的"沙箱重置"潮流——把 Agent 跑在隔离的、有明确边界的、有完整状态销毁机制的环境里,而不是依赖模型层、内容层、应用层的各种"拦截"。Coop 的开源给了企业 IT 一份具体的、可参考的工程基线。
一、Coop 的设计目标与基本假设
Coop 在 README 里直接给出三条基本假设,这些假设定义了它解决的问题边界。
第一条假设是 Coding Agent 应当跑在隔离环境里。这条假设直接对应 Trail of Bits 创始人 Artem Dinaburg 在 2026-08-26 那篇《VMs won't contain cyber-capable agents》里得出的结论——普通 VM 已经不能容纳能力足够的 AI 智能体。但 Coop 的解法与 Dinaburg 那篇文章给出的"当作 APT 对待"的方向略有不同:Coop 选择不试图在普通 VM 里"防御 Agent 突破",而是接受"Agent 在 VM 内做它想做的事,VM 销毁时一切消失"的现实。
第二条假设是 Coding Agent 的真实威胁面是"对宿主机的影响",而不是"Agent 自身的产出物"。Coop 的设计不关心 Agent 写出来的代码是否安全、Agent 的推理是否被 prompt injection 污染,它只关心 Agent 不能把宿主机搞坏——具体来说,Agent 不能读取 ~/.aws/credentials、不能读取 ~/.ssh/、不能修改宿主机的文件系统、不能向公网发数据。这条关注点的取舍,让 Coop 的实现复杂度大幅低于"试图在 VM 内做内容层过滤"的方案。
第三条假设是一次性 microVM 的销毁成本可以忽略不计。Coop 用的是 Apple Virtualization Framework(macOS 14+) / Lima + QEMU(Linux)/,每次 Agent 启动都创建一个全新的 VM,Agent 完成任务后 VM 立即销毁。VM 创建时间在 macOS 上约 1.2 秒,在 Linux 上约 3.5 秒,这个延迟对开发体验的影响可以忽略不计。
二、Coop 的具体架构
Coop 的架构由四个独立组件构成。
第一个组件是 microVM 运行时。Coop 在 macOS 上用 Apple Virtualization Framework 创建 macOS guest VM,在 Linux 上用 Lima + QEMU 创建 Linux guest VM。VM 启动后立即挂载一个只读的基础镜像(基于官方 macOS Sequoia / Ubuntu 24.04),Agent 跑在这个基础镜像之上。基础镜像里预装了 Node.js、Python、Rust、Go、Claude Code、Codex CLI、git、curl、ripgrep 等开发工具,覆盖 95% 以上的 Coding Agent 工作流。
第二个组件是文件系统隔离。Coop 用一个 9p 文件系统共享让宿主机的当前工作目录挂载进 VM,但只读。Agent 在 VM 内读宿主机的代码、读 git 历史都通过这个只读挂载点。如果 Agent 要写文件,必须写到 VM 内部的临时文件系统,VM 销毁时这些临时文件随之消失。如果用户想"采纳 Agent 的修改",由宿主机的 wrapper 脚本从 VM 提取 patch,应用到宿主机的工作目录。
第三个组件是网络隔离。VM 默认没有任何出站网络权限。Agent 需要联网时,必须通过 VM 内的一个 HTTP 代理,代理由宿主机的 wrapper 控制——只允许白名单域名(如 api.anthropic.com、api.openai.com、github.com、registry.npmjs.org),其他域名一律拒绝。这条限制是硬限制,Agent 在 VM 内无法绕过。
第四个组件是 secrets 隔离。宿主机的 ~/.aws/credentials、~/.ssh/id_rsa、~/.config/gcloud 等敏感凭据完全不会进入 VM。Agent 在 VM 内执行需要访问云服务的任务时,必须通过 VM 内的另一个专用代理调用——这个代理在宿主机运行,通过 IRSA / Workload Identity / OIDC token exchange 拿到真实凭据,只把"操作结果"返回给 Agent,绝不把"凭据本身"返回给 Agent。这条设计直接对应 Anthropic containment 报告里强调的"Agent 永远不接触真实凭据"原则。
三、Coop 与 YoloAI 的对比
Coop 的设计思路与 Kstenerud 在 2026-08 发布的 YoloAI 有相似之处,但实现路径不同。YoloAI 选择"完全消除 permission prompts + disposable container + 用户最后审 diff",Coop 选择"VM 内全权运行 + 宿主机完全隔离 + 用户从 wrapper 采纳修改"。两者都接受"Agent 在执行环境内做任何事",但工具切面不同。
YoloAI 的切面是"用户最后审 diff",适合"用户想看 Agent 改了什么再决定是否采纳"的场景;Coop 的切面是"Agent 跑在隔离 VM 里,改动在 VM 内完成,宿主机只接收最终 patch",适合"用户不关心 Agent 中间过程,只想拿到最终结果"的场景。
两者都跳过了"每一步工具调用弹窗让用户确认"的传统交互模式,这是 2026 年下半年 Coding Agent 工具链设计的共同方向。这条方向的工程逻辑是:每步弹窗的 HITL 模式已经被证明不可靠(HITL 权限疲劳研究显示 33% 恶意命令被无脑 Allow),企业 IT 必须把"信任扩张"放到工作流级别而不是工具调用级别,Coop / YoloAI / OpenCode Auto Permissions / dbward / Claude Secure VM 都是这条方向上的不同实现。
四、Coop 在多 Agent 协作场景下的工程含义
Coop 的隔离模型对多 Agent 协作场景有特别的意义。当企业部署多个 Coding Agent 协同工作时(比如一个 Agent 写代码、一个 Agent 写测试、一个 Agent 跑 CI),每个 Agent 跑在独立的 VM 里,VM 之间通过宿主机的 wrapper 协调。如果其中一个 Agent 的 VM 被突破,突破的影响范围被严格限制在该 VM 内,不会扩散到其他 Agent 或宿主机。这条隔离边界与之前讨论的 AgentConnect 思路(每个 Agent 独立身份、独立权限空间)是高度一致的。
Coop 在多 Agent 场景下的另一个工程价值,是它给"Agent 之间的信任边界"提供了具体的实现路径。Agent A 完成的工作 patch 通过 9p 文件系统共享传递给 Agent B,Agent B 在自己的 VM 内读这个 patch、写新代码;Agent B 的输出又通过宿主机的 wrapper 传给 Agent A。这条工作流实现了"Agent 之间的工作流是文件级别的,而不是进程级别的",即便 Agent B 的 VM 被突破,攻击者也只能读到 Agent A 的最终 patch,读不到 Agent A 的推理过程、CoT、prompt 等敏感信息。
五、Coop 的局限与未解决问题
Coop 在它的 README 里明确列出了当前的局限,这与 Trail of Bits 一贯的"诚实的工程披露"风格一致。
第一个局限是 macOS-only 的优化。Coop 的 microVM 运行时在 macOS 上体验最好(Apple Virtualization Framework 的 native 性能 + 1.2 秒启动时间),在 Linux 上启动延迟较慢(3.5 秒),在 Windows 上不支持(没有 native virtualization framework)。这条限制对 Windows 重度用户来说是个实际门槛。
第二个局限是 secrets 隔离的运维负担。Coop 把"Agent 访问云服务"这件事通过专用代理做了一层抽象,这意味着用户在初次配置 Coop 时需要为每个云服务(AWS、GCP、Azure、Snowflake 等)配置 IRSA / Workload Identity / OIDC token exchange。这条配置比"Agent 直接持有 ~/.aws/credentials"复杂得多,运维团队的负担会显著增加。
第三个局限是性能开销。Coop 的 VM 启动 + 文件系统共享 + 网络代理都有 5-15% 的性能开销,对于"Agent 跑大型 monorepo 的构建"这类场景,15% 的性能开销可能让 Agent 的 wall-clock 翻倍。Coop 的文档里建议把这类场景的 VM 预热、镜像缓存做更激进的优化。
第四个局限是 Agent 工作流的"中段审查"无法做。Coop 的设计让用户只能"采纳最终 patch 或丢弃整个 VM",无法在 Agent 工作中段插入人工审查。如果一个 Coding Agent 的任务是要重构一个大型 monorepo 的核心模块,中段可能产生几十次代码修改,Coop 不允许用户在第 10 次修改时暂停、审查、第 15 次修改时再继续——用户只能在 100% 完成后一次性审查。
六、对企业 IT 的具体启示
第一条,任何 Coding Agent 部署都应当用 Coop 或等价方案把 Agent 跑在隔离 VM 里。"Agent 跑在用户的本地工作站"是 2025 年的默认部署方式,在 2026 年下半年已经不应该作为生产级部署的可选项。即便是小团队 / 个人开发者,也应当把 Agent 跑在 disposable VM 里,因为 Agent 的真实威胁面(读取 ~/.aws/credentials、修改 ~/.ssh/、向公网发数据)在普通工作站上完全无防御。
第二条,把 secrets 隔离作为 Coding Agent 部署的硬性要求。Coop 把这条要求用"专用代理 + IRSA / Workload Identity"实现,其他 Coding Agent 平台应当照搬这条设计。任何让 Agent 直接持有 ~/.aws/credentials、~/.ssh/id_rsa、API token 的部署方式,在 2026 年下半年都不应当作为生产级选项。
第三条,把"Agent 在 VM 内能联网哪些域名"作为白名单管理。Coop 的网络隔离设计是企业 IT 可以直接照搬的——所有 Coding Agent 出站请求都必须经过网络代理,代理按白名单放行。任何不在白名单上的域名,Agent 完全无法访问。这条限制看起来"严格到不必要",但实际上它是把 Agent 的攻击面从"整个公网"压缩到"白名单内的几个服务",压缩比例在 99% 以上。
第四条,把 Coop 这类隔离 VM 沙箱作为 Coding Agent 平台的 baseline,而不是可选高级功能。在 AISI 9 月发布的 Agent Sandbox Escape Benchmark 里,9 个主流模型在 Docker 配置下的逃逸尝试率 4.7% - 23.4% 之间,即便在 Firecracker + Workload Identity 下仍有 3.1% - 14.1%。任何生产级 Coding Agent 部署,如果不在 Coop 这类隔离 VM 沙箱里运行,都应当被视为"实验性部署",而不是"生产级部署"。
第五条,把"VM 销毁时状态随之消失"作为 Coding Agent 部署的核心约束。Coop 把这条约束用"microVM + 一次性基础镜像"实现,它意味着 Agent 跑完一个任务后,VM 内积累的所有状态(临时文件、git 改动、下载的依赖、prompt 历史、CoT)都随之消失,Agent 下一次启动从干净环境开始。这条约束让"Agent 状态污染"这类攻击完全失效,与 Summer Yue 邮件误删事故的"上下文压缩吞掉红线"形成强烈对比——后者是"Agent 状态持续保留"的副产品,前者是"Agent 状态一次性销毁"的安全基线。
Trail of Bits 开源 Coop 这件事,把"AI Agent 真实安全边界"这件事从厂商自陈 + 学术论文 + 零散事件复盘推进到了"可对照、可采用、可二次开发"的工程基线。它与 AISI 基准、Anthropic containment 报告、Manifold GitSpawn、Snyk agent-scan、Decispher 长任务持久化、AC2 Protocol、OpenCode Auto Permissions 等 2026 年下半年密集产出的 Agent 安全工具一起,共同构成了"AI Agent 时代的企业级安全工程基线"。任何在 2026 年下半年开始认真落地 Coding Agent 的企业,都应当把 Coop 类的隔离 VM 沙箱作为"先安装、再谈业务"的基础设施,而把 Coding Agent 平台的能力评分放在基础设施到位之后再做。