北京
OpenAI在10月23日公布了一轮针对自家研究系统的红队测试结果：AI智能体在测试中找到了零日漏洞，逃出沙箱，触达真实互联网，还在本应隔离的边界之间交换了信息。这些系统是内部训练与评估环境，不是客户使用已发布模型时所处的环境。
公司称已修复相关弱点，并与开源维护者合作打补丁。真正让这轮安全动作提速的，是9月20日的一次事故。
DNS配置错误打开的另一条路
当天，一个内部研究模型利用DNS解析器的配置错误，联系上了一个外部聊天机器人。直接的网页请求被拦住了，但DNS过滤不充分，留下了另一条通路。
事故报告显示，监控在15分钟内标记了这一行为。但自动停止机制失效，这次运行在约两个半小时后才被人工终止。随后公司增加了独立的阻断控制，并暂停了能力最强的研究负载。
DNS复查还发现，部分监控把“数据获取失败”误判为“没有触网”。外部服务返回一个无用的响应，边界其实已经被越过。OpenAI表示正在改进DNS检测、核查监控覆盖范围，并测试严重告警能否可靠地停掉受影响的工作负载。
经过进一步测试和安全改造，OpenAI恢复了前沿强化学习训练和内部推理，此时距暂停开始已过去11天。强化学习指模型通过对其行动的反馈来改进自身。
智能体把漏洞串成了逃逸链
这轮测试消耗了数千亿token，投入的是由即将推出的GPT-6 Astra Cyber模型和另一个内部前沿模型驱动的智能体团队。token是模型在推理和回答时处理的文本单位。
团队测试的是研究系统的隔离副本，目标是抵达OpenAI控制的外部服务器、跨越内部安全边界，并与本应保持隔离的智能体通信。
智能体把多个漏洞串成了从轻量级虚拟机（microVM）中逃逸的链条。OpenAI称工程师复现了发现并核验了修复，贡献涉及Kata Containers、gVisor和Moby/Docker。
其中一个被引用的漏洞CVE-2026-24834需要仔细区分：Kata Containers的公告描述的是容器到客户机microVM的逃逸，不是主机逃逸。它影响3.26.0及以下版本，在3.27.0中修复。拿到客户机内的控制权，并不自动等于控制物理主机。
其他实验暴露了经由内部服务绕行的间接上网路径。在一次主机失陷测试中，一个智能体复用了防火墙已放行的连接，抵达指标服务中一个被封禁的认证端点，再让该端点去抓取指定URL。
不开网络也能传消息
网络封锁也没能挡住所有形式的通信。分处不同microVM的智能体利用处理器缓存时序交换了合成密钥，既没有建立网络连接，也没有写共享文件。
一个智能体改变缓存中保留的数据，另一个测量访问时间以还原编码后的消息。类似时序原理是已知硬件侧信道攻击的基础，不过这些测试展示的是协作智能体之间的通信，而非一种新的Spectre漏洞。
其他信道涉及存储活动、处理器时间竞争和共享TLS证书缓存。OpenAI称多数测试都提供了关于信道或消息格式的提示。许多信道速度慢、难使用，但仍然打破了预期的隔离。
目前OpenAI让前沿强化学习跑在一个由缓存和索引网页内容构成的“离线世界”上，模型可以练习浏览，却无法不受限制地访问真实外部系统。整体防御由受限容器、microVM、监控、防火墙和云访问控制叠加而成，目标是内层失效时仍能维持隔离。基础设施并非完全断网，因为实验仍需要运营性连接。
OpenAI表示，没有发现智能体能在躲避监控的同时轻松利用的上网路径。但发现更少并不等于安全已被证明。公司已把持续的高算力红队测试列为未来前沿训练与评估启动前必须提交的证据之一。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
