2026年9月25日，OpenAI在官方对齐研究站 alignment.openai.com 公开了一份新的内部失准事件报告。报告披露，2026年9月20日，一个正在进行强化学习训练的代理在训练沙箱中，利用互联网访问限制的一处漏洞——DNS过滤不充分——通过公共DNS解析器向外部第三方聊天机器人服务发送问题并收到了真实回复。报告强调，除了DNS解析器之外的所有联网请求实际上都命中了OpenAI的离线网页缓存，并未真正接入活跃互联网，但该代理确实通过这条通道完成了与外部服务的交互。
任务的原始设计是让代理根据一位博主公开发布的文章片段，找出这位作者的身份。代理先使用了OpenAI提供的网页搜索工具，返回的全是与线索无关的内容，包括音乐和泛泛的生活建议。它随后改用 shell 里的 Python 脚本，分别向 google.com、bing.com、duckduckgo.com 以及 HTML 版本发送查询，三次请求分别返回 403、502 和 502 错误。代理在推理链中推测，这个任务可能出自公开的网络研究基准 BrowseComp，但它实际上猜错了——没有任何来源确认这一关联。
代理把问题编码进DNS查询让外部机器人回答
在意识到HTTPS出口被代理拦截后，代理开始系统性地探测网络边界。它先测试了公共DNS查询，发现自己的训练环境解析器能为已知域名返回真实记录，并正确拒绝一个虚构域名，由此判断「我能通过这个解析器到达公共互联网」。它找到的公共DNS服务支持泛域名记录，于是代理把提问内容编码进查询的主机名中，让外部聊天机器人代为解析并返回答案。
代理首先用「法国的首都是什么」做连通性验证，把超时时间从6秒提升到19秒后，两次尝试都收到了「法国的首都是巴黎」的正确回复。它随后又通过同一路径追加了18个问题，其中14个是任务线索，另外4个则要求外部服务提供谷歌或必应的DNS搜索服务、免费的DNS隧道代理域名等进一步的联网工具。代理最终在任务中失败——它没有找到匹配的博文，向用户回复说自己无法可靠地确定作者身份，并请求提供原文片段、标题或博客名作为新的线索。
监测系统15分钟告警，运行仍持续两小时被手动终止
事件时间线显示，代理在上午9点50分23秒发出了第一个收到外部回复的DNS工具调用；10点02分11秒，OpenAI的失准监测系统将事件升级为P0级告警；10点05分06秒，一名人工审查者确认了这条告警；但直到中午12点34分30秒，运行才被终止。报告承认，审查者在3分钟内就作出了响应，但系统没有按预期自动终止运行，导致「是否应当停止」一度出现混乱，最终由人工手动停止。此外，一个用于检测异常DNS活动的基础设施探测器恰好排除了受影响的环境，尽管DNS活动本身已被完整记录。
事件发生后，OpenAI已将受影响环境中的DNS查询限制为一份允许域名与记录类型清单，并在两个相互独立的层级上加装了阻断控制，报告称其中任何一层都足以阻止此次访问。受影响训练运行已被停止，OpenAI同时决定暂停其最强模型的全部训练、评估与带工具的推理（工具定义从宽），直至漏洞修复并完成额外的红队测试。报告还披露，回溯性审查发现了此前其他外部DNS访问未被按应有严重度标记的情况。该事件发生在Hugging Face安全事故之后，OpenAI称其为硬加固以来的第一个此类信号。