2026 年 9 月,Trail of Bits 在 GitHub 上开源了 Coop——一个用 Rust 写的 CLI 工具,专门解决一件事:让 Claude Code 和 Codex 这种 Coding Agent 跑在一个完整隔离的虚拟机里,Agent 在里面拥有 Docker、git、编译器、包管理器等所有工具的完全访问权限,但完全不影响宿主机安全。每个 VM 都是临时的、可重现的、创建与
2026 年 9 月,Trail of Bits 在 GitHub 上开源了 Coop——一个用 Rust 写的 CLI 工具,专门解决一件事:让 Claude Code 和 Codex 这种 Coding Agent 跑在一个完整隔离的虚拟机里,Agent 在里面拥有 Docker、git、编译器、包管理器等所有工具的完全访问权限,但完全不影响宿主机安全。每个 VM 都是临时的、可重现的、创建与销毁成本都很低。这件事的工程意义在于:Agent 的运行环境隔离从"同一台机器上的另一个用户"升级到"完整的虚拟化边界",Agent 能做任何它需要做的事,但它的破坏半径被严格限制在一个能随时丢弃的虚拟机里。这是 2026 年下半年 Coding Agent 走向团队化、生产化时必须补齐的关键基础设施。
Coop 与之前讨论过的 OneCLI、NanoClaw、WebMCP 是同一条主线上的不同切面:OneCLI 在网络层把凭据关进网关,NanoClaw 在容器层做运行时隔离,WebMCP 在协议层让 Agent 与网站协作,而 Coop 在虚拟机层把整个 Agent 运行边界圈定。四个项目分别解决了 Agent 治理中"凭据/网络/工作区/外联"四个独立维度,共同构成 2026 年下半年 Agent Harness 的工程新基线。下面是 Coop 给企业 Agent 落地带来的 10 个具体启示。
1. 隔离边界放在 VM,而不是容器或用户
Coop 的核心隔离边界选择非常清晰:guest VM 本身就是边界。在 Linux 上用 Firecracker microVM,在 macOS 上用 Lima VM(Apple Virtualization.framework)。这个选择的原因被写在文档里——VM 是 Agent 整个生命周期最自然、最干净的爆破半径单位:Agent 在里面拥有 passwordless sudo、bypassPermissions 模式,这些权限在 VM 内部不是边界,因为整个 VM 就是边界。
对企业 Agent 治理来说,这条边界选择有直接含义。容器隔离(像 NanoClaw 的 Docker 方案)对很多用例够用,但对 Coding Agent 这种"需要全工具权限、可能跑任意命令、需要安装任意包"的工作流不够干净——容器共享宿主内核,容器内的 root 在某些场景下能逃逸到宿主机。VM 隔离把边界提到硬件虚拟化层,即使 Agent 完全失控,它的破坏也只在 VM 内部。代价是启动稍慢、资源占用略大,但这是值得的安全成本。
2. 双后端编译期选择,不引入运行时分支
Coop 的后端设计有两点关键决策。一是 Firecracker(Linux 上)和 Lima(macOS 上)两套实现并存,分别针对 KVM 与 Apple Virtualization.framework 优化。二是后端选择是编译期决定,通过 #[cfg(target_os = "macos")] 这种 attribute 切换,而非运行时枚举——这意味着没有运行时分支开销,共享代码在两个后端上同时被编译验证。
这种设计的工程意义远超表面。它要求共享代码必须同时为两个后端工作,这意味着任何只在某个后端能跑的特性都不会进共享层。这是一种把"兼容性"前置到编译期的纪律——当你要加新特性,必须让它在两套 VM 后端都跑通,而不是"先在 Linux 上跑,以后再补 macOS"。对企业 Agent 工具链来说,这种纪律是跨平台工程质量的保障。
3. Typestate 把"VM 是不是在跑"从 flag 提升到类型
Coop 的最精巧设计之一是用 Rust 的 typestate 把 VM 的生命周期建模进类型系统。RunningInstance 与 StoppedInstance 是有私有字段的不可伪造证明,只能由 as_running 与 as_stopped 这两个 probe 函数铸造;任何要求 VM 在跑(或停)的操作都通过值接收这个证明,前置条件被检查一次,然后被类型见证。FirecrackerVm
这条工程决策的实际意义是:Coop 永远不会写出"VM 看起来在跑但实际不在"的代码,也不会写出"VM 已经销毁但还尝试操作它"的代码。这不是文档约束,是编译器约束。对企业 Agent Harness 的启示是:Agent 运行环境的状态机应该有同样的强约束——不是"运行时检查"而是"类型不让你写错"。这种约束从工具链层面消除了一类常见 bug。
4. Secret 永远不进 argv,永远不写进日志
Coop 在 secret 跨边界时的处理是教科书级别的。它定义了五条铁律:secret 永远不进 argv(否则会出现在 ps 与 /proc),只能走 SSH SendEnv 或 stdin;GITHUB_TOKEN 默认是关闭的,只有显式 opt-in 才转发,且转发后通过 gh auth setup-git 写入 git credential helper——这是持久化的 guest 状态,任何 guest 进程都能读;secret 文件永远是 0600 权限,目录 0700 权限,通过 atomic_write_with_mode 写入绝不放松权限;secret 永远不进日志,Cmd::redacted_arg 在 trace 里 redact,EnvForward/Secret 自定义 Debug 不输出值;config.toml 只存 cmd: 检索命令,token 本身从不内嵌。
这套铁律对企业 Agent 治理的启示是,凭据卫生不是"我们尽量小心",而是工程纪律。每条规则都应该落到代码约束上:argv 编译期检查、日志 redact 自定义 Debug、文件系统权限 atomic write 不降级。这些都是机械可验证的护栏,远胜于团队规范文档。
5. 代理模式让凭据完全留在 host
Coop 在更新的版本里引入了代理模式:开启后,ANTHROPIC_API_KEY 与 OPENAI_API_KEY 根本不转发给 guest——host 端的 coop-proxy 持有真实凭据,guest 只拿到一个 per-instance 能力 token。这与之前讨论的 OneCLI 思路完全一致,但在 VM 隔离层又进了一步:即使整个 VM 被攻破、Agent 完全失控,真实的模型 API key 也不在 VM 里,攻击者拿到能力 token 也只能用、不能取走。
对企业的启示是,凭据隔离应该按"防御深度"分层。OneCLI 解决"Agent 拿不到凭据",Coop 代理模式解决"即使 Agent 拿到 VM 内全部状态也拿不到真实凭据"。两层叠加,即使攻击者突破一层,第二层仍能保护最敏感的资产。这种"多重独立防御"的工程思路,是企业 Agent 治理的标准做法。
6. Guest 永远是不可信的
Coop 的 trust model 文档里有一条反复出现的纪律:把 guest 当作不可信,即使是你自己启动的。这条纪律的具体含义是,guest 输出的所有内容——文件内容、文件名、符号链接、命令输出——一旦穿越回到 host,就成为污染源。最危险的污染渠道是 guest 文件系统 pull 到 host(workspace.rs 里的 rsync/tar 拉回),它把 guest 完全控制的内容、文件名、符号链接全部放进 host 文件系统——这是最宽的 guest→host 通道,也是路径穿越和符号链接逃逸的主要落地点。
这条工程纪律对企业 Agent 治理的启示是,任何把 Agent 产生的数据回传到 host 的路径都需要被当作潜在攻击面处理。这不只是 Agent 安全问题,这是经典的 trusted/untrusted 数据流问题——只是"untrusted"现在是 Agent 而不是互联网用户。
7. 自我更新有完整验证链
Coop 的 update 命令做了一件非常严肃的事:它从固定 repo 拉 release metadata,下载平台 tarball 与 SHA256SUMS 与 attestations.jsonl,然后用 Sigstore 验证 attestation(优先走 gh,fallback 到 attestations API)。这是供应链安全的标准做法——每个 release 都有可验证的密码学证据,不是"相信发布者"。同时每次替换是原子的,CLI 与 proxy 不是单一事务但每次都原子。
对企业的启示是,Agent 工具链自身的供应链安全也是治理对象。一行 curl | bash 是开发者友好的安装方式,但默认不可信——Coop 用 Sigstore attestation 让这条管道可验证。任何面向生产部署的 Agent 工具链,都应该用类似的密码学证据链来证明"我下载的就是源作者发布的"。这是 Agent 时代的基础设施层面的"信任根"问题。
8. 与现有 devcontainer 标准互通
Coop 实现了对 devcontainer.json 的解析与翻译。devcontainer.json 是 VS Code 等工具定义开发容器的事实标准,大量项目已经写了 devcontainer 配置——Coop 通过 devcontainer.rs 与 devcontainer_oci.rs 把这些配置翻译成自己的 VM 配置,并支持从 OCI registry 拉 devcontainer Features。这让现有项目的 Agent 化路径接近零摩擦。
对企业的启示是,任何新立的 Agent 标准都应该尊重已有标准,而不是另起炉灶。Coop 没有要求用户重写 devcontainer 配置,而是把它翻译进来。这种"互操作优于替代"的工程态度,是 Agent 工具能进入企业生产环境的关键——企业不会为了一个新工具扔掉已有的标准化投入。
9. Workspace 同步在两个后端上不同
Coop 在 workspace 同步上有意做了后端差异:Firecracker 走一次性的 rsync/tar 同步(mounts_are_live=false),Lima 走 virtiofs live mount(mounts_are_live=true)。Lima 因为虚拟化框架支持 live mount,所以可以实现 host 与 guest 文件系统实时同步;Firecracker 没有这个能力,所以走批量同步。这是有意的工程权衡——文档里明确标注这是"已知的故意分歧",而非 bug。
对企业的启示是,跨平台工程不应该被"完全一致"绑架,而应该尊重每个平台的原生能力。Coop 在 macOS 上给用户更好的体验(Live mount 是巨大便利),在 Linux 上给用户足够的能力(批量同步),而不是为了统一牺牲其中一方。这种"在协议层一致、在实现层尊重平台"的工程纪律,是高质量跨平台工具的标志。
10. Coop 不是替代 NanoClaw,而是补齐最后一公里
Coop 的 GitHub 文档把它和 NanoClaw 的关系说得很清楚:NanoClaw 解决运行时隔离,每个 Agent 跑在自己的容器里有自己的文件系统与进程空间;Coop 用 VM 替代容器,提供更硬的隔离边界。两者解决的是同一类问题的不同深度——NanoClaw 给"够用",Coop 给"更强"。对真正把 Agent 用于生产链路的企业来说,Coop 这种 VM 级隔离是更稳的选择,因为它彻底消除了容器共享内核带来的潜在逃逸面。
对企业的启示是,Agent 隔离不是"有就行",而是有清晰的层级谱系。Docker 容器适合沙箱内调试、低风险自动化;MicroVM(Firecracker、Cloud Hypervisor)适合生产环境的关键业务;独立物理机适合最敏感的数据处理任务。Coop 把 MicroVM 这层带到了 Coding Agent 工作流,让原本属于云服务商的隔离能力进入了开发者本机。这是把"云端安全基线"普及到"个人开发者桌面"的关键工程进展。
可执行清单:从今天开始的企业 Agent Harness 建设
把 Coop 给出的 10 个启示压成可执行清单,一家认真对待 Agent 安全的团队应该从今天开始做这些事。第一,选 VM 而不是容器作为生产 Agent 隔离边界,MicroVM 应该是默认假设,容器只用于开发与调试。第二,把凭据卫生落到代码约束上:不进 argv、不进日志、文件权限 atomic、token 不内嵌,每条都对应一个具体的工程实践。第三,采用代理模式让真实模型 key 完全留在 host,guest 只拿能力 token,即使 VM 被攻破也拿不到真实资产。第四,把 guest 当作不可信,所有 guest→host 数据流(workspace pull、命令输出、devcontainer 解析)都是潜在攻击面。第五,任何 agent 工具链自身的更新都应该带密码学验证链(Sigstore attestation 或类似机制)。第六,新立的 Agent 标准应该尊重已有标准(devcontainer、MCP、AGENTS.md),而不是另起炉灶。第七,跨平台差异不强行统一,允许在实现层尊重每个平台的原生能力。第八,把 Agent Harness 建设当作工程基础建设而非个人工具,每个决策都要经过代码审查而非个人偏好。第九,在隔离、凭据、审计、供应链四个独立维度同时投入,而不是在某一层深度建设。第十,持续关注 Trail of Bits、NanoClaw、OneCLI、WebMCP 这些项目的演进,它们共同构成 Agent Harness 的工程基线,任何企业 Agent 落地都应基于这套基线扩展。