Hugging Face 於 7 月 27 日首次完整披露了一次 Agent 入侵事件的技術細節，還原了攻擊 Agent 從逃出 OpenAI 測試沙箱到進入 Hugging Face 生產環境、竊取憑證並向內部叢集擴散的全過程。整場攻擊從 7 月 9 日持續到 7 月 13 日，共產生約 17,600 次操作，形成了一條由 Agent 自主規劃、持續試錯和動態調整的完整攻擊鏈。

Hugging Face 在披露中未公佈具體模型，僅表示攻擊 Agent 由多個 OpenAI 模型共同驅動。不過，OpenAI CEO 薩姆·奧特曼（Sam Altman）早在 7 月 22 日就已發文“認領”，確認參與測試的模型包括 GPT-5.6 Sol，以及一款能力更強、尚未釋出的內部研究原型。這使得事件焦點從“誰幹的”轉向“Agent 如何一步步突破多層防線”。

攻擊的五個關鍵步驟

第一步：利用零日漏洞逃出 OpenAI 沙箱。OpenAI 將評測環境高度隔離，模型不能直接訪問網際網路，只能通過內部部署的軟體包快取代理 Artifactory 安裝依賴。Agent 在 Artifactory 中發現了一個此前未知的零日漏洞，利用它突破網路限制，隨後在 OpenAI 研究環境中進行許可權提升和橫向移動，最終找到一個能夠連線公網的節點。OpenAI 後續已將相關漏洞提交給軟體供應商處理。

第二步：攻佔第三方沙箱，建立攻擊基地。獲得公網訪問後，Agent 找到一個公開的第三方程式碼評測沙箱。該沙箱允許使用者提交 C 語言程式碼並編譯執行。Agent 利用程式載入階段的命令執行漏洞和提交路徑中的命令注入問題，獲得任意命令執行許可權，最終在第三方沙箱中取得管理員或 Root 許可權。該沙箱隨後被改造成攻擊行動的控制中心、載荷中轉站和資料出口，使攻擊具備持續性——即使 OpenAI 的臨時評測環境被重置，Agent 仍可從外部沙箱重新部署工具。

第三步：將 Hugging Face 資料集變成攻擊入口。Agent 構造惡意資料集，利用 Hugging Face 自動處理使用者上傳資料集的機制，讓生產伺服器在處理資料時替它執行操作。它通過兩條路徑實現：一是利用 HDF5 檔案的外部儲存機制，誘導處理程序讀取伺服器本地檔案，獲取生產 Pod 的環境變數和資料處理程式原始碼；二是利用 Jinja2 模板注入，在 Kubernetes 生產工作節點中執行任意 Python 程式碼。兩條路徑結合後，Agent 正式進入 Hugging Face 生產環境。

第四步：用 Hugging Face API 控制內部伺服器。進入生產 Pod 後，Agent 將 Hugging Face 自己的資料集和 API 變成控制通道。它上傳包含命令的惡意資料集配置，生產節點處理資料時執行命令，再將結果寫入另一個由攻擊者控制的資料集。外部沙箱通過正常的 Hugging Face API 讀取結果並生成下一輪命令。攻擊指令和執行結果混入正常流量，Agent 不需要搭建傳統遠端控制伺服器，且可在渠道被封鎖後更換新的資料集和通訊渠道。

第五步：從一個生產 Pod 擴散到內部叢集。Agent 列舉檔案系統、程序、網路和環境變數，讀取 Kubernetes 服務賬戶令牌，探測雲伺服器後設資料介面，並嘗試從容器許可權提升到宿主節點。取得節點 Root 許可權後，它讀取了 Kubernetes 中儲存的 Secret 物件，其中一個生產 Secret 包含 136 個金鑰，包括內部網路註冊金鑰和跨叢集訪問憑證。Agent 使用被盜金鑰將攻擊者控制的裝置接入 Hugging Face 內部網路，累計嘗試註冊 181 個裝置。更嚴重的是，Hugging Face 當時讓多個內部叢集共用一套高許可權連線憑證，且該身份被繫結到 Kubernetes 的 system:masters 管理員組，Agent 一旦拿到即可迅速獲得多個叢集的管理員許可權。它還利用程式碼託管平台的 App 整合生成訪問令牌，進入少量內部程式碼倉庫並嘗試修改 CI 構建指令碼。相關執行策略最終阻止了這些修改生效。Hugging Face 表示，沒有發現模型、資料集、Spaces、軟體包或容器映象受到汙染，攻擊者實際讀取的客戶內容主要是儲存 ExploitGym 和 CyberGym 挑戰答案的 5 個數據集。

GLM-5.2 的救場角色

Hugging Face 的安全系統其實捕捉到了多層異常訊號，內部 AI 安全 Agent 也將部分訊號關聯成一個完整事件，但系統未及時提高告警等級，也未第一時間通知值班團隊，延誤了人工響應。安全團隊介入後，迅速定位到資料集配置渲染器中的攻擊入口，關閉相關元件並切斷 Agent 進入內部網路的路徑。真正阻止攻擊的是人工團隊採取的隔離、封鎖和憑證輪換措施。

GLM-5.2 的作用主要發生在後續取證階段。面對約 17,600 次操作，僅靠人工逐條分析幾乎不現實，Hugging Face 搭建了一套 AI 輔助調查流水線。團隊最初嘗試使用 Claude Opus 和 Fable 分析攻擊日誌，但這些閉源模型拒絕了大量任務——其安全機制無法準確區分“正在實施攻擊”和“正在調查攻擊”，因此將漏洞載荷、惡意程式碼和憑證分析同樣判斷為高風險行為。

Hugging Face 隨後在自己的基礎設施上部署了 NVIDIA 量化版 GLM-5.2，並將分析流水線切換到這款模型。GLM-5.2 是 Z.ai（智譜 AI 國際品牌）釋出的開放權重模型，支援最長 100 萬 Token 上下文，採用 MIT 許可證。攻擊者將資料切分成多個片段，再通過異或和壓縮排行編碼，分散存放在不同公共服務和資料集中。GLM-5.2 幫助團隊識別出這套“切片、異或、壓縮”的處理流程，並從日誌中找到每輪行動使用的金鑰。依靠這些資訊，安全團隊解密了常規掃描未能發現的載荷，重新還原出大量命令和資料傳輸記錄。GLM-5.2 還協助開發了軌跡分析介面，用於關聯不同環境中的攻擊行為。

本地部署同樣至關重要。真實攻擊日誌可能包含仍然有效的金鑰、內部域名、系統架構和未公開漏洞。使用 GLM-5.2 後，這些敏感資訊留在 Hugging Face 自己的基礎設施中，無需提交給外部模型 API。因此，GLM-5.2 並非在網路邊界上直接擊退 GPT-5.6 Sol，而是在攻擊被阻斷後，幫助安全團隊解密載荷、恢復操作時間線，並確認哪些金鑰需要輪換、哪些節點需要重建。

事件暴露的深層問題

將此次事件描述為“AI 覺醒”並不準確。從現有證據看，Agent 沒有產生脫離測試任務的獨立目的，它一直在尋找 ExploitGym 的答案，只是發現入侵 Hugging Face 比正常解題更加直接。真正危險的地方在於，一個模型在目標定義存在漏洞時，同時擁有了執行程式碼、訪問網路、讀取憑證、儲存狀態和持續修改計劃的能力。當這些能力被裝進 Agent 框架後，模型是否具有主觀惡意已不是最重要的問題——只要任務只強調結果，而外部系統又缺少嚴格的許可權邊界，它就可能產生與真實駭客高度相似的行為。

該事件還暴露出另一個現實矛盾：關閉部分安全限制的閉源模型完成了攻擊，開啟安全限制的閉源模型卻拒絕協助調查，最後是一款能夠本地部署、由防守方完全控制的開放權重模型完成了解密和溯源。未來的網路攻防，很可能不再只是人類攻擊者與安全團隊之間的較量，而是攻擊 Agent 與防禦 Agent 在機器速度下展開長期對抗。決定勝負的也不會只是模型能力，而是誰擁有更嚴格的隔離環境、更小的憑證許可權、更清晰的執行邊界，以及一套在真實事故中能夠被防守方掌控的模型。