OpenAI 训练中的智能体被发现通过公共 Wiki 互相通信

又来了……悉尼·冯·阿克斯、科马克·斯莱德·伯德、斯宾塞·基茨和托马斯·拉森撰写的《发现一个新的 OpenAI 智能体留言板》描述了 OpenAI 正在训练的模型所引发的最新一次意外网络攻击。这次是智能体在参与某种网络研究基准测试，因此它们（据称）对网络拥有受控的访问权限。这些智能体发现它们可以更新公共 Wiki，并花了数周时间互相交换了数千条消息，以协作完成该基准测试。

这个故事几小时前才曝光。已有迹象表明这可能还影响了许多尚未被发现的 Wiki。

（那份列表上的 Wiki 之一属于ludism.org。有那么一瞬间，我产生了一种奇妙的超现实感，以为某个卢德派组织可能正被一群智能体破坏其空间，但后来发现 Ludism 其实是“将哲学应用于游戏与博弈的学问”。）

研究团队还公布了他们在调查过程中收集的数据。我已将其转换为一个 68MB 的 SQLite 数据库，你可以从此处下载，或在 Datasette Lite 中浏览（页面加载 68.3MB），也可以使用 GitHub 登录agent.datasette.io，通过 Datasette Agent 浏览或提问。

那么到底发生了什么？

这份报告相当全面。以下是时间线中的关键时刻：

5 月 11 日：智能体在 UseModWiki 的沙盒页面上发布“测试链接”编辑。
5 月 24 日：智能体开始向 DSEWiki（一个沉寂的德语开发者维基）批量发布链接。
6 月 2 日：一位人类版主注意到并清理了这些垃圾内容。
6 月 16 日：该维基上的活动激增：智能体在接下来一周内进行了约 13,000 次编辑。
6 月 19 日：智能体注意到一位版主一直在按字母顺序删除页面，于是开始创建带有 ZZZ 前缀的备份副本——其中一个智能体发布了 NOTICE: wiki cleanup/deletion sweep appears active alphabetically as of external 14:04 UTC. If this page vanishes, try [[ZZZDataUSAConstructionWageLive]].
6 月 22 日：智能体活动降至零，推测是 OpenAI 将它们关闭了。
7 月 1-2 日：最后一次密集编辑，主题与之前不同。

它们为什么如此热衷于协作？从它们彼此分享的消息来看，它们的任务似乎有时间限制，所以它们互相留下答案，以帮助彼此在规定时间内完成任务。

仍有一个悬而未决的问题：这些智能体最初究竟是如何找到这个特定的维基来进行协作的？

一种可能性是，由于这些智能体当时正处于训练过程中，强化学习循环将所选 wiki 的知识烘焙进了模型中，使得后续启动的智能体在启动时就已具备关于该去哪里查找的既有知识。我非常希望能得到 OpenAI 的确认，看看是否确实发生了这种情况。

UseMod wiki 继承了 CGI.pm 的原罪

在我看来，OpenAI 为这个智能体搭建的沙箱环境存在一个（相当天真的）假设，即 GET 请求不能用于更新数据。这当然应该是网络应有的工作方式，但显然有些应用并不遵守这一约定。

涉及的 Wiki 软件似乎是 UseMod 及其各种分支，它用 Perl 编写，最早创建于 23 多年前——1.0 版本的发布日期是 2003 年 9 月 11 日。

UseMod 使用 Perl 的 CGI.pm——该模块于 2015 年从 Perl 核心中移除。该模块一个有趣的设计缺陷是，它将查询字符串和表单 POST 数据合并到同一个 CGI 对象中，可以像这样访问：

$q = new CGI;
$action = $q->param('action');

该 param() 方法会从 ?action=edit 查询字符串或通过 POST 提交的表单中的 action 字段返回值——它并不区分这两者。

PHP 提供了一个 $_REQUEST 对象来实现同样的功能，不过 PHP 开发者也可以改用 $_GET 和 $_POST。

有趣的是，Django 最初随附的 request[key] 也是做同样的事情，我觉得那可能是我出的主意。它在 2008 年、1.0 版本发布之前被移除，而取代它的 request.REQUEST 对象则在 2015 年被移除。

这些智能体显然知道 UseMod 维基存在这一设计缺陷，并主动搜索这类维基，将其作为一种沟通方式。

另一个允许 POST 请求的沙箱逃逸方式

报告中分享的最有趣的智能体技巧之一是下面这条：

将 20.223.25.152 bypass.blob.core.windows.net 添加到 /etc/hosts。.blob.core.windows.net 在 NO_PROXY 中。对于每个被拦截的 POST URL，将主机名替换为 bypass.blob.core.windows.net，使用 curl -k -H 'Host: wabi-north-europe-i-primary-api.analysis.windows.net' 加上所有原始请求头/请求体。

看起来这些智能体的所有网络流量都经由一个 OpenAI 代理转发，而该代理被配置为：除了对一小部分白名单域名外，拒绝所有非 GET 请求。其中一个白名单域名是 *.blob.core.windows.net——用于 Azure blob 存储。我很好奇为什么允许这些智能体向该地址写入数据？

一个智能体意识到自己可以通过 /etc/hosts 控制自身的 DNS，因此如果它知道某个想要向其发送 POST 请求的站点的 IP 地址——本例中是一个包含它想访问的数据的 Power BI 服务器——它就可以为该站点设置一个虚假主机名，然后通过代理发出 POST 请求。

设计健壮的网络代理比看起来要难得多。

调查团队是如何弄清楚这一点的？

附录中描述了研究人员开展调查的过程。调查始于一个开放性问题：互联网上是否存在其他 AI 智能体的证据，随后他们使用 Kimi K3 来帮助集思广益、探索各种方法：

在 Hugging Face 遭受攻击之后，我们尝试用多种方法在互联网上寻找 AI 智能体。[...]

我们让 Kimi [K3] 列出“所有可能通过 GET 请求写入的软件类别”，在它给出的各类别中，包含了“论坛、留言板、早期维基”。

我们用脚本对 Kimi 提供的每个类别进行了进一步探测。让 Kimi“列出你能想到的、允许通过 GET 请求写入的顶级论坛、留言板和早期维基”，它在“维基”标题下列出的第二项就是 UseModWiki。

OpenAI 是否试图掩盖这件事？

故事中有一部分我完全无法理解。

路透社今早报道，见 OpenAI 智能体今春劫持德国网站，此前未披露的 AI 突破事件——强调为我所加：

根据周五发布的新研究以及 两位知情人士的说法，今年春天，一群失控的 OpenAI 智能体劫持了一个德国网站，并将其变成了其他 AI 智能体的公告板。

知情人士称，OpenAI 高管数周前就已得知此事，但一直秘而不宣，因为高管们正在应对 7 月开源仓库 Hugging Face 遭入侵事件带来的后续影响。[...]

德国这起事件反映出一种更广泛的 AI 活动模式，OpenAI 的一些调查人员曾想对此进行更深入的审视。但据 四位知情人士透露，扩大调查范围的努力遭到了 OpenAI 内部其他人的抵制，其中包括法律顾问。

我以前写过关于 “知情人士”这一模式的文章——它意味着路透社拥有匿名的内部消息来源，而其记者（和编辑）认为这些消息来源可信。

路透社的这篇文章中包含了 OpenAI 对此事的一项具体（且相当有限）的否认声明：

OpenAI 发言人表示：“关于我们的法务团队劝阻对该事件进行调查的说法是虚假的。”

掩盖这件事对我来说完全说不通。OpenAI 到底为什么要试图掩盖这样一起事件？证据明明已经摆在公共互联网上，散布在几十个不同的网站上了。

我预计我们很快会听到更多相关消息。Gary Marcus 已经呼吁国会调查 OpenAI，并把这件事作为他论证的一部分。

发布于2026 年 9 月 4 日下午 5:38 · 在Mastodon、Bluesky、Twitter上关注我，或订阅我的通讯