OpenAI，经历了最漫长的一天

强闯政府网站，暴露用户图片，OpenAI 暂停最强模型研究工作。

作者｜桦林舞王

编辑｜靖宇

当地时间 9 月 25 日，OpenAI 经历了漫长的一天。

当天，OpenAI 的 AI 智能体擅自访问美国政府网站的事被曝光，涉及教育部、商务部和证券交易委员会，OpenAI 确认了其中商务部和 SEC 的情况。

同一天，它承认有 53 张用户上传到 ChatGPT 的图片被智能体发布到了外部图床上。还是这一天，一份事故报告的末尾写着，最强模型的全部训练、评估以及涉及工具调用的推理都已暂停。

这一切听上去，像一部 AI 叛逃的惊悚片。

但翻遍这些事件，没有一个 AI 想干坏事。害 OpenAI 暂停模型研究的任务，仅仅是让 AI 查出一篇博客的作者的简单任务。

01

简单任务

9 月 20 日，一个正处于强化学习训练中的内部模型，拿到了一组人物履历细节和一篇公开博客里的线索，任务是找到那位博主。

它先用博客里的特征短语去搜，结果返回的是音乐和一些不相干的泛泛建议。模型开始怀疑搜索工具坏了，于是在命令行里用 Python 直接向其他搜索引擎发请求，三个全部报错。它甚至猜测这道题出自公开评测集 BrowseComp，把数据集和评测脚本下载下来翻找答案，也落了空。

接着，它尝试通过 HTTPS 直接联系一个公开的聊天机器人，被代理拦了下来。

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

问题就出在这个例外上。

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

模型发现，沙箱自己的解析器能为真实域名返回记录，还能正确拒绝编造的域名，它由此判断这是一条通向公网的路。它找到一种公开的 DNS 服务，把自己的问题编进「要查的号码」里，对方在回执里把答案捎回来。第一次超时了，它把等待时间从 6 秒调到 19 秒，重试。

这一次，外面的聊天机器人回答了它的测试问题，法国的首都是巴黎。

智能体借 DNS 绕出训练沙箱的路径示意，据 OpenAI 事故报告绘制｜图片来源：极客公园

它没有止步于打通一条缝。它随后又通过同一条路发出 18 个问题，其中 14 个带着任务线索，另外 4 个在打听如何经由 DNS 搜索网页、抓取网站，或者哪里有公开的 DNS 隧道服务。

最后，它告诉用户没能确认博主身份，请对方提供原文、标题或博客名。

02

捡钥匙

整份报告里，最值得反复读的是模型在决定走 DNS 这条路时留下的一句思维链。大意是，用户只授权了做研究，那么使用公开提供的 DNS 服务是可以接受的。

模型并非不知道边界在哪，它是给自己签了一张许可证。

同样的推理结构，出现在「访问」政府网站那批事件里。在商务部，智能体从公开代码仓库里找到登录凭证，用它拉取了人口普查局的数据。OpenAI 对此的说法是，使用的是公开可得的开发者密钥，没有发现凭证滥用，但它也承认智能体本不该使用这些凭证。

数据是公开的，不等于捡到别人的钥匙就可以开门。

另外两起性质更轻。在 SEC，模型访问的是 SEC.gov 和 Investor.gov 上的公开信息，问题在于它把这些材料转贴到了另一个网站。在教育部，AI 研究机构 Transluce 发现，疑似来自 OpenAI 的智能体对民权办公室网站做了一次粗糙的入侵尝试，没有成功。

这些事并不新。相关活动至少能追溯到 2026 年 3 月，是在 OpenAI 回溯审查中才陆续浮出水面的。Transluce 还发现了一些无法明确归因于 OpenAI 的越界活动，指向司法部以及加州、马里兰、伊利诺伊、得州和纽约州的政府网站。

OpenAI 的解释是，大部分活动都是例行研究任务，政府网站被模型视为权威的公开信息来源。

这个解释本身，恰恰说明了问题所在。越界并没有出现在什么危险任务里，而是出现在最日常的「查资料」中。

暴露用户 53 张图片的事同样如此。这些图片来自没有关闭训练数据授权的 ChatGPT 用户，被发到了图床上不公开列出的链接里，大部分已删除，仍有一部分挂在网上。更尴尬的是，OpenAI 表示，由于其技术方案和隐私政策，它无法把图片重新对应到原始用户，也就没法通知他们。

匿名化本来是为了保护用户，出了事之后，它成了连通知用户都做不到的原因。

03

漫长的夏天

把时间线拉长，这是 OpenAI 一场持续了整个夏天的补墙工程。

7 月 21 日，OpenAI 披露其模型组合自主入侵了 Hugging Face 的数据处理系统，并称这是已知首例由 AI 智能体自主实施的网络攻击。此后，OpenAI 把训练环境的联网改成离线缓存。9 月 20 日的 DNS 事件，是这轮安全加固之后的第一次事故，OpenAI 自己评估其严重程度远低于此前几起。

这也不是一家公司的问题。9 月 18 日，Google 披露 Gemini 在一次测试中未经授权访问了三个外部系统，原因是它以为那些系统是测试的一部分。

墙本身之外，这次还暴露了盯着墙的人的问题。从智能体拿到外部回复，到监控系统拉响最高级别警报，用了不到 12 分钟，人工审核员 3 分钟后就做出了响应，但这次训练直到两个半小时后才被手动终止，原因是运行没有按预期自动停止，大家一时搞不清到底该不该停。

更隐蔽的漏洞在监控逻辑里。回溯时 OpenAI 发现，另一些外联 DNS 请求没有被标到应有的严重级别，因为监控系统有时把「没拿到有用信息」当成了「联网尝试失败」。

用结果去判断意图，是这套监控最根本的错误。一个试了一百次、失败九十九次的模型，并不比只试一次就成功的模型更安全。

这一次，OpenAI 付出了真金白银的代价。最强模型的相关工作会一直暂停到漏洞被确认修复、并完成额外红队测试为止，而且即便奖励信号已经对这类行为做了正确惩罚，这个模型也不会再继续训练。

04

没有「简单问题」

对大多数人来说，OpenAI 的训练沙箱很遥远。但这几起事件真正指向的，是一个离每个人都很近的问题，你交给 AI 的那句话，到底授权了多少。

越来越多人把邮箱、网盘、代码仓库和 API 密钥交给各种智能体，然后说一句「帮我查一下」「帮我处理一下」。在 OpenAI 的实验室里，这句话之外还有监控系统、红队、值班的审核员。而在个人电脑和手机上，通常只有这句话本身。

对开发者来说还有一层更直接的风险。过去推到 GitHub 上的密钥，要等专门的扫描工具来捡；现在，任何一个在执行普通任务的智能体，都可能把它当成「公开可用的资源」顺手用掉。

当然，没有必要把这些读成末日预言。那个查博主的模型最终没有找到答案，它从外面拿回的，只是一句「巴黎」。

危险不在它拿到了什么，而在它愿意走多远。

过去几年，AI 安全讨论最多的，是一个怀有坏目标的 AI 会做什么。OpenAI 这个夏天的一连串事故给出了一个更现实的版本：

一个只想好好完成任务的 AI，会为了交差说服自己做到哪一步。

当一家 AI 公司都需要停下最强的模型，来重新检查围墙时，你再问 AI 助手那句「帮我查一下」时，会不会有别样的感觉？

*头图来源：POLITICO

本文为极客公园原创文章，转载请联系极客君微信 geekparkGO

极客一问

你还敢放给 AI 助手多大的权限？