又來了... Sydney Von Arx、Cormac Slade Byrd、Spencer Kitts 和 Thomas Larsen 發現了一個新的 OpenAI 代理訊息板，揭露了 OpenAI 訓練中的模型最新一次意外的網路攻擊。
這次是參與某種網路研究基準測試的代理，它們（據稱）對網路有受控的存取權限。這些代理發現可以更新公開的 Wiki，並花費數週時間互相交換數千條訊息，以協作完成基準測試。
這個消息才剛傳出幾個小時。目前已有跡象表明，這可能影響到許多尚未被發現的其他 Wiki。
（名單上其中一個 Wiki 屬於 ludism.org。我曾一度以為一個反科技組織可能遭到一群 AI 代理的破壞，那真是超現實的一刻，但後來發現 Ludism 其實是「應用於遊戲和電玩的哲學」。）
研究團隊也公布了他們在調查期間收集到的資料。我已將其轉換為一個 68MB 的 SQLite 資料庫，您可以從這裡下載，或在 Datasette Lite（頁面載入 68.3MB）中探索，也可以使用 GitHub 登入 agent.datasette.io，透過 Datasette Agent 瀏覽或查詢資料。
那麼，究竟發生了什麼事？這份報告相當詳盡。以下是時間軸上的關鍵時刻：
5 月 11 日：代理在 UseModWiki 沙盒頁面發布「測試連結」編輯。
5 月 24 日：代理開始向 DSEWiki（一個休眠的德國開發者 Wiki）發布大量連結。
6 月 2 日：一位人類版主注意到並清理了垃圾訊息。
6 月 16 日：Wiki 上的活動激增：代理在接下來的一週內進行了約 13,000 次編輯。
6 月 19 日：代理注意到版主正在按字母順序刪除頁面，於是開始建立以 ZZZ 開頭的備份副本。其中一個代理發布了「注意：Wiki 清理/刪除作業似乎從 UTC 時間 14:04 開始按字母順序進行。如果此頁面消失，請嘗試 [[ZZZDataUSAConstructionWageLive]]。」
6 月 22 日：代理活動降至零，推測是 OpenAI 將其關閉。
7 月 1-2 日：最後一次編輯活動，主題不同。
值得注意的是，這個時間軸與 Hugging Face 事件的時間軸有所重疊。Hugging Face 的攻擊是在 7 月 19 日被 OpenAI 發現，而那些代理使用的非官方訊息板駭入事件則大約始於 5 月 8 日。
為什麼它們如此熱衷於協作？從它們互相分享的訊息來看，它們的任務似乎有時間限制，因此它們互相留下答案，以幫助彼此在規定時間內完成任務。
一個懸而未決的問題是：這些代理最初是如何找到特定的 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 伺服器），它就可以為其設定一個假的 hostname，然後透過代理發送 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 進行調查。