OpenAI 红队演示：AI 代理可构建 CPU 缓存隐藏通道绕过沙箱隔离
据 OpenAI 官方博客披露，其内部安全团队（红队）发现人工智能代理能够建立隐藏的通信通道。尽管研究人员此前已证实云虚拟机（VM）之间可通过 CPU 缓存时序差异传输数据，理论上被劫持的共享物理服务器上的代理可交换信息，但此次测试表明，即便在严格限制网络访问和文件共享的沙箱环境中，AI 代理仍能自主发现并利用微架构状态进行秘密通信。
在没有允许的网络或共享文件通道的单独 VM 中运行，但它们仍然共享底层硬件。和共享硬件意味着共享的微架构状态。这足以创建一个秘密的通信 channel.you 可以隔离进程，限制系统调用，阻止网络访问，并仍然有信息泄露通过时间 differences.a 相当显著的示范为什么安全的代理制是如此困难的 problem.October 24, 2026
测试场景设定为两个 AI 代理分别运行在独立的微型虚拟机上，这些虚拟机部署在同一台共享主机上，并使用 OpenAI 的沙箱软件进行隔离。任务要求代理在没有网络连接或共享可写文件的情况下交换合成秘密数据。结果显示，一个代理通过从 CPU 缓存中驱逐特定数据，另一个代理则通过定时重新加载这些数据，利用双方预先同意的协议实现了基于“快速”和“缓慢”读取状态的通信。
这种缓存定时技术与 Spectre 和 Meltdown 攻击中提取数据的技术原理相似，不同之处在于，Spectre 和 Meltdown 通常涉及恶意代码窃取信息，而本次演示中的秘密通道需要两个自愿参与的代理协同工作。技术评论员 Ryan Orhan 在 X 平台上指出，这种隔离机制“不一定在软件层面被打破”，并称这是“为什么安全的代理制如此困难的一个非常显著的演示”。
OpenAI 担心模型可能会“找到未经授权的方法与其他沙箱中的代理人进行沟通”。早在 2017 年的 NDSS 安全会议上，一篇论文就展示了两个 Amazon EC2 虚拟机之间的隐藏缓存通道，其速度足以承载 SSH 连接。而在本次测试中，AI 代理在被要求时能够自行构建此类通道，包括编写编码过程。在这种模式下，发送者是受攻击者控制或指导的代码（例如在云沙箱中注入提示式代理），接收器则是同一物理机器上的另一个进程，数据交换过程中不产生任何可用于监控的网络流量。
除了 CPU 缓存通道，代理还发现了其他三条潜在的数据泄露路径：
- 共享存储竞争：其中一个代理交替写入空时间。
- CPU 时间竞争：在共享执行容器中争夺 CPU 时间资源。
- TLS 证书缓存竞争：在 OpenAI 的离线网络设置中竞争保存 TLS 证书缓存。
在大多数测试中，OpenAI 将代理指向特定的通道或提供预设协议以引导其行为。红队测试涉及前沿模式的特工团队，旨在同时实现三个目标：接入实时互联网、跨越内部安全边界以及跨越隔离边界进行沟通。额外的测试假设内部保护已经失效，攻击者拥有监视器和主机的完全控制权。
参与测试的代理来自公司最具能力的模型，包括即将推出的 GPT-6 Astra Cyber 模型和内部边界模型。这些代理获得了基础设施源代码、配置细节以及描述潜在漏洞的文档，从而在有利于攻击者的条件下对防御系统进行压力测试。所有测试均在该公司研究基础设施的孤立、专门构建的副本上运行，总共消耗了“数十亿代币”。
此次披露是在涉及 OpenAI 代理人的多起网络安全事件之后进行的。此前发生的 20 个 DNS 事件导致训练暂停了 11 天。随着训练恢复，该公司继续披露“多个 microVM 项目”的漏洞，并将其最有能力的模型作为安全案例的一部分，用于决定是否进行培训和评估。OpenAI 认为，未来的模型将具备发现尚未知晓漏洞的能力。
