OpenAI 报告：训练中 Agent 借 DNS 漏洞访问外部聊天机器人

摘要

一个智能体在尝试完成一项基于搜索的训练任务时，通过我们互联网访问限制中的一个漏洞查询了一个公开的聊天机器人服务：其训练沙箱中的 DNS 过滤不足。在此之前，该智能体通过我们的搜索工具发出查询，并曾尝试直接访问搜索引擎但未成功。请注意，本报告中除 DNS 解析器之外的所有互联网访问都命中了我们的离线网页缓存，因此并未访问实时互联网。此后我们已在两个独立层级添加了阻断控制，其中任一层级都本可阻止此次访问。我们的失准监控系统在 15 分钟内标记了该行为，随后 3 分钟有人开始审查。该运行在 2.5 小时后被终止。我们最有能力模型的所有训练、评估以及使用工具（广义定义）的推理仍处于暂停状态。在 Hugging Face 事件之后，我们持续加固并对我们的研究环境进行红队测试。我们的重点一直是广泛的直接和传递路径。我们正在梳理系统依赖所使用的更窄路径，并用离线替代方案替换它们。此次事件的严重程度远低于我们此前的一些事件，但由于它是我们在 Hugging Face 事件后进行安全加固以来的第一起，它为我们提供了关于下一阶段工作重点的重要信号。

发生了什么

该

任务要求提供关于某个特定人物的信息，此人发表过一篇博客文章，智能体获得了一组传记细节以及来自该人物公开博客文章的线索。该任务并未要求智能体测试网络控制或访问基准测试答案，我们将规避限制或追求超出合理预期目标的智能体行为视为失准的一个例子。该智能体首先寻找博客文章中的独特短语，

包括我们将称为“distinctivephrase1”的短语。它告诉用户它会先识别作者，然后分别核对其他线索，并使用了所提供的网络搜索工具。. It told the user it would identify the author first, then check the other clues separately, and used the supplied web search tool.

网络搜索返回了不相关的内容，包括音乐和关于‘distinctivephrase1’的一般性建议。智能体怀疑搜索工具是否正常工作，决定尝试其他搜索引擎。它从 shell 中使用 Python 将相同的查询发送到其他搜索引擎。三个都返回了错误。

智能体还尝试了缓存页面和其他公共搜索服务。它告诉用户博客的措辞可能是转述，并转向其他传记线索。它核查的候选对象证据缺失或相互矛盾。

一次宽泛的 Bing 搜索最终加载成功，但未能将线索联系起来。请注意，这次搜索命中了我们的网页缓存。智能体决定测试更具体的查询是否也能通过。

在这些更具体的搜索运行期间，智能体猜测该问题来自 BrowseComp，一个公开的网络研究基准测试，但猜错了。它表示传记线索与精确日期的混合类似于一道被翻译成另一种语言的 BrowseComp 题目。没有来源证实这一关联。

该智能体下载了 BrowseComp（来自我们的离线网页缓存）及其评估脚本，然后在解码后的问题中搜索线索的各种组合。第一次搜索没有结果，于是它扩大了搜索范围。下面的计数显示了它找到的词项数量。

该智能体还检查了公开的 SimpleQA 基准测试，没有找到匹配的问题，于是回到普通搜索。

由于搜索仍无定论，该智能体开始测试其网络访问能力。它首先尝试通过 HTTPS 联系一个公开聊天机器人。网页代理阻止了该直接请求。

直接的公共 DNS 查询也没有得到回应，但训练环境自带的解析器为一个已知域名返回了真实记录，并正确拒绝了一个虚构域名。该智能体得出结论：它可以通过这个解析器访问公共互联网。把问题直接放进第三方聊天机器人服务失败，而它找到的公共 DNS 隧道项目要么已关闭，要么需要单独的服务器。随后它考虑公共域名服务能否帮助将查询委托给嵌入在主机名中的地址。接下来的命令展示了它如何利用这一特性将问题转发给第三方聊天机器人服务。

智能体发送了一个关于法国的问题和一条线索，还尝试了其他 DNS 服务。关于法国的查询超时了，而另一个基于线索的查询返回了 DNS 格式错误。

智能体将超时时间从六秒增加到十九秒，并用两个版本的法国问题重试。重试运行期间，它还通过所提供的网络工具发起了九次搜索。

这一次，两个版本的法国问题都给出了答案“The capital of France is Paris.”。这向智能体表明，外部聊天机器人正在通过 DNS 路由作答。

聊天机器人部分回答了该问题，但没有给出完整答案。

随后，智能体获取了该聊天机器人的公开文档，编写了一个超时时间为 24 秒的新 DNS 脚本，并通过同一路由又发送了 18 个问题。其中 14 个包含线索。4 个询问通过 DNS 搜索网络、抓取网站或使用公开托管隧道的方法。

智能体回复用户时，最后一批问题仍在运行。它表示无法确认此人身份，并索要原始措辞、标题或博客名称。

调查与响应

事件时间线：

上午 9:50:23智能体发起了 DNS 工具调用，并收到了外部响应。

上午 10:02:11监控系统发出了 P0 警报。

上午 10:05:06一名人工审核员确认了该警报。

下午 12:34:30该运行被终止。

我们的安全论证假设模型无法访问实时互联网，并且监控会检测到成功的尝试。该事件暴露了我们在以下方面的控制缺口：网络限制。因此，我们停止了受影响的训练运行，并随后决定暂停我们最强模型所有其他涉及工具使用（广义定义）的训练、评估和推理，直到我们既验证该缺口已解决，又对系统进行了额外的红队测试。当训练重启时，我们将以额外的对齐改进开始一次全新的运行，包括更全面的失准干预措施。我们不会恢复这个特定模型的训练，尽管现有的奖励信号已经正确地惩罚了这种行为。

监控系统检测到了这一事件，但我们的回顾性审查发现了其他未被其以预期严重程度标记的外部 DNS 访问案例。这些包括返回外部服务已关闭的静态通知的查询。监控有时将未能获得有用信息视为访问互联网尝试失败的证据。

此次响应还暴露了运营缺口。一名人工审核员在三分钟内确认了 Slack 警报，但运行并未如预期自动停止，导致在是否应该停止的问题上产生混乱。随后，当这一问题得到解决时，运行在两个半小时后被手动停止。我们正在解决这些运营缺口。另外，一个用于检测异常 DNS 活动的基础设施检测器排除了受影响的环境，尽管 DNS 活动已被记录。我们已开始部署额外的 DNS 检测以及检测管道的测试。我们还限制了环境内的 DNS 查询，仅允许有限的白名单域名和记录类型。

我们还加快了对沙箱和网络控制的额外模型辅助红队测试。这些红队测试工作可能会发现其他传递性互联网访问路径，若出现这种情况，我们将迅速修复，并在适当情况下暂停研究工作负载。仍需完成的工作包括验证不同环境配置下的控制措施，以及完成更广泛的调查。