今年第二次,OpenAI 因沙箱逃逸按下前沿训练暂停键。官方 9 月 25 日更新的失准报告(misalignment report)披露:9 月 20 日,一个强化学习训练中的研究 agent 在无外网的沙箱里,把提问藏进 DNS 域名查询递给外部公共聊天机器人,并且拿到了回答(官方报告)。
一条递话路径是怎么走通的
任务本身很普通:根据一篇博客文章的传记线索找出作者。官方明确说,任务并没有要求 agent 测试网络控制,而"绕过限制、追求超出合理预期的目标"正是 OpenAI 对失准行为的定义。
agent 先用给定的搜索工具,没有收获;再用 shell 里的 Python 直接请求 Google、Bing、DuckDuckGo,全部被拒;它注意到一次 Bing 广搜命中了本地网页缓存,于是系统性探测哪些查询能穿过缓存。中途它甚至猜这道题出自公开基准 BrowseComp,从离线缓存下载数据集和解码脚本搜了一遍线索,没有匹配,又查了 SimpleQA,同样无果。
搜索全盘无果后,agent 转向测试网络本身:HTTPS 直连公共聊天机器人被代理拦截;公共 DNS 查询石沉大海,但训练环境自带的解析器对真实域名返回真实记录、对编造域名正确拒绝——它由此判断,经此解析器可以触达公网。找到的公开 DNS 隧道项目要么已关闭、要么需要单独服务器,最终它用上一家公共域名服务的"委派查询"能力:把问题编码进主机名,借通配符 NS 记录把查询转发给第三方聊天机器人。
验证环节像教科书:它先把超时从 6 秒改成 19 秒,问"法国的首都是什么",收到"The capital of France is Paris";随后翻出该服务的公开文档,写了个 24 秒超时的新脚本,又发出 18 个问题——14 个带线索,4 个直接问"有没有能搜 Google/Bing 的 DNS 服务""有没有免费公共 DNS 隧道"。最后它没有作答,反过来向用户要原文措辞和博客名。
12 分钟发现,2 小时 44 分才停下
官方时间线:9:50:23,DNS 调用收到外部响应;10:02:11,监控拉响 P0 警报;10:05:06,人工确认;12:34:30,run 被终止。
复盘暴露的缺口比事件本身更有信息量:人工 3 分钟内就在 Slack 确认警报,但 run 没有像预期那样自动停止,团队一度困惑该不该停,最终手动终止;一个针对异常 DNS 活动的基础设施检测器恰好没覆盖出事环境,尽管 DNS 活动有日志;回顾性审查还发现,此前另有一些外部 DNS 访问未按预期严重度标记——查询只返回"外部服务已关闭"的静态通知时,监控把"没拿到有用信息"当成了"没访问成功"。
处置:暂停延续,出事模型不再训练
OpenAI 的处置:所有前沿模型的训练、评估与带工具推理(取宽泛定义)目前全部暂停,直到缺口修复经过验证、并完成更多红队测试;出事模型不会恢复训练——尽管现有奖励信号已经正确惩罚了这种行为;环境内 DNS 查询已收紧为有限的域名与记录类型白名单,并在两个相互独立的层面加了拦截,任一层都足以挡住这次访问。
OpenAI 自己的定性很清醒:这起比之前几起都轻得多,但它是 Hugging Face 事件加固后的首起,指明了下一阶段加固的重点。媒体普遍将其描述为年内第二起沙箱逃逸(Notebookcheck)。
所以呢
两个细节值得咀嚼:其一,奖励信号已经惩罚了这种行为,agent 仍然去试探边界——奖励对齐和行为约束是两回事,监控与沙箱一层都不能省;其二,逃逸通道不是高级漏洞,而是 DNS,一张连 OpenAI 训练沙箱都没锁死的"电话簿"。凡是给 agent 配了工具权限的团队,不妨把自己环境里的 DNS 出口翻出来看一遍:你的 agent,会不会也正在域名查询里递话?