AI 開源平台 Hugging Face 近期公布了一起內部資安事件：一套自主 AI Agent 從頭到尾入侵它的生產環境，取得雲端與叢集憑證，並在一個週末內橫向移動，留下超過 1.7 萬筆操作紀錄。Hugging Face 同樣動用 AI 完成偵測與調查，形成一場機器對機器的攻防，然而真正讓外界議論的，不是這場攻防本身，而是調查途中卡在一個誰也沒料到的過程：模型選擇。
一場由 AI Agent 端到端執行的入侵
Hugging Face 揭露，入侵發生在 7 月 13 日當週，起點落在 AI 平台最容易被攻擊的弱點之一：資料處理管線。一份惡意資料集利用處理流程中的兩個程式碼執行漏洞，在處理節點上執行程式碼；攻擊者隨後取得節點層級權限，蒐集雲端與叢集憑證，並在週末橫向移動進入多個內部叢集。
這場攻擊由一套自主 Agent 框架執行，透過大量短生命週期沙箱發動數千個動作，指揮控制節點還會自行遷移、藏身公開服務。這正符合業界討論已久的「代理式攻擊者」情境。至於攻擊者用的是哪款大型語言模型，Hugging Face 坦言仍無法確定，但表示目前沒有發現公開、面向使用者的模型、資料集或 Spaces 遭竄改，軟體供應鏈（容器映像檔與已發布套件）也經驗證乾淨。
因應措施上，Hugging Face 已修補初始漏洞、重建受影響節點、撤銷並輪替憑證與權杖，並收緊叢集准入控制、強化偵測告警，同時與外部鑑識專家合作、向執法機關通報。對一般使用者，該公司建議輪替存取權杖、檢視近期活動紀錄。
1.7 萬筆攻擊紀錄，商業模型要分析卻卡在安全機制
這起事件最初由 AI 協助偵測浮現：Hugging Face 的異常偵測管線會用大型語言模型對資安遙測做初步分類，把真訊號從雜訊中分離。為理清數萬個自動化動作，團隊再讓 LLM 分析代理跑過完整攻擊紀錄，重建時間線、萃取入侵指標、盤點被觸及的憑證，原本要數天的工作在數小時內完成。
然而問題出在模型選擇被意外限制。Hugging Face 表示，團隊一開始使用商業大型語言模型 API 協助分析，但分析過程需要輸入大量真實的攻擊指令、Exploit Payload 與 Command-and-Control（C2）相關內容。由於商業模型的安全機制無法區分「資安調查人員」與「攻擊者」，相關請求不斷觸發防護機制而遭到拒絕，導致調查流程無法順利進行。
根據 Hugging Face，改用開源的 GLM-5.2、跑在自家設施上後，鑑識才得以完成，並帶來另一好處：攻擊資料與相關憑證全程未離開自家環境。Hugging Face 特別聲明，這不是反對託管模型的安全措施，而是提出攻擊與防守方不對稱的難題：攻擊者不受任何使用政策約束，防守方卻被託管模型鎖在門外，並已把回饋分享給供應商。
選模型只看能力與成本就夠了嗎？
經過這次事件，Hugging Face 的具體建議是在事件發生前，就備妥一款能在自家設施運行、且已通過審核的高能力模型。理由有二，一是避免防護機制在關鍵時刻把人擋在門外，二是讓攻擊資料與憑證等敏感內容不外流。
《The Stack》則認為，這是一次相當值得關注的公開案例，重點不是模型來自哪個國家，而是這起事件具體展現，模型的部署方式與控制權，可能直接影響資安事件的處理效率。
過去企業導入 AI 時，最常比較的是模型能力、成本、推理速度與基準測試成績；但 Hugging Face 這次事件提醒企業，未來評估 AI 模型時，也可能需要思考模型是否能在高敏感度的情境下持續運作，並讓企業保有足夠的部署與控制能力。
【推薦閱讀】
◆ 首個 AI Agent 端到端勒索攻擊案例曝光：JadePuffer 給 CISO 的 3 大警訊
＊本文開放合作夥伴轉載，資料來源：Hugging Face、《The Stack》、《TechRepublic》，首圖來源：擷取自 Hugging Face
