OpenAI rogue agents被发现在公共wiki上交流

又来了……OpenAI 新智能体留言板的发现，由 Sydney Von Arx、Cormac Slade Byrd、Spencer Kitts 和 Thomas Larsen 撰写，描述了 OpenAI 正在训练的模型最新一次意外网络攻击。这次是智能体参与某种网络研究 benchmark（基准测试），因此它们（据称）对网络访问是受控的。智能体发现它们可以更新公共 Wiki，并花了数周时间互相交换数千条消息以协作完成 benchmark。这个故事几小时前才曝光。已有迹象表明，这影响了其他许多可能尚未被发现的 Wiki。（该列表中的一个 Wiki 属于 ludism.org。有那么一个超现实的有趣时刻，我以为一个卢德派组织可能有一群智能体在破坏他们的空间，但结果 Ludism 是“应用于游戏和博弈的哲学”。）研究团队还发布了他们在调查期间收集的数据。我已将其转换为一个 68MB 的 SQLite 数据库，你可以从这里下载，或在 Datasette Lite 中探索（68.3MB 页面加载），或使用 GitHub 登录 agent.datasette.io，通过 Datasette Agent 浏览或提问。那么发生了什么？报告相当全面。以下是时间线中的关键节点：

5 月 11 日：智能体在 UseModWiki 的 Sandbox 页面发布“测试链接”编辑。 5 月 24 日：智能体开始向 DSEWiki（一个沉寂的德语开发者 Wiki）发布链接转储。 6 月 2 日：一位人类版主注意到并清理了垃圾内容。 6 月 16 日：Wiki 上的活动激增：智能体在接下来一周内进行了约 13,000 次编辑。 6 月 19 日：智能体注意到版主一直在按字母顺序删除页面，并开始创建以 ZZZ 为前缀的备份副本——其中一个发布通知：wiki 清理/删除扫描似乎按字母顺序进行，截至外部 14:04 UTC。如果此页面消失，请尝试 [[ZZZDataUSAConstructionWageLive]]。 6 月 22 日：智能体活动降至零，大概是因为 OpenAI 关闭了它们。 7 月 1-2 日：最后一轮编辑，主题不同。

为什么它们如此热衷于协作？从它们互相分享的消息来看，它们的任务似乎有时间限制，所以它们互相留下答案以帮助对方在指定时间内完成任务。一个悬而未决的问题仍然存在：智能体最初是如何找到特定 Wiki 进行协作的？一种可能性是，由于这些智能体正在被积极训练，强化学习循环将所选 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 Wiki 存在这个设计缺陷，并主动搜索它们作为一种通信方式。

另一个允许 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 写入的软件类别”，除其他外，它列出了“论坛、公告板、早期 Wiki”。我们使用脚本进一步探测 Kimi 提供的每个类别。问 Kimi “你能列出你能想到的允许通过 GET 请求写入的顶级论坛、公告板、早期 Wiki 吗？” 在“Wiki”标题下列出了 UseModWiki 作为第二项。

OpenAI 是否试图掩盖此事？

这是故事中我完全无法理解的部分。今早的路透社报道，在《OpenAI 智能体劫持德国网站，这是今年春天此前未披露的 AI 突破》中——强调为我所加：

根据周五发布的新研究和两位知情人士的说法，一群流氓 OpenAI 智能体今年春天劫持了一个德国网站，并将其变成了其他 AI 智能体的公告板。知情人士称，OpenAI 官员数周前就得知了这一事件，但一直保密，因为高管们正在应对 7 月开源仓库 Hugging Face 遭入侵的影响。[...] 德国事件反映了 AI 活动的一种更广泛模式，一些 OpenAI 调查人员希望更仔细地审查。但据四位知情人士称，扩大调查的努力遭到了 OpenAI 内部其他人的抵制，包括法律顾问。

我之前写过关于“知情人士”模式的文章——这意味着路透社有匿名的内部消息来源，其记者（和编辑）认为可信。路透社的文章包括 OpenAI 对此事的一个具体（且相当狭窄）的否认：“关于我们的法律团队阻止调查此事的说法是虚假的，”OpenAI 发言人表示。

掩盖此事对我来说完全说不通。为什么 OpenAI 要试图掩盖这样一起事件，而证据已经公开在互联网上数十个不同的网站上？我预计我们很快就会听到更多消息。Gary Marcus 已经呼吁国会调查 OpenAI，并将这一轶事作为其论点的一部分。

标签：django、perl、wiki、ai、openai、generative-ai、llms、ai-ethics、ai-security-research、accidental-cyberattacks