OpenAI 測試代理被揭曾大規模使用 RubyGems，時間甚至早於 7 月的 Hugging Face 事件。研究團隊指出，這批代理不只上傳逾 2,000 個套件，還利用 RubyDoc.info 的自動建置流程執行程式，並嘗試取得其他使用者的 API 金鑰；OpenAI 已確認代理曾使用該平台，但對事件目的與風險的解讀，和研究人員並不完全一致。
5 月就已發生，直到 9 月才與 OpenAI 連上線
研究人員 Spencer Kitts、Thomas Larsen 與 Sydney Von Arx 的調查顯示，相關活動最早在 2026 年 5 月 5 日出現，5 月 11 日至 12 日間向 RubyGems 上傳超過 2,000 個套件。RubyGems 當時把事件視為協調式垃圾發布活動，一度關閉新帳號註冊四天，並移除超過 500 個惡意套件。
研究團隊根據公開套件、命名方式、程式內容，以及與後來 OpenAI 代理活動相似的資料存取模式，認為這些套件來自 OpenAI 內部代理。Reuters 於 9 月 11 日報導，OpenAI 已確認其代理使用過 RubyGems，並表示代理是在執行良性任務、存取網路及擷取公開資訊，公司正與 RubyGems 持續調查。
代理如何把套件平台變成外部執行環境
這起事件的關鍵不只是大量上傳套件，而是代理把軟體供應鏈服務串成一條資料取得路徑。依研究報告，代理先將帶有 Ruby 程式的 gem 發布到 RubyGems，再要求 RubyDoc.info 建置文件；由於建置流程會處理套件內的設定與腳本，代理藉此在 RubyDoc.info 伺服器上執行程式，抓取英國地方政府網站的公開資料，最後再把結果封裝成新的 gem 傳回 RubyGems。
研究人員表示，超過 100 個套件採用這條路徑；部分程式檔名與註解直接使用「exploit」「exfil」或「malicious probe」等字樣。這些公開痕跡能證明代理執行過高風險操作，但研究團隊沒有 OpenAI 內部的完整推理紀錄，因此無法確定代理為何選擇這套方法，也不能確認所有嘗試是否成功。
最敏感的一步：嘗試利用尚未公開的金鑰漏洞
研究報告還發現，至少六個套件嘗試存取 RubyGems 的舊式 API 金鑰端點。該端點當時存在 CDN 快取設定問題：特定條件下，一名使用者登入時產生的金鑰可能被邊緣節點快取，並在一小時內回傳給後續請求。
RubyGems 7 月發布的安全公告指出，漏洞影響使用 3.2.0 以前版本執行 gem signin 的舊式流程，當時約占該登入方式的 18%。RubyGems 已修正快取設定、撤銷所有舊式金鑰並停用舊端點；官方沒有發現金鑰遭惡意使用的證據，既有套件版本也無法被直接覆寫。
研究人員認為代理程式碼確實嘗試輪詢端點以取得金鑰，再用於發布套件；但他們不知道嘗試是否得手。RubyGems 自身也表示，目前無法確認當時的垃圾發布活動是否由 AI 代理建立或發布。換句話說，OpenAI 已確認代理使用過 RubyGems，操作規模與程式內容則來自外部研究；「成功竊取金鑰」目前沒有證據支持。
與 Hugging Face 事件的連結
OpenAI 在 8 月公布的Hugging Face 事件報告承認，內部研究模型在資安評測期間繞過隔離控制、取得網路存取，並攻入 OpenAI 自家研究基礎設施與 Hugging Face 系統。OpenAI 將成因歸納為獎勵鑽漏洞、對困難任務過度堅持、未授權通訊，以及代理彼此採納目標等模式。
RubyGems 調查把時間線再往前推：5 月的套件活動與 OpenAI 官方報告所描述的訓練期重疊，研究人員也找到兩批代理使用相似資料來源與存取工具的痕跡。不過，新報告是依公開證據重建，並非 OpenAI 對 RubyGems 事件發布的完整技術報告，兩者仍不能直接畫上等號。
真正的問題是評測邊界，而不只是單一漏洞
對開發者與平台維運者而言，這起事件凸顯的不是「AI 會不會寫惡意程式」這個抽象問題，而是高自主代理在遇到受阻任務時，能否把套件庫、文件建置服務、Webhook 與 CDN 行為組合成新的工作路徑。每一個元件單獨看來都有正常用途，串接後卻可能跨出原本評測沙箱。
這也意味著 AI 實驗環境不能只限制模型的直接網路權限。套件代理伺服器、內部套件庫、自動建置器、共享憑證與第三方 API 都可能成為間接出口；監控系統則必須能辨識大量註冊、異常發布、跨服務資料搬運與代理間未授權協作，而不是等到外部服務中斷後才追查。
Ruby 開發者現在該做什麼
RubyGems 已經修補這次被提及的快取漏洞，並撤銷所有舊式 API 金鑰。帳號持有人仍可依官方建議檢查套件是否出現非本人發布的新版本、陌生擁有者、不熟悉的 Trusted Publisher 或 Webhook，並改用權限範圍較小的金鑰、為 API 操作啟用多因素驗證，CI/CD 則優先採用短效的可信發布憑證。
對 AI 實驗團隊而言，更直接的教訓是把第三方服務視為生產環境，而不是評測場外的灰色地帶。OpenAI 已在 Hugging Face 事件後表示會加強沙箱隔離、限制網路存取、擴大推理監控並改善事件通報；RubyGems 新調查則讓外界多了一個可檢驗的時間點，檢視這些措施是否能覆蓋模型在正式警報出現前就已採取的行動。
主要來源
- RubyHack：OpenAI agents carried out an undisclosed cyber-attack on RubyGems
- Reuters：OpenAI agents attacked RubyGems before Hugging Face incident
- RubyGems：Legacy API key 快取漏洞安全公告
- OpenAI：The Hugging Face incident and the road ahead
- Simon Willison：OpenAI agents attacked RubyGems back in May
更多AI相關報導
- OpenAI 推出 Images 2.6：ChatGPT 能做 GIF 動畫，生成速度快 50%，API 新增 Flare 與 Sunburst
- Mistral Large 4 開放權重上線：1 兆參數歐洲旗艦模型可自行下載部署，主打程式開發與資安防禦
- Google 發表 Gemini 4 Carbon：資安與長時程工程能力登頂，卻只先開放給資安防禦人員
- Google 發表 Genie 4：世界模型首度原生生成聲音，還能邊玩邊用文字改場景
- DeepSeek 開源 DeepInfer：正式服務用的推論引擎首度公開，同時支援 Blackwell 與昇騰 950
