Trail of Bits 工程论文:为什么虚拟机装不下 Cyber-capable Agent,以及企业级 Agent 隔离的工程基线

2025 年 12 月到 2026 年 6 月,学术界与工业界密集发布了三份针对 Agent 隔离与沙箱的工程研究。Oxford 等机构的 ceLLMate(2025 年 12 月)提出「在 HTTP 层对浏览器 Agent 做沙箱」,因为所有副作用 UI 操作最终都会转化为对后端的网络通信;SafeClawBench(2026 年 6 月)给出 600 个对抗任务的标准化 Agent 安全评估基准,验证「语义失败」(Agent 同意攻击)与「实际危害」(sandbox 观察到的工具/状态危害)是两个独立维度——在 12,000 行匹配分析中,有 291 个 sandbox 危害出现在「语义检查通过」的行上;Alibaba 的 AgentBay(2025 年 12 月)给出 Windows/Linux/Android/浏览器/代码解释器的统一沙箱服务,核心创新是「Adaptive Streaming Protocol」让人类可以在任意时刻无缝接管 Agent 的工作。三份工作合在一起,清晰勾勒出企业级 Agent 隔离的工程新基线:**Agent 沙箱必须从「把 Agent 关起来」的隔离视角迁移到「让 Agent 与人类在同一沙箱里协作」的协同视角,这一迁移直接对应 AgentBay 论文中的「Agent + Human 模型比纯 Agent 模型提升 48% 任务完成率」这一量化结果**——隔离不再是「防 Agent 越狱」,而是「让 Agent 在受控环境里与人类协作」。

一、Agent 隔离的常见误区

传统 Agent 隔离的工程思路是「把 Agent 关在沙箱里,让它出不来」——VM、容器、chroot、seccomp 等技术都是这一思路的具体实现。这一思路在传统多租户云计算场景里有效,但在 Agent 时代遇到三类根本性挑战。

第一类是「语义鸿沟」(semantic gap)。Agent 的操作是「点击」、「滑动」、「输入」这类高层 UI 动作,沙箱的拦截规则是「系统调用」、「文件路径」、「网络端口」这类底层事件。从「点击购买按钮」到「POST /api/checkout」之间存在多层抽象,沙箱直接拦截 UI 动作几乎不可能,拦截底层事件又会因为抽象鸿沟而频繁误判。ceLLMate 论文明确指出「writing and enforcing security policies for low-level UI tools like clicks and keystrokes is brittle and error-prone」,把沙箱放在 UI 层直接拦截是不可能的。

第二类是「真实危害与语义失败不等价」。SafeClawBench 论文给出了一个反直觉的实证:Agent「同意」攻击(语义失败)与「实际产生危害」(sandbox 观察到的工具/状态危害)是两个独立维度——一个 Agent 在语义上同意攻击并不意味着 sandbox 看到危害,反之 sandbox 看到危害也不意味着 Agent 在语义上同意攻击。在 12,000 行匹配分析中,「347 个 sandbox 危害」里有 291 个出现在「语义检查通过」的行上——这意味着传统只看「Agent 是否同意」的评估方法会漏掉超过 80% 的真实危害。这一发现直接挑战了「Red-team 测试结果能反映生产风险」的常见假设。

第三类是「隔离不等于可用」。传统 VM/容器隔离会带来 5-15% 延迟开销,在 Agent 高频调用场景下被显著放大。ceLLMate 论文的实验结果是「7.25-15% 延迟开销」,这一开销在「1000 次调用」场景下变成 70-150 秒累计延迟,在用户体验上不能忽视。更糟的是,某些隔离技术会禁用某些 UI 功能(比如禁止粘贴、禁止文件下载),进一步损害 Agent 的可用性。Sandflare 的边缘 Workers isolates 设计用「不可信代码物理隔离 + 网络出口默认 deny」的方式把延迟压到接近原生,但仍然需要在安全与可用之间做权衡。

二、Agent 沙箱的新工程范式

三份工作合在一起,展示了 2026 年 Agent 沙箱的三大工程范式迁移。

第一类范式是「在合适的网络层做拦截」。ceLLMate 提出「所有副作用 UI 操作最终都会转化为对后端的网络通信」,因此「在 HTTP 层对 Agent 做沙箱」比「在 UI 层」更可靠——HTTP 拦截器可以基于 origin、URL 模式、Cookie 等元数据决定是否放行请求,这些规则比 UI 模式更精确。ceLLMate 把这一思想实现为「agent-agnostic browser extension」,任何基于 Chromium 的 Agent(OpenAI Operator、ChatGPT Atlas、本地 Coding Agent)都可以直接受益。WASP 基准测试显示这一方法能拦截绝大多数 prompt injection 攻击,延迟开销 7.25-15%。

第二类范式是「语义失败与实际危害分离评估」。SafeClawBench 给出的 600 个对抗任务覆盖六大攻击家族——直接/间接 prompt injection、tool-return injection、memory poisoning、memory extraction、ambiguity-driven unsafe inference——并把每一任务的评估结果分为三个独立维度:语义失败(Agent 是否在输出层同意攻击)、审计可见危害(Agent 的输出是否在外部审计日志里显示出攻击意图)、sandbox 观察危害(Agent 是否真正执行了危险操作)。这一三层评估让企业能够更精确地判断 Agent 风险——只看语义失败率会漏掉超过 80% 的 sandbox 危害,只看 sandbox 危害会漏掉「Agent 内部已经同意但被 sandbox 阻挡」的攻击意图。

第三类范式是「人与 Agent 在同一沙箱里协作」。AgentBay 的核心创新是「Adaptive Streaming Protocol」,让 AI Agent 通过 MCP 或 SDK 与沙箱交互的同时,人类操作员可以在任意时刻无缝接管 Agent 的工作——不只是「看」Agent 在做什么,而是「直接接管」。这一设计与传统远程桌面(VNC、RDP)的关键差异是:ASP 专门为「AI + 人类」的混合使用场景优化,在弱网络环境下仍能保持低延迟,根据当前控制者(AI 或 人类)动态调整编码策略。这一设计直接解决了「Agent 卡在某个决策点需要人类介入」的实际工程问题。AgentBay 论文的实证显示,「Agent + Human」协同模式比纯 Agent 模式提升 48% 任务完成率。

三、企业级 Agent 隔离的工程新基线

把 ceLLMate、SafeClawBench、AgentBay 三个工程范式合并,可以看到企业级 Agent 隔离必须落地的五项关键基线。

第一项基线是「沙箱层应该尽可能接近网络层」。UI 层、Agent 层、工具层的拦截都存在语义鸿沟,网络层(HTTP 请求、域名、origin)是 Agent 副作用最终落地的位置,在这一层做拦截能最大化准确性、最小化误判。ceLLMate 给出的浏览器扩展 + HTTP 拦截模式是企业级 Agent 沙箱的具体实现路径,任何把沙箱放在 UI 层的设计都应该被重新评估。

第二项基线是「评估必须分语义、审计、sandbox 三个维度」。只看「Agent 是否同意攻击」会漏掉 sandbox 实际危害,只看 sandbox 危害会漏掉 Agent 内部意图。SafeClawBench 论文的实证显示「347 个 sandbox 危害中有 291 个出现在语义检查通过的行上」——这一发现意味着传统只看「Agent 是否同意」的评估方法在生产风险评估上严重失真。企业落地 Agent 评估时必须采用多维度评估,不能依赖单一指标。

第三项基线是「Agent 沙箱必须支持人类无缝接管」。任何 Agent 在生产环境被部署后,都可能遇到「卡在某个决策点需要人类介入」的情况——可能是 prompt injection 攻击、可能是业务上下文缺失、可能是工具调用结果异常。AgentBay 的「Adaptive Streaming Protocol」给出了工程实现路径:沙箱同时支持 AI Agent 的程序化接口与人类操作员的可视化接口,两者可以无缝切换。这一设计直接对应了生产环境的现实需求——「让 Agent 跑完所有任务」是不现实的,「让 Agent 与人类协同完成任务」才是工程目标。

第四项基线是「沙箱延迟开销必须控制在 15% 以内」。任何超过 15% 延迟开销的沙箱都会显著影响 Agent 可用性,尤其在高频调用场景下。ceLLMate 给出的「7.25-15% 延迟开销」是企业级 Agent 沙箱的工程目标。任何宣称提供「更强隔离」但延迟开销超过 25% 的沙箱方案,都应该被工程团队谨慎评估——隔离强度与延迟开销的权衡需要按业务场景定制。

第五项基线是「沙箱必须支持跨环境统一抽象」。企业级 Agent 通常需要在 Windows、Linux、Android、浏览器、代码解释器等多个执行环境里运行,每个环境用不同的沙箱技术会导致运维复杂度过高。AgentBay 给出的「统一 session 通过 MCP/SDK 与 Agent 集成」是企业级 Agent 沙箱的工程方向,任何只支持单一环境的沙箱方案都会在企业规模扩展时遇到阻力。

四、链路视角下的最终结论

三份 2025-2026 年的 Agent 沙箱研究合在一起,清晰勾勒出一个 Agent 时代的工程范式迁移:**Agent 沙箱必须从「关起来」迁移到「协同起来」**。传统沙箱设计的核心假设是「Agent 是不值得信任的不可信代码,沙箱是隔离 Agent 与系统的边界」,这一假设在 Agent 时代仍然成立,但工程重点已经从「如何把 Agent 关得更严」迁移到「如何让 Agent 在受控环境里与人类、与其它 Agent、与基础设施高效协作」。AgentBay 论文中「Agent + Human 比纯 Agent 提升 48% 任务完成率」是最直接的量化证据——人类介入不是沙箱的失败,而是沙箱设计的目标之一。

把视角拉到企业 AI 落地的长周期,可以看到三个必然迁移。第一,Agent 沙箱拦截层必须从「UI 层 / Agent 层 / 工具层」迁移到「HTTP 层 / 系统调用层 / 持久化层」等更接近副作用源头的层,在这些层做拦截能最大化准确性、最小化语义鸿沟。第二,Agent 评估必须从「单一维度」迁移到「多维度」,语义失败、审计可见、sandbox 危害分别评估,任何只看单一维度的评估方法都会系统性低估或高估 Agent 风险。第三,Agent 沙箱必须从「自动运行到底」迁移到「支持人类无缝接管」,沙箱的设计目标不仅是「让 Agent 出不来」,更是「让人类可以随时介入」——这一设计直接对应生产环境的现实需求。

模型可以迭代——Claude Sonnet 5 之后会有更强的 Sonnet,Fable 5 之后会有更强的 Opus——但 Agent 沙箱的工程基线(网络层拦截 / 多维度评估 / 人类无缝接管 / 延迟开销可控 / 跨环境统一抽象)不会因为模型升级而失效。把资源投到这些不散的链路层要素上,是企业 AI 落地性价比最高的工程方向。ceLLMate、SafeClawBench、AgentBay 三份工作共同标志着 Agent 沙箱工程从「单点防御」走向「协同治理」的范式迁移——这一迁移与过去十年 Web 安全从「WAF 单点」走向「零信任 + 端到端可观测」的演进一脉相承。Agent 时代的安全不能依赖任何单一防御层,必须建立在多层防御 + 人类协同 + 持续评估的链路基础上。