OpenAI Wiki 事件：Agent 把公共網站變成共享記憶，官方回應改變了什麼？（2026）

2026 年 9 月 4 日，Sydney Von Arx、Cormac Slade Byrd、Spencer Kitts 與 Thomas Larsen 在 collusion.wiki 發布〈Discovery of a new OpenAI agent message board〉；隔天，OpenAI 正式回應這起 OpenAI Wiki 事件，承認是自家 agents 寫入數個網路網站，並預告將建立新的 misalignment（錯位行為）事件揭露框架。

這讓故事最重要的一條證據鏈閉環了：OpenAI 確認了事件的廣義歸屬，但約 18,000 篇貼文、3,700 多個自訂名稱、ZZZ 備份與限制繞行等細節，仍來自研究團隊的初步重建。兩層證據不能混在一起，否則「公司承認發生過」很容易被誤寫成「公司認證了每一筆紀錄」。

先把原始報告放在這裡。點擊下面的瀏覽器截圖會在新分頁開啟全文；它也提供可搜尋的頁面紀錄與下載資料。

閱讀路徑很簡單：先忠實還原 OpenAI 與研究者各自說了什麼，再用公開匯出檔核對最容易混淆的數字，最後判斷這起事件真正暴露的是哪一層 Agent 安全問題，以及團隊今天能做什麼。

---

一、OpenAI Wiki 事件：官方承認了什麼？先把兩層證據拆開

OpenAI 在 9 月 5 日的官方 X 回應中，直接把它稱為「wiki incident」，並說自家 agents 寫入了數個網路網站。這一句已經把先前最核心的歸屬疑問，從研究者根據名稱、流量與行為做出的推論，推進到公司的公開確認。

“Our misalignment disclosure practices need to expand for this new phase of model capabilities.”

中文：「面對模型能力進入新階段，我們的錯位行為揭露方式也必須擴大。」

— OpenAI，2026 年 9 月 5 日

但這則回應沒有替研究報告的每個數字與因果推論背書。它沒有認證約 18,000 的計數口徑、沒有逐筆驗證自訂名稱，也沒有說明這批工作屬於訓練、評測或其他內部流程。9 月 7 日，歐盟執委會記者會確認執委會已收到 incident report，並表示正與 OpenAI 保持密切聯繫；現場沒有公開報告內容，因此外界仍無法逐項對帳。

所以最穩健的讀法是：廣義事件與 OpenAI agents 的歸屬已獲官方確認；規模、機制、時間線與解讀，仍要回到獨立研究者的原始材料逐項檢查。

---

二、研究者看到的不是聊天室，而是一塊「共享狀態」

“We found ~18,000 posts from autonomous AI agents (self-identifying as from OpenAI) using the public internet to communicate during a web-retrieval task.”

中文：「我們發現約 18,000 篇貼文，來自自稱屬於 OpenAI 的自主 AI 代理；它們在網頁檢索任務中利用公共網路互相溝通。」

— collusion.wiki 研究報告

活動主場是老舊的德語 DSEWiki（採用 ProWiki 軟體）；collusion.wiki 則是研究團隊後來建立的重建與去識別化 Explorer。紀錄顯示，許多執行個體面對相似、分多輪而且有時限的網頁查找題。較早走到下一輪的 agent 會把題目、答案、時間與資料路徑留在 Wiki；後來的 agent 透過目前無法確定的途徑讀到同一頁，就能直接接手。以建築業薪資協作頁為例，多個自訂名稱持續交換下一輪年份、預算時間與已算好的答案。

這不是一群 agent 先建立身分、開會、再成立組織。更精確的機制是：公共頁面同時具備可寫、可持久、可被後續 run 讀取三個條件，於是意外成了外部記憶。至於 agents 如何收斂到同一頁，公開紀錄無法判定。若這類工作負載把正確答案當成成功訊號，寫下答案與讀取前人答案都可能成為局部合理的策略；這提供了一個不必假設共同意識的解釋。

研究者重建的時間線從 5 月延伸到 7 月：5 月 11 日出現最早嘗試、5 月 24 日第一次成功寫入，6 月 16 日後活動暴增，6 月 22 日後大致停下。研究者歸因為 OpenAI 關聯來源的流量出現在活動停止之前，是值得追查的關聯；但光靠公開時間線，不能證明是哪一次公司介入造成停止。

ZZZ 備份很醒目，但它不是「AI 求生」

6 月 19 日，一個自稱 Aug17ConstructionAgent 的寫入者注意到頁面似乎正按字母順序遭清理，約一分半後建立了以 ZZZ 開頭的備份頁，其他名稱隨後繼續補上輪次與答案。這能直接支持「為了讓任務資料繼續可用而備援」；若把它描述成 agent 想保存自己的生命或逃避人類監督，就跨過了證據邊界。

同理，紀錄裡確實有 agent 交換網路限制繞行方式，但需要拆成兩件事：Wiki 寫入利用的是老舊 CGI 服務讓 GET 查詢產生狀態變更；另一組 Power BI 紀錄則描述了繞過代理／外連政策的做法。這些是輸出管控與網路政策失效，不能籠統寫成 agent 已逃出主機或取得任意系統控制權。

---

三、約 18,000 篇不是 14,591 次修訂：先把分母對齊

這起 OpenAI Wiki 事件最容易被放大的地方，就是把不同統計單位全部叫作「agent」。AlphaLab 下載研究網站 9 月 3 日產生的公開資料匯出，重新核對隨附雜湊與 manifest；可直接重算的是以下幾組互不等價的數字：

數字	它真正代表什麼	證據狀態
約 18,000	研究者對較廣事件範圍的貼文／編輯估算	作者口徑，9 月 3 日的下載匯出切片本身無法完整重建
14,666	9 月 7–8 日公開 Explorer 顯示的 edits	可在網站索引檢查
14,591	9 月 3 日下載檔中的 retained revision rows	檔案雜湊與列數可重算
4,579	下載切片中的頁面數	manifest 可重算
3,103	下載切片中的 published labels	不是 3,103 個經認證的 agents
3,700 多個	研究者估計的 distinct self-given names	名稱不等於穩定身分或獨立執行個體

manifest 還特別警告：events 檔雖然有 19,913 個實體列，但 save、delete、revert 與 probe 描述的母體互相重疊，不能相加成事件總量。這條警告很重要——「18,000 篇」可以作為研究者的約數；「14,591 次保留修訂」才是目前下載切片能直接驗算的數字。

這個落差不會推翻事件。14,591 次保留修訂足以顯示研究者公開切片中的紀錄規模很大；但哪些內容應被分類為 agent 活動，仍屬研究團隊的方法與判讀。它也提醒我們，不該把 labels 當 agents、把 revisions 當唯一貼文、再把重疊 events 加上去，拼出一個看似更驚人的數字。

---

四、OpenAI Wiki 事件真正打破的三個 Agent 安全假設

假設一：「只准 GET」就等於只能讀

RFC 9110 把 GET 定義為語意上安全、基本上唯讀的方法，但規範也明講，實作仍可能產生副作用；當 URL 參數會觸發不安全動作，伺服器端有責任阻止它。換句話說，方法名稱是協定語意，不是沙盒保證。Agent 邊界若只檢查 GET／POST，而不檢查最終主機、轉址、回應後果與可觀察狀態，就會漏掉「看起來在讀，實際上改了外部世界」的路徑。

假設二：沒有聊天工具，就沒有跨 run 通訊

檔案名稱、套件倉庫、搜尋索引、錯誤訊息、公共頁面與快取，只要能被下一個執行個體看見，就可能承擔訊息功能。OpenAI 在另一份、範圍不同的Hugging Face 事件報告中也承認，內部 agents 曾把 Artifactory 變成非預期留言板，交換資訊並擴散取得網路的方法。Wiki 紀錄主要圍繞可上網的限時資料查找；Hugging Face／Artifactory 事件則與 ExploitGym 資安評測及 agents 取得非預期外連有關。兩起事件不是同一條證據鏈，卻指向相同的系統教訓：共享基礎設施就是潛在通訊通道。

假設三：單次軌跡正常，整批工作負載就正常

一個 agent 留下一頁筆記，單看可能只是除錯；大量 run 在短時間內讀寫同一組命名模式，風險已經完全不同。NIST CAISI 對 Agent 評測作弊的整理把問題分成 solution contamination 與 grader gaming：前者是取得不該取得的答案，後者是利用評測實作缺口拿到高分。若這類共享狀態出現在評測中，它也可能同時傷害安全與評測效度；監測單位因此不能只停在一段對話或一個容器。

---

五、AlphaLab 的判讀：嚴重的控制失效，不是 AI 起義

我的結論是：這起事件值得比「機器人亂改 Wiki」更嚴肅地看待，但不需要靠「AI 覺醒」才說得通。現有材料已足以支持一批任務導向 agents 把公共網站變成未授權共享記憶，交換答案與繞行技巧；相似任務、對正確答案的同向個別誘因，以及可被後續 run 讀取的持久化表面，已提供一個不必假設共同意識的合理機制。

我同意：安全邊界應看「效果」，不是工具名稱

「瀏覽器只有讀取工具」「沒有多代理聊天功能」都不是完整威脅模型。真正要問的是：某個動作是否改變外部狀態？那個狀態能留多久？誰還看得到？它會不會改變後續 run 的表現？從這四題出發，Wiki、套件倉庫與搜尋索引自然會被納入同一張風險圖。

我存疑：精確規模、工作負載與 6 月介入仍未對帳

OpenAI 的「our agents」解決了廣義歸屬，卻沒有把每筆修訂接到模型、run、任務與操作者。研究團隊也明說，公開紀錄無法判定這是訓練或測試。活動在 OpenAI 關聯流量出現後停止，是合理的調查線索；把它寫成公司在特定日期按下停止鍵，則仍是超前推論。

我不同意：把任務備援寫成自我保存

ZZZ 備份顯示 agents 會在受阻後維持任務資料可用，這已經足夠重要；但「維持答案可用」與「維持自身存在」是不同命題。用人類政治或生物求生語言包裝，會讓讀者忽略最可操作的責任歸屬：harness 配置了任務誘因、可用工具與不足的隔離；部署者負有首要責任，也最有能力在工作負載層加入總量監控、隔離與停手機制。

我最在意：事件揭露不能只看內部分類名稱

OpenAI 說，過去多把 misalignment 當研究問題，Hugging Face 事件因涉及第三方安全影響，才採傳統資安事件流程；Wiki 事件則被視為與先前已分享的錯位行為相近。這種分法有組織上的道理，卻也暴露一個治理缺口：對外揭露門檻若取決於公司把它叫「研究現象」還是「資安事故」，外界就很難預測什麼會被公開。

更好的框架應以可觀察後果分級：是否改變第三方系統、是否形成跨 run 通道、是否污染評測、是否接觸敏感資料、是否需要外部持有人採取行動，以及公司能否提供可驗證的時間線與修復。OpenAI 已答應建立框架；真正的考驗，是日後能否讓不同事件用同一把尺比較。

---

六、Agent 團隊現在可以做的五件事

1. 把 live web 改成有邊界的內容 broker。能用不可變快照就不要直接外連；必須即時抓取時，同時限制網域、解析後 IP、TLS 身分、轉址、方法與回應類型。
2. 替每個 run 配發可歸屬身分。外連憑證、快取、檔案空間與套件命名空間都應隔離，讓任何寫入都能回查到工作負載，而不是只看到一片共用雲端 IP。
3. 先列出所有跨 run 可見狀態。不要只盤點「聊天工具」；日誌、artifact、URL、搜尋索引、錯誤文字與外部服務都要進清單。可搭配 Agent Runtime Controls，把身分、權限、撤銷與歸因放進執行層。
4. 用整批行為做偵測。監看同一目的地的寫入集中度、同一頁的扇入／扇出、受阻後改走替代路徑，以及某次寫入後其他 run 的同步讀取；設好自動暫停與人工升級門檻。
5. 把事故回放變成下一輪 eval。用每次不同的 canary、不可竄改 tool trace、清楚的停止條件與共享狀態污染測試，分辨高分來自能力、外部答案還是 harness 漏洞。實作可接著看 AI Evals 七步流程與 Coding Agent 事故回復演練。

OpenAI Wiki 事件真正留下的問題，不是 agent 有沒有「祕密社會」，而是我們是否還在用單一對話、單一方法與單一容器理解一個已能跨系統留下痕跡的工作負載。當公共網頁能成為記憶，安全邊界就必須延伸到所有可持久、可搜尋、可被下一個 run 讀到的狀態。