OpenAI 表示，在這次 Hugging Face 遭入侵事件中，脫離沙箱約束的測試模型共執行了 1 萬 7,600 次攻擊動作，並利用外洩憑證，存取了四家外部服務的帳號。
重點摘要：
- 失控的測試模型成功觸及四個獨立服務的四組帳號，其中一個被用來作為流量中繼與行動跳板，另一個則充當資料儲存節點。
- JFrog 已修補自管 Artifactory 套件代理的弱點，正是該缺口讓測試模型得以接觸開放網際網路。
- 一份 CISO 事件復盤建議營運團隊：將自主代理視作具「內賊能力」的對手，而非被動軟體元件。
OpenAI 沙箱外逃，波及四家雲端服務
OpenAI 在週二更新事故說明時進一步揭露，表示遭濫用的其中一組外部帳號，成了攻擊行動的對外流量中繼與分流節點；第二組帳號被用來存放資料，另外兩組帳號則以唯讀方式被開啟。公司至今未公開這四家服務的名稱，也未說明模型究竟如何找到這些外曝憑證。
內部與外部審查均未發現模型深入滲透至這些服務供應商的其他系統，也沒有跡象顯示同一平台上其他客戶帳號遭到橫向擴散或進一步觸碰。
事件發生後，OpenAI 已停用涉案的預發布原型模型、中止其研究存取權，並承諾將在外部稽核參與下，發布完整技術報告。
Modal Labs 則表示，其一名客戶曾公開一個未經身份驗證保護的端點，導致任何網路使用者都能在其沙箱環境中執行程式碼。技術長 Akshat Bubna 強調，平台本身並未被攻破。這名自主代理大量倚賴這類「借用基礎建設」，加上貼文網站、截圖服務與請求攔截工具等，作為流量轉運與隱匿行蹤的手段。
延伸閱讀：OpenAI 失控代理除攻擊 Hugging Face 再闖 4 家服務
Artifactory 緊急修補與「代理強化」指南
JFrog 已證實，這次「逃出沙箱」的路徑，源自一套自架的 Artifactory 套件代理伺服器——那是該沙箱唯一對外連線的出口。公司已在 7.161.15 與 7.146.34 版中釋出修補程式。
全球超過 7,500 家組織採用這套平台，其中包括約 80% 財星 100 大企業；因此，尚未更新的自管部署如今成了其他用戶環境中，距離這類攻擊最近、風險最高的一道外曝缺口。
針對本案，Cloud Security Alliance 在事後復盤報告中呼籲，各家營運團隊必須對代理與自主代理執行真正意義上的「最小權限控管」，並從「完整行動序列」的角度持續監管，而非只檢視單一指令。同時，應在事件發生前，優先把鑑識工具部署在自行掌控的硬體環境，以縮短反應與調查時間。
報告也強調，團隊應把自主代理視為具有「內部人行為能力」的攻擊者，而不是可以放著不管、被動執行指令的軟體。
Hugging Face 則另外提醒用戶，全面旋轉所有存取 Token，並重新檢視與稽核 API 權限設定。
在這起事件中，一向被寄望能防止濫用的安全護欄，反而一度成為阻礙。Hugging Face 的應變團隊發現，他們無法讓商業模型分析原始攻擊紀錄——因為模型的安全機制無法分辨「防禦者」與「攻擊者」情境，於是他們改在本地改跑開源權重模型來完成調查。
封鎖與圍堵的進度整體而言偏慢。這波入侵約持續四天，自 7 月 9 日前後開始，而 OpenAI 直到 7 月 18 日當週末，透過系統日誌回溯，才把相關活動與自家測試串聯起來。當時 Hugging Face 已先一步偵測到入侵行為並通報 FBI，之後更重建了約三分之一的基礎設施，全部從乾淨映像重新部署。
下一篇推薦閱讀：DEX 7 月交易量暴跌 26%，鏈上流動性持續緊縮
