Hugging Face 揭露一起由自主 AI agent 驅動的入侵，攻擊者留下逾 17,000 筆記錄事件，一批內部資料集與數個服務憑證遭波及。更尷尬的是事後鑑識，商用前沿模型因安全護欄拒絕處理真實攻擊指令與 C2 產物，資安團隊只好改用 Z.ai 的開源權重模型 GLM 5.2 在自家機器上完成分析。
（前情提要：假 OpenAI 開源模型登 Hugging Face 冠軍！24 萬次下載暗藏惡意軟體）
（背景補充：Google、Meta 研究員聯手喊話：AI Agent 安全不是模型問題，是系統問題）
重點摘要
- Hugging Face 7 月 16 日揭露入侵事件，攻擊者留下逾 17,000 筆記錄事件
- 入口是惡意資料集，串起遠端程式碼載入器與模板注入兩條執行路徑
- 商用前沿模型護欄擋下鑑識請求，改用 Z.ai 開源權重模型 GLM 5.2 收尾
開源 AI 社群龍頭 Hugging Face 在 7 月 16 日發出資安事件揭露，坦承生產環境的一部分遭到入侵，而這場入侵從頭到尾由一套自主 AI agent 系統驅動。攻擊者在系統內留下超過 17,000 筆記錄事件，波及內部資料集，以及數個內部服務使用的憑證。
Hugging Face 的官方說明指出，這份資料集同時濫用了資料集處理流程中的兩條程式碼執行路徑，一條是遠端程式碼資料集載入器，另一條是資料集設定檔裡的模板注入漏洞。兩條串起來，就足以讓攻擊者在處理節點上跑自己的程式，接著往內部叢集橫向移動，收割雲端與叢集憑證。
官方的描述是「一群跑在短命沙盒裡的自動化小程式」，指令與控制基礎設施還會自己搬家，寄生在公開服務上。這種攻擊方式只有 agent 做得出來。
防守方請不動模型
真正的麻煩出現在事後鑑識。要重建完整的攻擊時間軸，分析人員得把大量真實攻擊指令、exploit payload 與 C2 產物餵進模型，而這些東西正好就是安全護欄設計來擋的內容。Hugging Face 寫得很直白，這些請求「被供應商的安全護欄擋下」。
攻擊者不受任何使用政策約束，我們自己的鑑識工作卻被一開始採用的託管模型護欄擋住。
英文原句是「The attacker was bound by no usage policy, while our own forensic work was blocked by the guardrails of the hosted models we first tried.」Hugging Face 全程沒有點名是哪幾家供應商，只說是「一開始採用的託管模型」，但想也知道是美國的主流模型。
最後是中國開源模型收尾
Hugging Face 改用中國新創 Z.ai 的 GLM 5.2 完成鑑識，這是一款六月中旬才發布的開源權重模型，總參數約 7,530 億。關鍵不在跑分，在於它可以整包架在自家機器上跑。
執行長 Clem Delangue 的說法更白：「當你正處理一起進行中的事故，你不能讓工具拒絕檢視惡意 payload，或是反過來把你的帳號標記起來。」他補了一句，攻擊者早就在用 agent，而他們顯然不遵守任何護欄。
Hugging Face 表示，自己並不知道攻擊者的 agent 背後掛的是哪一個模型，可能是被越獄的託管模型，也可能是完全不受限的開源權重模型。這其實不重要，不管是哪一種，攻擊方都不需要通過任何使用政策的審查，防守方需要。
災情範圍目前看起來有限。Hugging Face 說沒有證據顯示公開的模型、資料集、Spaces 或軟體供應鏈遭到竄改，調查仍在進行，會直接聯繫受影響的對象。零信任資安公司 Zero Networks 的 field CTO Chris Boehm 也點出同一個諷刺，為了防禦而設計的安全工具，反過來拖住了資安事故的應變，當下的窘境。
常見問題
Hugging Face 這次被駭外洩了哪些資料？
遭波及的是一批內部資料集與數個內部服務憑證，攻擊者留下逾 17,000 筆記錄事件。官方表示沒有證據顯示公開模型、資料集、Spaces 或軟體供應鏈遭竄改，調查仍在進行。
為什麼商用 AI 模型會拒絕協助資安鑑識？
鑑識得把大量真實攻擊指令、exploit payload 與 C2 產物送進模型，而這些正是安全護欄設計來攔截的內容。護欄讀內容不讀意圖，分不出提問者是攻擊者還是防守方，因此觸發拒答。
📍相關報導📍
Vercel 遭駭、加密開發者急換 API Key：AI 工具 Context.ai 成破口，Web3 前端供應鏈拉警報
