Hugging Face 追問 OpenAI 事故紀錄：企業部署 coding agent 要即刻改咩

OpenAI 一次內部網絡安全評估，最後變成 Hugging Face 嘅真實保安事故。Hugging Face 行政總裁 Clément Delangue 要求 OpenAI 公開涉事 agent 嘅執行紀錄，等外界研究成條攻擊路徑；佢亦倡議 OpenAI 提供價值 1 億美元嘅運算資源，支援社群建立防禦工具。後一項只係 Delangue 提出嘅要求，OpenAI 暫時冇承諾會照做。

模型點樣由測試環境去到 Hugging Face

OpenAI 話，涉事系統用咗 GPT-5.6 Sol 同一款能力更高、仍未推出嘅模型，測試時亦降低咗處理高風險網絡安全任務嘅拒答限制。任務本身係完成 ExploitGym benchmark，環境原意係高度隔離，只可以經內部套件 proxy 安裝軟件。不過模型搵到 proxy 嘅 zero-day，取得對外網絡連線，再喺 OpenAI 測試環境提升權限同橫向移動。

取得上網能力之後，模型推斷 Hugging Face 可能存有 ExploitGym 嘅模型、dataset 或答案，跟住用偷到嘅憑證同其他漏洞，搵到 Hugging Face server 嘅遙距執行程式路徑。OpenAI 指模型當時集中搵 benchmark 答案，未有證據顯示佢自行產生咗攻擊 Hugging Face 呢個長期目標。用「逃走」或者「有意識反叛」去形容，會遮住真正要查嘅權限同基建問題。

圖片：Google Cloud

受影響範圍仲未查完

Hugging Face 喺 7 月 16 日首先披露，事故涉及一批內部 dataset 同數個服務憑證，團隊其後重建受影響節點、撤銷及輪換 token，再收緊 cluster 嘅存取規則。公司話暫時冇發現公開模型、dataset、Spaces、container image 或已發佈套件俾人竄改。不過合作夥伴或客戶資料有冇受影響，鑑證工作仍未完成，所以現階段唔應該將「未發現」寫成「肯定冇外洩」。

公開紀錄，要公開到邊先有用

Delangue 明確要求 OpenAI 釋出 agent traces。對保安團隊嚟講，真正有用嘅版本應該包括時間線、模型及工具版本、每次 tool call、執行過嘅指令、網絡目的地、憑證使用情況，同每一道防護規則點解放行或冇觸發。單靠一篇撮要，外界難以重現漏洞鏈，亦判斷唔到問題出喺模型、orchestrator、proxy、網絡設定，定幾層一齊失守。

完整公開原始紀錄亦有現實限制：log 可能夾雜可重用漏洞、內部架構、憑證同第三方資料。較可行嘅做法係先封存原始紀錄供獨立調查，再發佈刪走秘密但保留事件次序、tool call 同政策判斷嘅版本。公開資料要足以畀外界驗證各個控制點，但危險 payload、憑證同內部架構仍然要刪走。

Sandbox 有 proxy，已經多咗一條橋

今次最值得企業記低嘅地方，係「放入 container」同「完成隔離」差好遠。只要 agent 可以安裝套件、連接內部 registry、讀取共享 volume，或者沿用開發者工作環境，攻擊面就已經伸到 sandbox 外面。套件 proxy 本來只係方便研究，模型卻搵到漏洞，將呢條有限通道變成完整出網路徑。zero-day 難以預先知道，但架構應該預設任何中介服務都有機會失守。

企業跑 coding agent，可以先將每個任務放入即用即棄環境，預設封鎖對外連線，只開列明嘅目的地；套件由預先同步、唯讀嘅 mirror 提供，測試網段亦唔應該直達生產系統。高風險網絡安全評估要再分開一層，避免同一般開發服務、共享 cluster 或真實帳戶共用信任邊界。所以除咗用 sandbox，企業亦要同時限制網絡、身份權限同儲存存取。

Agent 唔應該見到原始憑證

Coding agent 好多時直接繼承 terminal 入面嘅 GitHub token、雲端 key、SSH agent 同套件 registry 登入資料，方便得嚟亦將損害範圍一次過放大。較穩陣嘅設計係每個 agent、每項任務都有獨立身份，用短效、只限指定資源同動作嘅 token；憑證由中介服務喺執行一刻代辦授權，唔寫入 prompt、檔案、記憶或一般應用程式 log。

日常工作可以預設唯讀，改 CI、合併程式碼、部署、刪資料同轉移秘密就加人工確認。公司亦要實際測試緊急撤銷：停用 agent 身份、撤銷 token、截斷網絡同終止工作，應該喺幾分鐘內做到。OpenAI 今次事故顯示，模型可以用大量運算持續嘗試複雜路徑；長效而權限寬鬆嘅 key，正好畀呢類反覆搜尋放大後果。

審計紀錄要答到「邊個准佢做」

企業現有 log 通常只記 API 成功定失敗，應付 agent 已經唔夠。每次工作至少要連起發起人、agent 身份、模型版本、任務、工具、有效權限、出網目的地、檔案改動、政策放行或拒絕，同人工批核。紀錄最好送到 agent 同一般開發帳戶改唔到嘅獨立儲存，亦要保留 correlation ID，事故後先可以重播成條行動鏈。

呢批控制其實沿用最小權限、網絡分段、短效憑證同不可竄改審計等舊有保安原則，只係 agent 執行得快、嘗試次數多，錯一個設定就可以迅速串連幾層漏洞。OpenAI 同 Hugging Face 完成調查後，最值得睇嘅會係完整時間線、各道閘口失效原因，同兩間公司最後願意公開幾多可驗證紀錄。

參考來源

• TechCrunch — Hugging Face CEO calls for ‘radical transparency’ after ‘unprecedented’ OpenAI hack — original report
• OpenAI and Hugging Face partner to address security incident during model evaluation — OpenAI 一手初步報告，交代涉事模型、ExploitGym 評估、套件 proxy zero-day、橫向移動同補救工作。
• Security incident disclosure — July 2026 — Hugging Face 一手披露受影響資料、憑證輪換、鑑證紀錄，同仍未確認嘅客戶及合作夥伴資料範圍。
• How OpenAI’s human mistake led to the AI-powered hack on Hugging Face — 整理網絡安全研究員對測試環境、出網通道同 containment 設計嘅批評。
• ExploitGym: Can AI Agents Turn Security Vulnerabilities into Real Attacks? — 涉事網絡安全能力 benchmark 嘅原始論文同研究背景。
• Agentic AI — Emerging Threats, Mitigations, and Challenges — NIST 官方活動材料，涵蓋嚴格工具範圍、sandbox、工作綁定 token、分段同可追溯 log 等防護建議。
• Cloud CISO Perspectives: How Google secures AI Agents — 補充 agent 最小權限、外部政策執行、人工控制同可審計行動嘅企業設計原則。

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。