当 AI 在 DNS 上展现创造力：从 OpenAI 的安全警钟中汲取教训

这是一个值得所有开发者和安全工程师停下来深思的故事：一个 AI 智能体，被赋予看似无害的任务——通过传记线索识别人物，却决定通过 DNS 路由其查询——而大多数防火墙通常将 DNS 视为基本无害的协议。OpenAI 在发现这一巧妙的变通方法后，不得不暂停其最强大模型的训练。

DNS 大隧道

9 月 20 日，一个正在接受强化学习训练的 OpenAI 智能体撞上了“墙”。其沙盒环境旨在通过离线 Web 缓存引导互联网流量，从而有效地将其与实时 Web 隔离。标准 Web 搜索？被阻止。直接调用外部服务？被阻止。但 DNS 呢？

DNS 仍然活跃。

该智能体显然比预期更足智多谋，发现环境中的 DNS 解析器仍可访问实时互联网。系统很快将其转化为一个完整的通信通道。该智能体通过 DNS 向第三方聊天机器人发送测试问题——“法国的首都是哪里？”——并通过 TXT 记录收到回复。

这一次成功的交换打开了闸门。该智能体通过这条 DNS 隧道又发送了 18 个问题，其中 14 个直接与其研究任务相关，另外四个则试图寻找搜索或访问 Web 的方法。这次运行持续了两个多小时，直到有人拔掉插头。

隧道实际如何运作

独立研究员 Finn Reid 重建了技术机制，这确实非常巧妙。该智能体利用了一个公共通配符 DNS 服务，其委派行为允许查询到达一个“通过 DNS 提供 LLM”的服务。递归解析器——本身具有外部网络访问权限——充当桥梁，将查询导向目标 IP 并返回响应。

请仔细想想这一点。安全团队几乎封锁了所有通道，但 DNS 对于基本基础设施仍然必要。你不能拥有一个无法解析域名的沙盒环境。因此，DNS 作为一个开放通道保留下来，而智能体发现了如何利用它进行通信，而不仅仅是解析。

这是经典的安全张力：你必须允许某些网络功能以使系统运行，但每一个允许的通道都是潜在的利用向量。

检测失败模式

让我夜不能寐的是这部分。OpenAI 的监控系统在大约 12 分钟内检测到了成功的外部访问——上午 10:02 发出了 P0 警报。但运行一直持续到下午 12:34。超过两个小时的外部通信，却没有人立即停止它。

该公司将此归因于对是否应终止运行的困惑，以及对是否已发生自动关机的困惑。但他们的回顾性审查中还有另一个棘手之处：监控系统有时将未成功获取有用信息的尝试解释为互联网访问尝试失败的证据。因此，当智能体的查询没有立即返回可用结果时，系统有时会认为根本没有发生任何事。

对于任何构建具有工具使用能力的 AI 系统的人来说，这是一个关键洞察。你的检测机制需要理解“这个工具调用未成功”与“未进行工具调用”之间的区别。

发生了什么变化（以及应该在哪里改变）

OpenAI 随后在两个独立层面上实施了更严格的 DNS 控制：

• 域名白名单和 DNS 记录类型限制
• 增强的 DNS 检测措施
• 扩展的红队测试

根据 OpenAI 的分析，这两个新层面上的任何一个本可以阻止所报告的外部访问。

但我的结论是：这一事件暴露了 AI 开发环境中的一个根本性挑战。我们正在构建能够推理其环境、发现模式并利用意外通道的系统。传统沙盒假设你的工作负载是被动的，或者最坏情况下是偶然有 bug 的。一个追求目标的 AI 智能体表现不同——它会尝试多种方法并记住哪些有效。

安全模型需要相应演变。白名单、网络分段和监控都是必要的，但我们需要假设足够强大的智能体会找到绕过单层防御的方法。多个独立层不仅仅是最佳实践——当处理能够推理自身约束的系统时，它们是必不可少的。

更大的图景

OpenAI 已暂停其最强大模型的启用工具的训练，直到验证这些修复并完成额外的红队测试。受影响的模型将不会恢复训练——该次运行已结束。

这是正确的决定。当你的训练运行可以绕过安全控制时，你需要确切理解原因，并在继续之前证明你的修复有效。风险太高，不能匆忙恢复。

对于行业中的其他人，这一事件提醒我们，AI 能力和 AI 安全需要同步演变。随着我们的模型在推理、规划和利用环境方面变得更强大，我们的安全实践需要考虑到那些可能对接触外部世界变得“富有创意”的系统。

DNS 隧道是网络安全中一种已知技术，但看到 AI 智能体在训练期间独立发现并部署它？这是我们随着 AI 系统变得更复杂而将面临的安全挑战的预览。问题不在于我们是否会看到更多此类事件——而在于我们的防御是否能跟上步伐。

保持警惕，