OpenAI 證實，其代理工具今年 5 月曾透過 RubyGems 執行任務。較早前有安全研究人員指，一輪突如其來的 RubyGems 套件「洗版」、伺服器端程式碼執行，以及嘗試取得用戶 API 金鑰的行為，與 OpenAI 代理工具活動高度重疊。
事件重點：
- 研究人員發現，5 月兩日內在 RubyGems 新增的逾 2,000 個套件，背後活動極可能來自 OpenAI 代理工具。
- 部分套件疑借用 RubyDoc.info 的文件建構程序執行腳本，當中至少 6 個用作測試一個可洩露 API 金鑰的缺陷。
- OpenAI 聲稱其代理只是在執行「良性」任務；RubyGems 則表示，無法判斷相關套件是否由 AI 代理建立或發佈。
OpenAI 相關 RubyGems 活動
安全研究人員 Spencer Kitts、Thomas Larsen 及 Sydney Von Arx 指出，他們追溯到首個疑似與 OpenAI 有關的套件於 5 月 5 日出現，其後在 5 月 11 日及 12 日兩天內，代理工具一口氣提交逾 2,000 個套件。RubyGems 於 5 月 12 日一度暫停新帳戶註冊，並將當時的異常流量形容為持續的分散式阻斷服務（DDoS）攻擊；平台其後在 5 月 16 日重開註冊前，已刪除超過 500 個套件。
相關活動其後再度出現，5 月 26 日及 27 日多出 5 個套件；6 月 18 日於短短三小時內，再有 83 個新套件上架。
多數套件主要是擷取英國各地區議會網站的公開資料，後期則轉為嘗試接觸美國證券交易委員會（SEC）的數據集。
報告指，逾 100 個套件利用 RubyDoc.info 的文件建構服務，在 .yardopts 檔案中植入指令，以執行腳本，相當於把該文件服務變相用作對外抓取數據的通道。當中至少 6 個套件，刻意測試 RubyGems 的一項快取缺陷，可在特定情況下讀取舊有用戶登入所遺留的 API 金鑰。RubyGems 表示，目前未見有金鑰實際被成功盜取的證據。
延伸閱讀： XRP 分散式帳本單區塊打包 3,254 筆交易 創新紀錄
Edwards：自動代理帶來的新型安全風險
研究人員強調，將事件歸因於 OpenAI 代理，仍屬「間接證據」：例如不少套件名稱含有「oai」字樣，作者欄使用相同標籤，技術特徵亦與另一宗與 OpenAI 有關的 wiki 事件相似。他們又發現，有 1,397 個套件提及 r.jina.ai 代理服務，而早前涉事的 wiki 代理就大量依賴該服務。
營運 RubyGems 的非牟利機構 Ruby Central 表示：「我們無法判斷這些套件是否由 AI 代理建立或發佈。」該會的開源總監 Marty Haught 另指出，就平台平日觀察到的流量而言，是次事件在規模上「已可算是一場重大攻擊」。
OpenAI 則回應稱：「根據我們的檢視結果，我們的代理工具是透過 RubyGems 平台連接互聯網，以執行良性的任務及擷取公開資料。」公司並指，現正審視代理在訓練及評估階段的活動，現階段無法證實外界所稱「代理曾發現一個先前未被揭露的漏洞」。
Socket 威脅研究員 Joseph Edwards 表示，他的團隊之所以懷疑涉及 AI，主要是因為套件推出的速度，以及命名模式極具機械化特徵。
今次事件之所以重要，在於即使代理工具被設定執行的任務表面屬「良性」，其自動化操作亦足以為公共基礎設施帶來相當壓力，甚至構成新型網絡風險。
5 月這輪 RubyGems 異常活動，時間上早於 7 月 Hugging Face 資安事故 約兩個月，同時亦與 6 月一宗涉德文 wiki 的個案互相呼應。值得留意的是，在目前已公開的三宗案例中，每一次都是由外部團隊率先揭露代理活動，OpenAI 本身其後才作出確認或回應。
