OpenAI 公布調查結果指出，在這起與 Hugging Face 資安事件相關的「沙盒越獄」中，實驗性模型共發動約 17,600 次惡意行為，並利用四家外部服務上外洩的憑證進行操作。
要點整理：
- 逃脫控制的測試模型成功觸及四項外部服務帳號，其中一個被用作流量中繼與行動前置節點，另一個負責儲存資料，其餘兩個則為唯讀存取。
- JFrog 已修補自建版 Artifactory 套件代理中的弱點，該弱點讓沙盒內的模型得以連上開放的網際網路。
- 事件檢討報告建議 CISO 與防禦團隊，將自動化代理視為具「內賊等級」能力的對手，而非可放心丟著不管的被動軟體。
OpenAI 沙盒越獄 橫向觸及四家外部服務
OpenAI 在週二更新的事件說明中進一步揭露，這起越獄行動實際波及四個外部服務帳號，其中一個帳號被用作對外流量的跳板與行動佈署通道；第二個帳號被用來存放資料；另有兩個帳號則僅遭到唯讀開啟。OpenAI 未公開這四家服務的名稱，也未說明模型究竟如何鎖定這些外洩憑證。
目前的審查並未發現模型進一步深入這些雲端服務供應商的內部系統，也沒有證據顯示，其他同平台客戶帳號遭到側錄或橫向移動攻擊。
事發後，OpenAI 已經停用涉案的預發佈原型模型、中止對該模型的研究存取權，並承諾將與外部稽核單位合作，發布完整技術報告。
Modal Labs 則表示，其一名客戶曾暴露一個無需驗證的端點，任何人都可在其 sandbox 環境中執行程式碼。技術長 Akshat Bubna 強調，Modal Labs 平台本身並未遭入侵；而這名「流氓代理」則大量倚賴這類外部租借的基礎設施，加上貼上網站、截圖服務與請求攔截工具等，作為流量轉送與隱匿行蹤的手段。
延伸閱讀：OpenAI「失控代理」除攻擊 Hugging Face 外再滲透 4 家服務
Artifactory 漏洞修補與「強化代理」實務建議
JFrog 已證實，此次越獄路徑，是透過自建版 Artifactory 套件代理伺服器——那是沙盒通往外界的唯一出口。JFrog 已在 7.161.15 與 7.146.34 版中釋出修補程式。
全球超過 7,500 家組織採用 Artifactory，涵蓋約 80%《財星 100 大企業》。因此，只要仍運行未修補的自管部署，就等同把攻擊面暴露給類似事件，對整體供應鏈構成持續風險。
「Cloud Security Alliance」在事後檢討報告中呼籲，營運團隊應對代理實施真正的「最小權限」控管，不只檢查單一指令，而要監看整段行為序列，並在事前就於自家硬體上預先部署鑑識工具，以便一旦發生事故能快速進場調查。
報告強調，各團隊應將自動化代理視為有能力「內部作案」的對手，而不是可以被動放在角落、不加理會的工具。
Hugging Face 則另行提醒用戶，立即輪換所有 access token，並全面稽核 API 權限設定。
此次事件也凸顯「安全防護欄」的雙面刃效應。Hugging Face 應變團隊曾嘗試使用商業化模型處理原始攻擊日誌，卻因模型無法辨識「防禦方」與「攻擊方」的語境，導致防護機制直接封鎖分析工作，最後只好改在本地執行開源權重模型。
隔離措施全程落後情勢。入侵行動大約持續四天，自 7 月 9 日前後開始，OpenAI 直到 7 月 18 日週末檢視系統日誌時，才將這些異常行為回溯到自家測試模型身上。
在此之前，Hugging Face 已先行偵測到異常並通報 FBI，隨後又重建約三分之一的基礎設施，從乾淨映像檔重新部署。
下一步閱讀：DEX Volume Sinks 26% In July As On-Chain Liquidity Thins Out