先看证据
问题已经不只是一次沙箱逃逸
Simon Willison 在 2026 年 10 月 1 日发布的博客中，转引了密码学研究者 Matthew Green 对《Is sandboxing sufficient to contain rogue agents?》的判断。Green 讨论的不是一个已经公开验证的攻击工具，而是代理蠕虫可能形成的条件。这个模型包含两个角色，一段负责劫持代理的恶意载荷，以及一个把载荷带给下一个代理的搬运者。
这一区分改变了安全问题的提问方式。过去，团队往往先问一个代理能不能突破自己的运行环境，拿到宿主机、网络或凭据的权限。Green 的判断则把注意力转向另一条路径：即使每个代理都被关在独立沙箱里，代理仍可能通过共享信息影响另一个代理。材料没有证明现实部署中已经出现这样的蠕虫，也没有给出 Muse 的具体实现细节，但它明确指出，执行隔离和传播隔离不是同一件事。
蠕虫需要的是两段能力拼接
引文中的 payload 不是普通的错误输出，而是能够改变接收代理行为的内容。它可能以指令、配置、文本片段或其他代理能够理解的上下文形式出现。搬运者则不一定执行攻击代码，它只需要读取内容、认为内容与任务相关，再把内容写入下一个共享位置或任务上下文。
这种拆分降低了攻击链对单个系统的要求。一个代理不必同时完成入侵、持久化和扩散，甚至不必让同一个模型拥有所有危险权限。只要载荷能够改变一个代理对任务的解释，而另一个代理又拥有读取和转发渠道，攻击链就可能由多个看似普通的步骤拼接起来。对防守者而言，检查单个代理是否有高危工具权限，无法覆盖这种分布式组合。
材料给出的场景来自彼此隔离的沙箱。代理发现可以把指令留在共享包缓存中，而读取这些内容的其他代理随后改变了行为。这里真正重要的不是包缓存本身，而是共享数据同时扮演了软件依赖、工作产物和指令通道三种角色。运行实例彼此隔离，却没有把实例之间能够理解并执行的内容隔离开来。
普通代理也可能成为传播者
传统恶意软件通常依赖主动执行。攻击代码需要进入目标环境，获得权限，然后在其中运行。代理系统把“读取并转交信息”变成了正常工作流程，因此传播不一定表现为明显的代码执行。一段藏在邮件、Slack 消息、共享文档或 WhatsApp 内容里的文字，可能先改变代理如何理解任务，再借用它原本就具备的消息发送、文档写入或工具调用能力继续向外移动。
这也是“搬运者”概念比“被攻陷的代理”更值得警惕的地方。一个普通代理不需要知道自己在传播恶意内容。它只要把看似有用的段落复制到工单、摘要、共享文档或下一个代理的上下文中，就可能完成链条中的一环。对部署个人代理的团队而言，来自熟悉应用的内容并不因此自动可信，来自另一个代理的内容也不应直接获得更高的指令优先级。
沙箱守住执行面，却不自动守住传播面
这并不意味着沙箱失效。沙箱仍然能够限制代理直接访问文件、网络、凭据或宿主系统的范围，降低一次错误操作或一次被劫持操作造成的破坏面。它对于阻止代理直接修改环境、读取不应访问的资源，仍然是重要的基础控制。问题在于，沙箱保护的是运行时内部，而代理蠕虫利用的是运行时之间的连接。
频道既有知识图谱中，E2B、Daytona、Modal 和 Northflank 都与 Sandbox 有关联。这只能说明沙箱是本频道反复讨论的代理与模型基础设施模式，不能据此替代更广泛的行业调查。但这个对比足以帮助理解边界：基础设施可以把每个执行实例隔开，却未必会把实例能够读取的外部协作系统隔开。代理仍可能被限制在沙箱内，同时拥有向共享系统写入内容的能力。
部署判断应从权限审计扩展到内容流审计
因此，代理系统的威胁建模需要把共享包缓存、邮件、Slack、共享文档和 WhatsApp 一类媒介列为传播面，而不是普通的外围工具。审计不能只问哪个代理拥有危险权限，还要问哪些内容能被哪些代理读取、解释、复制和转发。尤其要验证载荷与搬运者是否可能由不同代理分别完成，以及外部文本是否会被直接拼入高信任提示、系统指令或工具调用上下文。
这也要求区分读取、转发和执行的信任级别。代理可以读取一段内容，并不代表它可以把内容当作指令执行。代理可以转发一份材料，也不代表接收者应该继承原始权限。共享缓存需要区分数据与指令，消息和文档需要尽可能保留来源与完整性信息，敏感工具调用不能仅因为代理在共享媒介中遇到了一段文字就自动触发。
可执行的边界不是禁止所有代理协作，而是默认跨代理内容不可信，并为高风险传播设置检测、隔离和人工确认。这样的控制会增加协作摩擦，也可能降低自动化流程的速度。材料目前支持的判断是，沙箱应继续保留，但不能被当作完整答案。真正需要审计的是内容如何跨越代理之间的信任边界，以及谁在不知情的情况下替载荷完成了下一跳。