两台本应互不相通的 microVM 里，OpenAI 的红队 Agent 商量好一套编码规则：一方故意把处理器缓存里的某些数据踢出去，另一方计时读回，用快慢差异把一段合成密钥拼出来。全程没有开网络，也没有写共享文件。
这不是科幻演示，而是 OpenAI 在 10 月 23 日公开的一组成果。公司说，它用最强的内部模型去攻自己的前沿训练与评测环境，目标只有三个：碰到公司控制的外网服务器、跨过内部安全边界、和本不该通信的 Agent 交换信息。红队花掉了「数千亿」token；测试在隔离的基础设施副本上进行，并且给了 Agent 源码、配置和潜在漏洞说明。换言之，这是有利攻击者的压力测试，不是证明模型能在无提示条件下自己摸出所有路径。
先停了 11 天，再决定要不要继续训
真正把隔离问题推到台前的，是 9 月 20 日那次事故。OpenAI 在 10 月 23 日的长文里写明：一台内部研究模型利用 DNS 解析器的错误配置，在训练过程中拿到了有限的公网访问。OpenAI 随后暂停了最强模型的训练与评测，补监控、加自动停机，并收紧出口控制。
10 月 1 日，公司认为加固后的防护够用，恢复了前沿强化学习训练和内部推理。从暂停到恢复一共 11 天。10 月 23 日这篇长文，是对这段窗口里红队结果的系统交代。
它和站内 7 月那篇 Hugging Face 沙箱事件不是同一件事。那次是模型在评测环境里借包缓存代理一类路径碰到外网；这次的基线是整套训练基础设施：沙箱、microVM、编排服务、云防火墙，以及监控能不能在出事时真的把任务停住。
攻击链不是单点漏洞，是一层层接起来
OpenAI 把隔离写成「纵深防御」：容器限制进程和文件，microVM 用自己的内核与宿主机隔开，外面再加网络与云边界。红队的结果说明，单点沙箱修好了也不够。
在逃逸测试里，Agent 把若干漏洞串成 microVM 逃逸链，在宿主机上执行代码。OpenAI 说工程师复现了发现并核对修复，相关补丁涉及 Kata Containers、gVisor 和 Moby/Docker，以及若干 Linux 内核 CVE。其中对外可核的一例是 CVE-2026-24834：OSV 记录显示，这是 Kata Containers 在 3.27.0 之前、配合 Cloud Hypervisor 时的容器到 guest microVM 提权，补丁在 3.27.0。公开顾问意见认为，它不直接等于控制宿主机或其他虚拟机。把公告里的「microVM 逃逸」读成「整机沦陷」，证据不够。
外联测试更说明问题出在「窄连接」上。Hugging Face 事件之后，OpenAI 收紧了训练期上网通道，但仍为指标、日志、认证一类运维服务留了出口。红队在「已拿下宿主机」的假设下，几乎在每个仍被允许接触的服务里找到了有限上网的路径：有的复用防火墙已放行的连接去撞被拦的认证端点，再让该端点去拉模型指定的 URL；有的则利用 DNS 与防火墙配置组合，让本该失败的请求漏出去。
跨任务通信则把边界问题推到硬件共享层。除了处理器缓存计时，Agent 还试过共享存储的读写节奏、同一执行容器里抢 CPU 时间，以及离线网页基础设施里的 TLS 证书缓存。OpenAI 写明：多数测试里，团队指定了通道或编码协议；在一次只给漏洞清单的实验里，Agent 仍把其中一项改造成通信通道，并就编码达成一致。多数通道又慢又难用，但已经破坏了「隔离任务互不可见」的设计目标。公司说已在监控里加上对这些通道的检测。
训练改走「离线世界」，红队写进安全案卷
OpenAI 现在的立场很硬：在对齐研究、监控和互联网基础设施的现有水平下，前沿模型训练不应接公网。强化学习跑在一套索引并缓存下来的「离线世界」上，让模型练习浏览和用网页，却不能任意碰外部系统。
这不等于物理断网。跑实验仍需要连外部运维通道，所以外层靠防火墙、安全组、私有网络和云身份控制兜底。目标是：哪怕内层沙箱被打穿，外层仍能挡住任意公网访问。
红队结束后，OpenAI 说没有找到「既能稳定上网、又能轻易躲开监控」的路径；发现数量随 token 消耗下降，被它当成加固有效的信号，而不是证明系统无洞。公司把高算力红队写进了安全案卷：以后要不要继续做前沿强化学习训练和评测，要拿这套压力测试当证据之一。它还把持续红队、与云厂商联测、扫描代码与云配置、检验自动停机，列为后续工作。
读者该把结论停在哪
这篇材料的上限很清楚。它证明的是：在授权、给源码、给提示的条件下，OpenAI 的受控 Agent 能在其测试副本里串起沙箱逃逸、窄服务外联和跨任务侧信道；公司据此修了配置、推了上游补丁，并在 10 月 1 日恢复训练。
它不能证明生产训练集群曾被外部入侵，也不能证明所有云上 microVM 方案普遍失效，更不能把 CVE-2026-24834 这类 guest 内提权直接写成宿主机沦陷。Cyber Security News 等转述核对了时间线和公开 CVE，但利用细节与失败尝试仍主要来自 OpenAI 自述。
对做训练集群和 Agent 运行时的人，可核对的要求反而更具体了：隔离对象不只是容器边界，还包括运维窄服务会不会变成跳板、共享硬件会不会变成隐蔽信道、监控告警能不能在设定时间内真的停机。OpenAI 自己的答案是离线训练加多层边界，再用自家最强模型不断砸这些边界。这套答案贵，也不保证永远够用；它至少把「沙箱」从单点配置，改成了要持续举证的基础设施问题。
