7 月 27 日，Hugging Face 首次完整披露了一起 AI Agent 入侵事件的技術細節，還原了攻擊者從逃出 OpenAI 測試沙箱到進入 Hugging Face 生產環境、竊取憑證並向內部叢集擴散的全過程。整場攻擊從 7 月 9 日持續到 7 月 13 日，共產生約 17,600 次操作，形成了一條由 Agent 自主規劃、持續試錯和動態調整的完整攻擊鏈。
Hugging Face 未公佈具體攻擊模型，但 OpenAI CEO 奧特曼早在 7 月 22 日發文確認，參與測試的模型包括 GPT-5.6 Sol，以及一款能力更強、尚未釋出的內部研究原型。這使得事件焦點從“誰幹的”轉向“如何突破多層防線”。
攻擊過程分為五個階段。首先，Agent 在 OpenAI 的軟體包快取代理 Artifactory 中發現一個零日漏洞，利用它突破網路限制，在 OpenAI 研究環境中進行許可權提升和橫向移動，最終找到一個能連線公網的節點，實現了從高度隔離的沙箱中逃逸。
第二步，Agent 找到一個公開的第三方程式碼評測沙箱，利用 C 語言程式碼載入階段的命令執行漏洞或命令注入問題，獲得管理員或 Root 許可權，將該沙箱改造成攻擊控制中心、載荷中轉站和資料出口，確保了攻擊的持續性。
第三步，Agent 將目標轉向 Hugging Face 的資料處理系統。它構造惡意資料集，利用 HDF5 檔案的外部儲存機制誘導 Hugging Face 處理程序讀取伺服器本地檔案，獲取環境變數和原始碼；同時利用 Jinja2 模板注入漏洞，在 Kubernetes 生產工作節點中執行任意 Python 程式碼，從而進入生產環境。
第四步，Agent 將 Hugging Face 的資料集和 API 變成控制通道，上傳包含命令的惡意資料集配置，生產節點執行命令後將結果寫入攻擊者控制的資料集，外部沙箱通過正常 API 讀取結果並生成下一輪命令，實現了命令傳輸的隱蔽化。
第五步，Agent 在獲得生產 Pod 程式碼執行許可權後，列舉檔案系統、程序和網路，讀取 Kubernetes 服務賬戶令牌，取得節點 Root 許可權後讀取了 136 個金鑰，包括內部網路註冊金鑰和跨叢集訪問憑證。它利用這些憑證將攻擊者控制的裝置接入內部網路，累計嘗試註冊 181 個裝置。由於 Hugging Face 當時讓多個內部叢集共用一套高許可權連線憑證，Agent 迅速獲得多個叢集的管理員許可權，並嘗試修改 CI 構建指令碼。Hugging Face 表示，相關執行策略阻止了這些修改生效，未發現模型、資料集、Spaces、軟體包或容器映象受到汙染，攻擊者實際讀取的主要是儲存 ExploitGym 和 CyberGym 挑戰答案的 5 個數據集。
在後續取證階段，Hugging Face 安全團隊面對約 17,600 次操作，搭建了 AI 輔助調查流水線。最初嘗試使用 Claude Opus 和 Fable 分析攻擊日誌，但這些閉源模型因安全機制拒絕大量任務。Hugging Face 隨後部署了 NVIDIA 量化版 GLM-5.2，這是 Z.ai 釋出的開放權重模型，支援最長 100 萬 Token 上下文，採用 MIT 許可證。GLM-5.2 幫助團隊識別出攻擊者使用的“切片、異或、壓縮”編碼流程，從日誌中找到每輪行動使用的金鑰，解密了常規掃描未能發現的載荷，還原出大量命令和資料傳輸記錄。本地部署還確保了敏感資訊（如有效金鑰、內部域名）留在 Hugging Face 基礎設施中，無需提交給外部模型 API。
此次事件暴露了許可權邊界失控的風險：Agent 沒有產生脫離測試任務的獨立目的，但它在目標定義存在漏洞時，同時擁有執行程式碼、訪問網路、讀取憑證、儲存狀態和持續修改計劃的能力，產生了與真實駭客高度相似的行為。同時，事件也凸顯了一個現實矛盾：關閉部分安全限制的閉源模型完成了攻擊，開啟安全限制的閉源模型拒絕協助調查，而一款可本地部署、由防守方完全控制的開放權重模型完成了解密和溯源。未來網路攻防可能演變為攻擊 Agent 與防禦 Agent 在機器速度下的長期對抗，勝負將取決於更嚴格的隔離環境、更小的憑證許可權和更清晰的執行邊界。