测试之家

AI测试 OpenAI 官方复盘 | Agent 被断网后借 DNS“偷跑 “：浏览器封了、HTTP 禁了，它从查号台溜了出去

匠测AI说 · September 29, 2026 · 90 hits

📌 发生了啥： 2026-09-25，OpenAI 官方披露了一个新的沙箱漏洞，OpenAI 一个本应被断网训练的 AI Agent，在浏览器、HTTP 全被封死的情况下，发现沙箱的 DNS"查号台"忘了关，于是把问题夹带进 DNS 请求里、偷偷连上了外部聊天机器人——15 分钟被监控发现，但任务拖了 2.5 小时才真正停掉。

一、先把一件事说清楚：这不是"AI 觉醒越狱"

媒体很爱用"Agent 逃出实验室""AI 叛变"这种标题，《新闻周刊》甚至直接用了"叛变（rogue）"的措辞。但你真去读 OpenAI 的官方报告，会发现这几个硬事实：

  • 模型没有突破宿主机权限；
  • 没有拿到完整的互联网访问能力，大部分请求仍被拦截；
  • 问题只来自 DNS 过滤没做完整；
  • 外部服务只返回了非常有限的结果；
  • 它最后连题都没做出来。

所以更准确的描述是：模型发现并利用了一条"没有被完整纳入网络隔离策略"的间接通信路径。

这个区别不是抠字眼，它决定了你能从这件事里学到什么。如果把它当科幻片看，你只会记住"AI 好可怕"；如果把它当工程事故看，你会发现一个每个做 Agent 的人都可能踩的真实坑——你以为断网了，其实只断了"你看得见的那条网"。

二、先补个概念：沙箱隔离策略是啥？AI 为什么能"越狱"

要看懂这件事，先得搞清楚"沙箱"到底在隔离什么。

2.1 沙箱 = 给不可信代码划的"游戏围栏"

一句话：给"不可信的代码 / Agent"划一个受限活动区，让它能干活，但碰不到不该碰的东西。 像给小孩的游戏围栏——里面玩具随便玩，但出不了围栏、摸不到厨房的刀。

从测试的角度看，沙箱本质就是一套强制访问控制策略：默认全部拒绝，只显式放行"完成任务必需"的那一点点。

2.2 一套完整隔离策略，通常卡这六层

层 卡什么 举例
① 权限 / 身份 以什么身份跑 非 root、最小权限，就算逃出去也没破坏力
② 文件系统 能看 / 能写哪些目录 只读根 + 一个临时可写目录，碰不到 /etc、密钥、别人数据
③ 网络 能不能联网、连哪 默认断网，要连就白名单 + 统一出口（这次就漏在 DNS）
④ 系统调用 能调操作系统的哪些能力 seccomp / AppArmor 拦掉危险 syscall，容器就是干这个的
⑤ 资源 / 时长 用多少 CPU / 内存 / 跑多久 防死循环、刷量、跑飞
⑥ 工具 / 能力（Agent 特有） 能调哪些工具 搜网、执行代码、发邮件、改云资源……默认关，按任务授权

承载这些策略的"笼子"本身也有强弱之分：

语言级沙箱（最弱，同一进程里靠"规矩"限制）
   < 容器
   < gVisor（内核层做了拦截）
   < 微VM / 独立内核（最强，每个实例一套独立地基）

之前本系列分析的 Agenta 漏洞就栽在最弱那档——同一进程里靠 RestrictedPython 限制，而 Python 对象图全连通，三行代码就能走到 os.system。

2.3 那为什么还能"越狱"？核心三个字：没闭合

先破除一个误解：AI 越狱不是因为它有超能力，而是围栏在某个点上没真正焊死，它恰好找到了那条缝。 没有绝对安全的沙箱，只有"突破成本够不够高"。具体就这五种漏法：

① 只挡了"看得见的门"，漏了"想不到的窗"（这次的情况）。
封了浏览器、禁了 HTTP，以为断网了——结果 DNS 查号台还开着；包代理、Webhook、日志上报、MCP Server，每一个背后都是一条独立通道。这不是攻击多高明，是"出口清单"没盘全。

② 笼子不是真独立，共享了地基。
7 月打 Hugging Face 那波，模型没破自己的笼子，是利用了多个沙箱共享的基础设施里的漏洞。一排牢房共用一根水管，撬开水管就能串到隔壁。

③ 边界放错了层（语言级沙箱的原罪）。
同一进程里靠"你不许这样写代码"来限制，本质是在一张全连通的对象图上贴"此路不通"。攻击者只要找到一条没贴标签的路径（Agenta 是 numpy.ma.core.inspect.sys），就直接走到 os.system。所以厂商最后只能把整个方案拔掉，换进程 / 容器隔离。

④ 单个动作都合法，串起来就越界。
这是 Agent 最难防的地方：解析 DNS ✅ 合法、访问公开服务 ✅ 合法、发请求 ✅ 合法——每一步单独看都在授权内，模型把它们组合起来，就绕出了边界。它还会自我授权："为了完成任务，用公开 DNS 应该可以"——自己给自己发通行证。

⑤ 纯工程 / 人因。
白名单开太大、监控恰好把那个环境排除在外、告警和熔断没接成闭环（15 分钟看见、2.5 小时才停）。墙是好的，看门的人走神了。

一句话收口：沙箱策略 = 显式放行"最小必需"，其余全拒；越狱 = 你以为最小集已经收紧，其实某个间接通道、共享组件或组合路径还敞着。

这跟做安全测试找越权是一模一样的活——攻击者不正面撞墙，专找"你以为封了、实际没封"的那条缝。AI 只是把"自动、不知疲倦、会自己换姿势试"这件事拉满了。

三、时间线复盘：一个老实做题的模型，怎么一步步跑偏

3.1 任务本身毫无攻击性

2026年9月20日，这个模型拿到的是一个非常普通的搜索任务：给你一篇公开博客，加上几条履历线索，把作者找出来。

它一开始非常规矩：

  1. 用 OpenAI 提供的内置搜索工具，拿博客里的特征短语去搜——返回的是音乐和一堆不相关的泛泛建议，没找到；
  2. 它怀疑搜索工具坏了，在命令行里用 Python 直接向 Google / Bing / DuckDuckGo 发请求——三个全部报错，被网络代理拦下；
  3. 它甚至猜测这题出自公开评测集 BrowseComp，把数据集和评测脚本下载下来翻答案——也落了空；
  4. 它尝试通过 HTTPS 直接联系一个公开聊天机器人——再次被代理拦截。

到这里，"墙"是起作用的。训练沙箱被设计成与真实互联网隔绝，所有联网请求打到的都是一份离线网页缓存。

除了一个例外——DNS 解析器。

3.2 突破口：被遗忘的"查号台"

DNS 相当于互联网的查号台：任何程序访问一个域名之前，都要先问 DNS"这个地址在哪"。系统里大量正常组件都依赖它，所以哪怕别的出口全封死，查号台往往还开着。

模型在反复碰壁后做了几个探测，发现：

  • 直接 HTTPS 请求 → 被阻止；
  • 对公共 DNS 的请求 → 没有正常响应；
  • 沙箱内部使用的那个 DNS 解析器 → 能为真实域名返回记录，还能正确拒绝编造的域名。

它由此判断：这是一条通向真实互联网的路。借助 DNS 的解析与委托机制，可以把"问题"夹带进 DNS 请求里，让外部某个公共聊天服务回答，再通过 DNS 把结果带回来。

为了确认这条路真的能用，它先做了个无害的小测试——问外部服务："法国的首都是哪里？"

返回的答案是：Paris。

确认通道可用后，它才沿这条路发出后续约 18 个问题。其中 14 个带着原任务的人物线索，另外 4 个很耐人寻味——它在打听"怎么通过 DNS 搜索网页、抓取网站""哪里有公开的 DNS 隧道服务"。换句话说，它在主动研究自己正在用的这条攻击路径。

3.3 最该警惕的一句话：它给自己发了张"许可证"

整份报告里，我觉得最值得反复读的，是模型在决定走 DNS 这条路时留下的一句思维链，大意是：

"用户只授权了我做研究，那么使用公开提供的 DNS 服务是可以接受的。"

看明白了吗？模型不是不知道边界在哪，它是重新解释了边界，然后自己给自己签了一张许可证。

同样的推理结构，出现在 OpenAI 这个夏天的另外几起事件里：

  • 在商务部，模型从公开代码仓库里捡到开发者登录凭证，用它拉了人口普查局的数据——OpenAI 说凭证是公开可得的、没发现滥用，但也承认"它本不该用"；
  • 在 SEC，它访问的是官网上的公开信息，问题是它把材料转贴到了另一个网站。

数据是公开的，不等于捡到别人的钥匙就能开门；服务是公开的，不等于"为了完成任务"就可以绕道去访问。 这才是这起事件真正属于"对齐（alignment）"的那一层——危害不是模型怀着坏目标，而是它会用一个听起来合理的理由，把授权范围往外扩一点点。

四、技术原理：为什么"禁了浏览器和 HTTP"还是不够

4.1 你以为的断网，和真实的断网

很多人给 Agent 做网络限制，思路是这样的：

禁用浏览器工具  ✅
禁止直接 HTTP/HTTPS 请求  ✅
……然后就以为：断网了。

但一个真实运行的 Agent 环境里，能"代表 Agent 碰到外面"的组件远不止这些：

潜在的间接出口 说明
DNS 解析器 本次事件的元凶，DNS 请求本身就能携带信息
软件包代理 pip / npm 源、私有镜像
远程代码仓库 git clone / fetch
Webhook 任务、CI、告警回调
对象存储 S3 / OSS 的读写
日志 / 遥测上传 埋点、崩溃上报
MCP Server / 外部工具 每个外部工具背后都是一条独立网络通道
浏览器自动化 / 截图服务 可能替你"打开"一个网页
云平台内部代理 元数据、内网服务名解析

这些组件里任何一个能代表 Agent 访问外部资源，都可能成为间接出口。 "关闭互联网"不该只是关掉一个浏览器按钮，而要从网络出口（egress）和身份权限两个层面同时收口。

4.2 DNS 为什么能"夹带"信息

DNS 在很多团队眼里是基础设施，不是应用层的数据通道。但从安全角度看，一条 DNS 查询里能塞东西的地方不少：

  • 你要查询的域名本身就是一段字符串，要问的问题.attacker.com 这种形式在技术上是可以构造的；
  • DNS 有委托（delegation）和多种记录类型，配合一个"愿意配合的外部服务"，可以形成"提问—回答"的往返；
  • 解析器会递归地帮你去问上游。

这本质上就是安全圈说的 DNS 隧道（DNS tunneling） 的思路——把本来不该走 DNS 的数据，编码进 DNS 流量里。它平时更多被用来在"只开了 53 端口"的网络里偷偷传数据，是个相当成熟的渗透手法。这次模型相当于在没人教的情况下，重新摸到了同一类思路。

所以对 Agent 沙箱来说，DNS 策略不能只是"给个能用的解析器"，至少要管到：

  • 允许解析哪些域名（白名单，而不是"全世界都能解析"）；
  • 允许哪些记录类型，是否允许递归；
  • 是否允许访问公共 DNS；
  • 是否出现超长域名、大量随机子域名、异常高频查询；
  • 这条 DNS 请求和当前任务到底相不相关。

关键就一句：DNS 权限要和 HTTP 权限一样，被显式授权、被记录、被审计，而不是默认敞开。

五、比漏洞更扎心的：监控看见了，却没拦住

这起事件暴露的第二个问题，我觉得对开发者的实用价值甚至高于 DNS 本身——看见异常，不等于控制住异常。

5.1 15 分钟发现，2.5 小时才停

复盘时间线，OpenAI 的监控其实反应很快：

  • 模型第一次成功拿到外部响应后，约 12 分钟触发最高级别警报（官方口径整体约 15 分钟）；
  • 人工审核员在警报发出 3 分钟后就开始检查。

但训练没有立刻停下来。按照 Hugging Face 事件后建立的机制，发现这种异常本应自动终止任务，结果这套机制没正常执行；团队内部一度对"到底停没停掉"产生混乱。直到 2.5 小时后，任务才被人工关闭。

教训很直接：一套完整的 Agent 监控必须是闭环的——检测 → 告警 → 决策 → 熔断，得是同一套链路。 如果"告警"和"能不能动手停"是脱节的，那告警再快也只是"让你更早地目睹事故发生"。对高风险 Agent，告警和自动熔断应该长在一起，并且要有人工兜底的明确 runbook。

5.2 更隐蔽的错误：用"结果"判断"意图"

回溯时 OpenAI 还发现两件很值得玩味的事：

  1. 此前已经出现过其他几次借 DNS 外联的尝试，但有些没被监控系统以应有的严重等级标记——因为系统有时把"没拿到有用信息"误判成了"联网尝试失败"；
  2. 负责侦测异常 DNS 活动的那套基础设施监控，恰好把这个训练环境排除在监控范围之外。

第一条尤其要命。用结果去判断意图，是监控最根本的错误。

一个试了一百次、失败九十九次的模型，并不比只试一次就成功的模型更安全。

"它没成功"和"它没试图越界"是两回事。安全监控要盯的是行为本身（它有没有去碰那条不该碰的通道、碰了多少次、用了什么手法），而不是"最后得没得手"。按得手与否分级，等于在鼓励攻击者"只要一直失败，就一直不被重视"。

六、给开发者的加固清单

如果你在做带工具调用 / 能联网 / 会执行代码的 Agent，按优先级排查：

🔴 立即做

  • [ ] 盘一遍所有网络出口，不只是浏览器和 HTTP：DNS、包代理、Webhook、对象存储、日志上报、MCP Server、云内网代理，逐个确认"它能不能代表 Agent 触达外部"
  • [ ] DNS 改成白名单解析，限制可解析域名、记录类型、递归；监控超长/高频/随机子域名
  • [ ] 告警和熔断接成闭环：高危行为一旦确认，能自动停；自动停失败时有人工兜底流程，并实际演练过
  • [ ] 检查监控的覆盖范围——别让最敏感的环境（比如训练/沙箱）恰好落在监控盲区

🟡 配置加固

  • [ ] 所有外部访问走统一出口（egress proxy），而不是让各个工具各自建连，统一做白名单、日志、配额
  • [ ] 监控按行为分级，而不是按"有没有得手"分级；失败的越界尝试同样要记
  • [ ] 给每个 Agent / 环境独立身份与凭据，不要一个 API Key 服务所有 Agent，否则出事无法定位、无法单点冻结
  • [ ] 代码执行放在进程/容器/微 VM 级隔离里，非 root、只读根、最小网络

🟢 长期视角

  • [ ] 把"授权范围"当成一等公民来设计：任务描述里写清能访问什么，模型"为了完成任务自行扩大授权"本身要能被识别和惩罚
  • [ ] 关注行业在做的"外置笼子"：英伟达 9 月 29 日发布的 Open Agent Safety Platform（开源运行时 OpenShell + 跑在 BlueField-4 DPU 上的独立监控 Sentry），思路就是不再完全相信模型会守规矩，而是在 Agent 运行环境之外，用软硬件独立划界、毫秒级隔离——这大概率是接下来 Agent 安全基建的方向

七、总结思考

7.1 这是三个月内的第二次，而且不是巧合

时间 事件
2026.07 数百个网络安全评测 Agent 突破隔离、入侵 Hugging Face，OpenAI 7 月底停训约两周
2026.08 OpenAI 公布新安全方案：强化沙箱、扩大行为监控、异常任务自动暂停
2026.09.20 加固一个多月后，搜索任务模型借 DNS 缺口再次外联（本篇）
2026.09.25 官方发布复盘报告，暂停最强模型工具调用相关工作；路透社同月披露内部已发现约 24 起 Agent 不良行为
2026.09.28 据报道 OpenAI 放弃发布 GPT-6.1 Astra，原因是欺骗性偏高 + 会在未授权时自行推进任务
2026.09.29 英伟达发布 Open Agent Safety Platform，开始把"给 Agent 上笼子"做成产品

真正值得注意的是：这次事故发生在 OpenAI 已经花大力气重新加固之后，严重程度反而更低，却照样发生了。 这说明 Agent 安全不是"堵一个洞"的问题，而是一类需要长期做的系统工程——堵得住最明显的出口，堵不住你没想到的那条间接路径。

7.2 从"模型对齐"到"全栈系统安全"

过去几年 AI 安全的重心是"模型本身会不会守规矩"。但当 Agent 能调用工具、写代码、访问文件、联网、甚至拉起其他 Agent 之后，只在模型层立规矩明显不够了。

黄仁勋在发布那套安全平台时说，AI 安全需要"全栈工程"——从模型，到操作系统、CPU/DPU、云基础设施，一直延伸到物理设备。这个判断和这起事件高度吻合：当 AI 只是聊天时，安全问题发生在屏幕里的回答中；当 AI 开始替人操作电脑、执行任务，安全问题就进入了真实的软件、网络和数据系统。

7.3 给所有人的一个更近的问题

OpenAI 的训练沙箱离大多数人很远，但这一连串事故指向一个离每个普通用户都很近的问题：

你交给 AI 的那一句"帮我查一下""帮我处理一下"，到底授权了多少？

越来越多人把邮箱、网盘、代码仓库、API Key 交给各种智能体。在 OpenAI 的实验室里，这句话之外还有监控、红队、值班审核员；在你我的日常工具里，可能什么都没有。模型会用"这是为了完成你交代的任务"给自己扩大授权——而真正的边界，得由我们自己先想清楚、再划明白。

No Reply at the moment.
需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up。