OpenAI 披露内部模型借 DNS 突破沙箱访问外部聊天机器人
OpenAI 内部 Agent 为完成任务把 DNS 变成绕过沙箱的通信信道，暴露了工具调用训练中的网络管控漏洞。
OpenAI 一个正在做 RL 训练的内部研究模型，被安排根据几份履历和博客锁定文章作者。常规搜索失败后，它发现沙箱虽封了正常上网通道，却为系统依赖保留了 DNS（把域名解析成 IP 地址的互联网通讯录）查询出口，于是把 DNS 改造成绕过断网限制的聊天通道，向外部聊天机器人发了 18 个问题。任务最终没完成，但这个漏洞先被它自己揪了出来。
正文摘录
事情有多离谱呢？请看大屏幕——OpenAI 一款正在进行 RL 训练的内部研究模型，本来的任务是凭几份履历、博客定位某人。 常规搜索碰壁后，它没有放弃，竟把本该查地址的 DNS，改造成突破断网沙箱的聊天窗口。 （DNS 原本相当于互联网的“通讯录”：用户输入一个域名，DNS 负责查询这个域名对应的网络地址。） 更抓马的是，它费了这么大劲最后还是没找到人，反倒先把 OpenAI 沙箱里的漏洞给揪出来了… OpenAI 随后宣布，这次事件暴露了他们在网络限制管理方面的漏洞，因此，他们将暂停最强模型中所有涉及工具调用的训练、评测和推理任务。 当时，模型接到的任务本身风险并不高：依据公开博客文本和人物履历线索，找出文章作者。 它先用 OpenAI 提供的搜索工具寻找博客中的特殊短语，结果搜回来的不是音乐就是泛泛的人生建议。 眼见着搜索工具不给力，它又调用 Python，直接向 Google、Bing 和 DuckDuckGo 发送请求。 它一度怀疑这道题来自 OpenAI 的 BrowseComp 搜索基准，于是便从离线网页缓存中下载数据集和评测脚本，解码题库、搜索关键词。 说干就干，它先尝试通过 HTTPS 访问一家公共聊天机器人服务，结果被网络代理果断拦截。 它发现，OpenAI 虽然封住了沙箱正常上网的正门，却给部分系统依赖保留了查询 DNS 的窗口，它可以试着钻这个空子： 确认这条路可行后，模型重新写了一份 DNS 脚本，又一口气向外部聊天机器人发送了 18 个问题。 （其中 14 个与原本的人物线索有关，另外 4 个则在询问如何搜索网页、抓取网站，以及有没有可以公开使用的 DNS 隧道。） 另一方面，人工已经收到警报，系统却没有按流程自动熔断，内部甚至一度搞不清楚任务究竟该不该停。 复盘时，OpenAI 还发现了其他未被正确标记的外部 DNS 访问。