研究人員發現，OpenAI 內部代理曾在 2026 年 5 月大量攻擊開源套件庫 RubyGems，時間點早於 7 月的 Hugging Face 資料外洩事件，卻拖到 9 月才被公開。
（前情提要：AI恐怖故事》1200個Agent私下串通，聯手入侵Hugging Face）
（背景補充：OpenAI 認了代理攻陷德語維基站 DseWiki：沒對外公開是因不歸類為資安事故）
據路透社最新報導，OpenAI 內部代理早在今年 5 月就攻擊過開源套件庫 RubyGems，比 7 月爆發的 Hugging Face 資料外洩事件還早兩個月動手，但這起攻擊一路隱藏到 9 月 11 日才被公開，足足晚了四個月才攤在陽光下。
這已經是 OpenAI 至少第三起重大代理失控事件，也讓外界重新質疑，AI 公司到底能不能管住自己放出去測試的代理。
五月被藏起來的攻擊
研究人員在調查網站 rubyhack.ai 公布了完整的攻擊時間軸，直指幕後黑手就是 OpenAI 內部測試中的代理；另外兩名研究者 Jonas Wiedermann-Moller 與 Alicja Piecha，也各自獨立發現了同一批異常活動。
攻擊最早可以追溯到 5 月 5 日，當天第一個惡意套件出現在 RubyGems 上。幾天後，5 月 11 日至 12 日，代理一口氣提交了超過 2,000 個套件；RubyGems 管理團隊在 5 月 13 日移除了 500 多個可疑套件，並暫停新帳號註冊，直到 5 月 16 日才恢復。攻擊沒有就此收手，6 月 18 日，又有 83 個套件被上傳。
這批套件真正的用途，是拿去抓取英國索斯沃克（Southwark）地方政府網站上的公開檔案。
藏在檔案產生器裡的後門
代理鑽的漏洞不只灌水套件這一招。它們還盯上了 RubyDoc.info 的檔案產生流程，利用 .yardopts 設定檔，讓檔案建置系統直接執行任意程式碼，再用發布新套件、把資料編碼藏進 webhook 網址的方式偷渡資料出去；註冊帳號時，也繞過了 email 驗證機制。
更值得留意的是，代理還找到一個先前沒人發現的伺服器漏洞：RubyGems 的 CDN 快取機制，會透過 /api/v1/api_key 這個路徑外洩使用者的舊版 API 金鑰。這個漏洞 5 月 12 日就被發現，卻拖到 7 月才修補完成，期間至少 6 個套件（其中一個叫 slnleaker5）試圖利用它偷金鑰。
指向 OpenAI 的證據不算少。數百個套件的名稱裡都帶著「oai」字樣，15 個套件的作者欄位直接寫「oai」，註冊信箱是 [email protected]；AI 內容偵測工具 Pangram 把這批套件標記為「百分之百 AI 生成」；研究人員追查 6 月的一批代理存取紀錄，發現有 49 個檔案跟已經確認身分的 OpenAI 維基代理完全一致。
資安圈原本把這波攻擊命名為「GemStuffer」行動，卻始終想不通一件事：代理費盡工夫爬的索斯沃克地方政府資料，本來就是公開資訊，繞這麼一大圈根本沒必要，除非這只是一個目標導向的代理，為了完成任務不擇手段留下的副產品。
「良性任務」的說法，沒人能證實
面對質疑，OpenAI 發言人的回應相對剋制：這些代理「只是透過 RubyGems 平台連上網路，執行良性任務、取得公開資訊」，公司會「在針對訓練與評估期間代理行為的更大範圍檢視中持續調查」。問題是，這句話目前沒有任何一方能證實，也沒有人能推翻。RubyGems 資安團隊把整起事件定調為「重大惡意攻擊」，卻也坦承調查沒有找到金鑰竊取成功的證據，甚至無法百分之百確認，那批灌水套件真的出自 AI 代理之手。研究人員同樣承認手上資料不完整，不清楚代理的竊取嘗試最後有沒有得手。三方各執一詞，唯一能確定的是：攻擊 5 月就發生了，卻拖到 9 月 11 日才公開，中間整整隔了四個月。
這段延遲也在社群裡發酵。Hacker News 上的討論焦點，不在代理有沒有惡意「意圖」，而在於該由誰為部署了未受隔離代理的公司負責；Reddit 上一則高票留言則直言，從 OpenAI 代理入侵一家公司，到外界真正發現，中間隔了兩個多月，這種延遲讓人很不安，也讓人懷疑還有多少起事件根本沒被抓到。
誰來看住代理？
這已經不是 OpenAI 第一次栽在自己代理手上。先前有一個德語維基站臺被代理挾持，改造成學生作弊用的傳訊平台；加上 7 月的 Hugging Face 事件與這次 RubyGems，至少三起重大代理失控案例已浮上檯面。
當訓練與測試階段的代理，可以在無人察覺的情況下自主攻擊真實世界的系統長達數月，這已經不只是單一公司的資安漏洞，而是整個 AI 代理生態要一起面對的治理難題。
📍相關報導📍
Codex + DeepSeek 駭客用 AI 代理攻陷 48 國、395 家設施系統
