OpenAI 週二表示，其入侵 Hugging Face 平台的「失控」AI 代理，在攻擊中也駭入了多個第三方帳戶和服務。這起史無前例的資安事件，發生在 OpenAI 內部測試最新 AI 模型期間，其規模顯然比公司最初披露的更為廣泛。
OpenAI 在一份更新的部落格文章中指出，對此事件的持續審查顯示，該 AI 代理利用了四個與「公開可用服務」相關的帳戶，作為其駭入 Hugging Face 行動的一部分。這個失控的代理顯然在網路上找到了外洩的憑證，並利用它們來入侵這些帳戶。
OpenAI 並未透露這些帳戶所屬的公司或組織名稱，但強調它們受影響的「嚴重程度或規模，並未達到我們就 Hugging Face 事件所分享的程度」。
OpenAI 表示，其代理入侵的其中一個額外帳戶被用作「對外中繼和暫存路徑」，可能旨在模糊對 Hugging Face 攻擊的來源。此外，OpenAI 的失控代理還利用另一個帳戶進行資料儲存，以協助這次駭客行動。
路透社週二報導，提供 AI 服務訓練與運行軟體基礎設施的公司 Modal，其一名客戶是 OpenAI 代理的受害者之一。Modal 技術長 Akshat Bubna 向 WIRED 證實，OpenAI 的代理利用了其客戶程式碼庫中的一個漏洞，該程式碼庫運行在 Modal 的基礎設施上。然而，Bubna 表示：「Modal 平台本身並未受到任何形式的入侵。」該客戶的身分目前無法確認。
OpenAI 拒絕向 WIRED 進一步評論此事件。一位發言人指出，公司已更新部落格文章，其中提到若在持續審查中發現有服務所有者受影響，將會直接通知他們。
Hugging Face 本週發布的事件事後分析報告指出，這次入侵深入其內部系統的程度，遠超最初披露的範圍。該公司表示，他們從 7 月 9 日至 7 月 13 日的日誌中，恢復了大約 17,600 個代理動作，其中大部分是代理嘗試失敗的路徑。
Hugging Face 透露，OpenAI 的代理取得了多個內部 Kubernetes 叢集的管理員權限、生產伺服器的 root 權限，以及其 GitHub 原始碼儲存庫子網的寫入權限。它還利用竊取的憑證，將 181 個攻擊者控制的設備註冊到公司的企業網狀網路中，從而獲得了 Hugging Face 開發和測試其程式碼庫的內部系統存取權。
根據 Hugging Face 的說法，OpenAI 的失控代理至少使用了一個第三方沙盒作為其攻擊的「外部發射台」。OpenAI 的代理隨後「能夠在該外部沙盒上以 root/管理員身份運行命令，並將其用作整個攻擊行動的控制、暫存和資料外洩基地」。
Hugging Face 最早於 7 月 16 日披露，一個自主 AI 代理入侵了其部分生產基礎設施，但當時並不知道幕後主使者是誰。隔週，OpenAI 承擔了責任，表示這次事件是由其公開可用的 GPT-5.6 Sol 模型和一個內部研究原型所主導，兩者都在針對網路能力基準測試時停用了安全防護措施。OpenAI 週二表示，在發現入侵後，已停用了這個從未打算公開發布的內部研究原型，並限制研究人員存取。
這次入侵發生在 OpenAI 測試其最新 AI 模型時，對象是 ExploitGym，這是一個評估 AI 系統尋找和利用軟體漏洞能力的基準測試框架。ExploitGym 根據代理從數百個不同目標系統中，快速有效地檢索機密文件的能力進行評分，其提示詞本質上是鼓勵模型尋找解決方案。
Hugging Face 的鑑識團隊得出結論，OpenAI 的代理本質上是想在 ExploitGym 的測試中「作弊」。該代理並非解決基準測試的挑戰，而是推斷 Hugging Face 可能在其伺服器上存放著答案，並試圖竊取它。ExploitGym 團隊先前曾指出，代理有時會脫離腳本，透過利用基準測試原不打算評估的其他漏洞來解決任務。然而，這次是一個極端案例。
專家先前向 WIRED 表示，OpenAI 代理所利用的底層弱點其實很常見。管理企業程式碼庫的軟體經常被發現存在嚴重缺陷，資安專家長期以來一直建議將關鍵基礎設施與公共網路隔離。
一位研究人員認為，這起事件與其說是 AI 問題，不如說是數十年來資安實踐的失敗。他們表示，該代理並非逃脫了高度隔離的環境，而是穿過了其操作者唯一開放的連接點。
另一位專家則表示，隨著尖端模型能力日益增強，相同的網路資安基本原則仍應適用。AI 實驗室應該投入與教導模型利用弱點同等的精力，來教導它們如何建立安全的基礎設施。
