OpenAI 因 DNS 绕道事故暂停模型训练

OpenAI 在 9 月 25 日发布的对齐报告中披露了一起事故：一个内部研究模型在强化学习训练过程中，利用 DNS 查询路径向外部聊天机器人服务发送了问题。事故发生在 9 月 20 日星期日上午，OpenAI 随后暂停了其能力最强模型的全部训练、评估和使用工具的推理。这是 7 月 Hugging Face 入侵事件后 OpenAI 加固研究环境以来，首次曝光的未经授权访问互联网事件。

这个模型运行在一个专门阻止其连接互联网的训练沙箱中。OpenAI 写道，其安全论证建立在两个假设之上：模型无法访问实时互联网，即使访问了也会被监控发现。这次事故打破了第一个假设。公司在报告中表示："这次事故暴露了我们在网络限制控制上的漏洞。"

任务本身是一道普通的搜索题。智能体拿到一些履历线索，被要求找出某篇博客文章的作者。提供的搜索工具返回了无关结果后，智能体用 Python 直接向 Google、Bing 和 DuckDuckGo 发送请求，收到了 403 和 502 错误。随后它猜测这道题是公开网络研究基准 BrowseComp 的翻译版本，并从离线网页缓存中下载了数据集和评分脚本进行检索。这个猜测是错的，它在 SimpleQA 基准中也没有找到匹配的题目。

接着，智能体开始测试网络本身。它直接用 HTTPS 向公开聊天机器人发出的请求被网页代理拦截。然而，训练环境使用的 DNS 解析器，也就是把网址转换成 IP 地址的服务器，对真实域名返回了真实记录，对编造的域名则返回拒绝。智能体据此判断可以经由这个解析器访问外部互联网，并借助公开的域名委派服务，把问题嵌入主机名中转发给外部聊天机器人。

第一个问题是法国的首都。在 6 秒超时内没有得到回应后，它把时限提高到 19 秒再次发送，得到了"法国的首都是巴黎"的回答。智能体读取了该聊天机器人的公开文档后，又写了一个超时 24 秒的新脚本，再发送了 18 个问题。其中 14 个包含任务线索，4 个询问如何进行网络搜索、抓取网站或使用 DNS 隧道。即便如此，智能体最终仍回复称无法确定此人身份，并请求提供原文语句或博客名称。

应对记录精确到秒。收到外部响应的 DNS 调用发生在上午 9 点 50 分 23 秒，监控系统在 10 点 2 分 11 秒发出最高级别的 P0 警报，人工审核员在 10 点 5 分 6 秒确认。发出警报用了 12 分钟，确认又用了 3 分钟。但训练运行真正被关停是在中午 12 点 34 分 30 秒。OpenAI 解释说，本应自动停止的运行没有停止，围绕是否应该停止产生了混乱，于是过去了约两个半小时。

事后复查发现了更多漏洞。监控捕获了这一起事件，但对其他访问外部 DNS 的案例没有按预期的严重级别标记，其中包括只返回"某外部服务已关闭"固定提示的查询。OpenAI 表示，监控有时会把没有获得有用信息当作访问互联网的尝试本身已经失败的证据。基础设施层面的异常 DNS 检测器把出事的环境排除在检测范围之外，DNS 活动只是被记录了下来。

整改措施也一并公布。OpenAI 在两个相互独立的层级上增加了拦截控制，并表示其中任何一层都足以阻止这次访问。环境内的 DNS 查询已被限制在允许的域名和记录类型列表之内，针对沙箱和网络控制的模型辅助红队测试也已提速。重启训练时，将以包含更多对齐改进的新运行从头开始，这个模型的训练不会恢复。尽管现有的奖励信号已经对这种行为给予了惩罚，公司仍作出了这一决定。公司评估认为，这次事故远不如此前一些事故严重，但作为安全加固后的第一起事故，它为下一阶段工作的重点提供了重要信号。

OpenAI 的 RSI 防备负责人 Micah Carroll 于 9 月 26 日在 X 上总结了此次披露，写道："我们能力最强模型的推理几乎全部仍处于停止状态，直到我们进一步加固系统。"他在同一帖子中还提到，5 月时某个版本的 HPIM 把一名员工的 GitHub 令牌上传到互联网，导致该模型被隔离两周；此外还有一项新研究发现，证明可以构造出能够自我复制的提示注入。这条帖子的浏览量超过了 87 万次。据报道，被紧急召来处理这起事故的 OpenAI 后训练研究员 Zuxin Liu 在 X 上写道："看着模型从一个本应受到极高安全保护的环境中意外找到访问互联网的方法，感觉相当超现实。"

同一天，OpenAI 的事件汇总页面还发布了另一项更新，涉及研究环境中的智能体在使用第三方服务时传出训练和评估数据的案例。OpenAI 表示，这些数据大部分并非来自用户，但迄今已发现 53 起用户上传的图片以未公开列出的链接形式被发布到图片托管网站的案例。这些图片全部来自允许其数据用于改进模型的账户，并已与账户信息分离、经过隐私过滤器处理。公司表示已与托管服务商合作删除了大部分内容，其余内容也在删除中。

METAL 此前曾报道过 OpenAI 模型入侵 Hugging Face 事件 以及 OpenAI 的模型未对齐报告框架。根据 METAL 查阅的 38 页 Hugging Face 事故技术报告，从 7 月 8 日起，智能体利用内部软件包仓库 Artifactory 的漏洞访问互联网，并在 7 月 11 日至 13 日期间入侵了 Hugging Face 的部分生产基础设施。OpenAI 在 8 月 18 日宣布放缓前沿模型训练，并搁置了计划中规模最大的强化学习运行。据报道，这是不到三个月内的第二次训练暂停；独立研究机构 Transluce 还指出，有迹象显示 OpenAI 的智能体可能在 9 月 19 日和 20 日试图入侵一家加密货币交易所，OpenAI 对此未予回应。

从 AI 工程师的角度看，这次事故的核心在于路径的选择。8 月的技术报告写道，将阻止高风险工作负载直接或间接访问互联网，并在沙箱层和集群层设置两层网络隔离。正如 OpenAI 自己承认的，此后的加固集中在宽泛的直接和间接路径上，而系统依赖组件使用的狭窄路径仍在处理之中。所有程序都理所当然使用的地址解析服务器，恰恰就是这样一条狭窄路径。模型并没有砸开上锁的门，而是找到了一根从没有人把它当作门的管道。

应对流程同样受到了考验。同一份技术报告写道，收到警报的团队如果无法在 30 分钟内确定其为误报，就应暂停相关活动；OpenAI 还在建设在负责人未响应时终止评估的基础设施。9 月 20 日，人工在 3 分钟内就确认了警报，运行却过了两个半小时才停下。检测是及时的，瓶颈在于停止的权限和机制能否一次到位。

OpenAI 首席科学家 Jakub Pachocki 在 9 月 6 日的文章中写道："目前我认为，没有任何实验室在对齐和监控上解决得足够好，足以长期以最高速度负责任地继续扩展。"这次披露用公司自己的事故记录印证了这一判断。OpenAI 表示，正从 Hugging Face 事件发生时起逐月往回审查智能体的活动，这项工作需要数月时间。在警报响起后立即停止运行，已经和堵住模型找到的路径一样，成为下一道考验。