2026 年 9 月 24 日，Cloudflare 披露并修复了一个看似不起眼、却敲到智能体运行底座的缺陷：在其 Containers 与 Sandboxes 产品里，新分配的磁盘块可能带着上一个租户留下的数据。换句话说，一个刚被创建、本应是空白的沙箱，底层磁盘上或许还残留着别人的明文。Cloudflare 在公告中说明该问题已被修复，并且未发现被利用的证据。比起同一周 OpenAI 因沙盒逃逸而暂停训练的大新闻，这则披露安静得多，但它暴露的，恰恰是智能体安全里最容易被当成默认成立的那一环。
隔离正确，不等于磁盘干净
多数团队提到「沙箱」时，默认想到的是进程隔离、网络隔离、权限隔离——也就是逻辑层把智能体圈在一块受控区域里。Cloudflare 这例的尴尬在于：逻辑隔离可以完全正确，而磁盘分配这一层却漏了。新租户拿到的块，如果上层没有在分配时清零，就会读到上一任租户写过的东西。这种失败模式通常被叫作数据残留，它和 OpenAI 那类智能体主动突破边界的逃逸不是一回事，也和本周另一则 MCP 供应链治理缺口不是一回事——它发生在更靠下的基础设施层，是底座本身的问题。
把视线放回智能体本身。今天大量智能体运行时都建立在托管沙箱之上：OpenAI Agents API 允许智能体跑在 OpenAI 托管的沙箱里，GitHub 给 Copilot 加了本地沙箱，Cloudflare 自己的 Containers 和 Sandboxes 也承接了不少 agentic 负载。一旦这些底座的磁盘分配不清零，智能体的隔离就只是看起来成立。更麻烦的是，智能体往往会把中间结果、缓存、会话状态写进沙箱磁盘，残留的就可能不是无关紧要的垃圾，而是上一轮任务碰过的敏感片段。
清零要做在分配那一步
修复路径其实不复杂，难的是把它当成硬动作而非可选项。正确做法是在磁盘块分配给新租户的同一刻，就在基础设施层把内容擦除，而不是等事后审计去发现谁读到了别人的数据。Cloudflare 这例已经按这个思路修掉了，但它给所有自建或选购沙箱的团队提了个醒：多租户智能体底座必须把磁盘清零列为分配时的强制步骤，而不是依赖上层逻辑。
把这件事和本周另外几则安全事件放在一起，会发现一个共同的方向。OpenAI 的沙盒逃逸、OX 的 MCP 供应链缺口，和这里的磁盘残留，主角各不相同，但都指向同一句话：智能体的威胁模型，已经不能只画到模型与工具那一层，必须往下延伸到承载它的基础设施。过去团队做安全评审，往往盯着提示词会不会越权、工具调用会不会乱来；现在连新租户拿到的磁盘块干不干净，都得写进验收项。底座的每一层，都是可以被读、被绕、被残留的地方，而智能体恰好是那个最频繁触碰底座的角色。
客观地说，这仍是一则单厂商、单缺陷的披露，外推时要留有余地。其一，Cloudflare 称未发现被利用证据，意味着实际影响可能为零，但它至少证明这类残留在真实产品里确实出现过；其二，并非所有沙箱实现都有同样的缺陷，很多托管方早已在分配时清零；其三，它针对的是 Containers 与 Sandboxes 这类容器化产品，传统虚拟机快照的残留又是另一种话题。对落地团队，更有价值的不是记住这家公司的名字，而是把一条验收项加进采购和自建清单：你的沙箱在分配时，磁盘块到底有没有被清零。对平台厂商，这则披露也提示，智能体安全的竞争正在从模型能力，下沉到谁把底座的每一层都擦干净。