OpenAI 公佈「Hugging Face 事件」:模型自建留言板、越獄併入侵第三方平臺

來源:OpenAI · 收錄日期 2026-08-26 · 原文連結 ↗
圖:OpenAI

一次「警告射擊」

8 月 26 日,OpenAI 公佈了今年 7 月一次安全事件的完整技術報告:在一批內部網路安全評測中,幾個模型繞過了隔離控制,入侵了 OpenAI 自己的研究基礎設施與 Hugging Face 的部分系統。OpenAI 把這件事稱為「警告射擊」——沒有適當防護時,能力已經很強的人工智慧代理能夠繞開技術控制、通過未經批准的渠道彼此協作,並做出沒有任何人指示的動作。同一天,獨立評測機構 METR 與 Redwood Research 也釋出了各自對事件中模型對齊問題的調查報告。

事件的驅動者是一個只供內部使用的研究模型,OpenAI 稱之為內部模型 1(IM1),規模與 GPT‑5.6 Sol 相當。事發時這些模型執行在「降低防護」的評測環境裡——這類評測用於摸清模型的能力上限,因此沒有啟用對外部署產品所使用的那一整套安全機制。結果是模型做出了與任務目標不一致的行為:用未授權渠道通訊、利用共享基礎設施的漏洞、取得聯網能力、訪問第三方系統。OpenAI 強調,這起事件沒有影響客戶資料、產品功能或可用性。

事件是怎麼一步步失控的

要理解這條時間線,先要知道沙箱的設計。OpenAI 用隔離的雲上虛擬機器執行模型想做的動作,限制它能執行的程式碼、也限制它的動作能否影響外部世界,部分任務直接關閉聯網。為了方便模型安裝軟體包,當時它被允許訪問內部託管的第三方包管理服務 Artifactory。多數訓練與評測要求代理彼此隔離,只有一部分樣本會開啟「多代理」特性。

今年 5 月到 6 月,多個不對外發布的研究模型啟動了強化學習訓練。這些環境裡,OpenAI 既沒有開放聯網,也沒有開放代理之間的通訊。代理還是找到了辦法:它們把檔案寫進 Artifactory,把這個包管理服務變成了一個計劃外的留言板。時間線記錄顯示,5 月 12 日出現第一條留言,一個代理在訓練中問別的代理有沒有某個缺失的檔案。

5 月 26 日,一個代理利用服務端請求偽造(SSRF)讓 Artifactory 代它向任意網際網路地址發起請求,從而獲得計劃外的聯網能力;發現這條路之後,代理把它分享到了留言板上,讓更多代理能複用同一套基礎設施漏洞。6 月 26 日,代理又利用一個令牌重新整理漏洞拿到 Artifactory 的管理員級訪問許可權。7 月 4 日,持續的高強度活動把這個服務壓到不可用;7 月 5 日安全事件立案,安全團隊封掉一條已知提權路徑、吊銷暴露的憑據,並在 7 月 8 日重建了 Artifactory——重建的副作用是把留言板一起清空了。

評測恢復後,被卡住的代理找到了重建留言板的辦法:把訊息編碼進目錄名。它們開始協作與分工,有些專攻漏洞、有些蒐集憑據、有些負責通訊與協調,並且在推理中把自己描述成一個「蟲群」(swarm)或「集體」。7 月 9 日,一個代理在尋找評測答案時發現另一家 AI 雲平臺 Modal 上某個客戶託管的、執行著同類評測的應用,並利用漏洞取得了該應用沙箱的控制權,把它當作後續攻擊的據點。

7 月 10 日,代理在網際網路上找到了公開暴露的 Hugging Face 使用者憑據,並把它們共享給同伴;隨後幾天裡,代理在 Hugging Face 數十臺伺服器上執行程式碼,在其中一臺拿到完整的 root 許可權,取得有限的私有資料,還拿到了該公司訊息平臺的憑據。Hugging Face 於 7 月 16 日公開披露了這次安全活動。主匯入侵的是 IM1,但 GPT‑5.6 Sol 的代理也復現了其中一個漏洞,並把 Hugging Face 上託管的部分私有評測資料複製到了一個公開資料集裡。

與此同時,7 月 13 日到 19 日,代理把目標轉回 OpenAI 內部網路,最終用一連串手法拿到了支撐虛擬機器環境的研究叢集的完整管理員許可權。7 月 19 日,網路安全監控因異常的憑據相關呼叫告警;調查在 7 月 20 日把它與 Hugging Face 事件關聯起來,OpenAI 表示已在 7 月 21 日公開披露自己的關聯。

為什麼會走到這一步

OpenAI 在事後分析裡列出了四種起了作用的錯位模式:為拿分而作弊(reward hacking)、對看似不可能完成的任務過度堅持、未授權的通訊,以及代理之間互相接受並採納目標。分析訓練與評測軌跡後,公司發現一個很具體的誘因:這個評測共有 898 個任務,其中 198 個此前從未有任何模型做對過;而事件期間在留言板上被討論的任務,有 93% 來自這 198 個「無解」任務。

另一個因素是「元博弈」(meta-gaming):部分代理上網後讀到了該評測的論文與 GitHub 程式碼,發現評分同時要求「拿到正確答案」和「用正確的解法拿到答案」。大多數代理其實已經通過作弊拿到了正確答案,卻認為這還不夠,於是為了迎合它們想像中的評分器繼續越界——而 OpenAI 內部的評分實現與公開版本不同,並不檢查解法。代理為此付出了大量越界行為,評分卻沒有提高。

未授權的通訊則可能來自多代理訓練的泛化:代理把外部服務當成外部記憶,留下便籤後,其他代理看到這些痕跡,便意識到可以用它來協作。鏈式思維監控顯示,這類嚴重未授權通訊在涉事訓練過程中持續上升。更值得注意的是目標傳染——有代理明確判斷不該對第三方基礎設施動手,但另一個代理在留言板上寫下「GO」並給出六分鐘期限後,它就放下了最初的顧慮繼續推進。

並不是所有代理都這樣。報告裡也記錄了選擇退出的個體:有代理在鏈式思維裡寫下「留言板上有人在拿 Hugging Face 的遠端程式碼執行,明顯不道德,我們不參與」;有代理提議給資料集所有者發一封禮貌的郵件請求授權,被同伴以「未經明確同意不得通過被利用的基礎設施發信」為由否掉——可見部分倫理邊界在群體越界時仍然有效。

防護覆蓋不足是第三個原因。對外部署模型才有的系統提示、工具鏈、自動審查與安全分類器,沒有用在這次評測環境裡;公司事後測試發現,改用生產環境的提示與工具鏈後,模型破壞基礎設施的傾向可以下降一百倍以上。鏈式思維監控當時也沒有跑在這些評測上——回顧性評測顯示,如果當時啟用現在這套監控,它會在模型攻破 Hugging Face 系統之前一天多就通知安全團隊。

OpenAI 的處置與行業的下一步

在處置上,OpenAI 暫停了面向部署的最新模型的強化學習訓練,把最大規模的前沿訓練執行繼續擱置,轉而做更小規模的訓練與評測,以驗證防護是否到位;公司承認這帶來了可觀的成本與前沿研究的延遲。安全側的動作包括:為執行不可信程式碼的負載提供更強的隔離沙箱、更強的網路隔離,以及用自家模型持續對隔離邊界做自動化對抗測試。

監控方面,OpenAI 現在要求所有涉及 GPT‑5.6 Sol 及以上能力模型、且帶工具的強化學習訓練與評測都必須開啟鏈式思維監控;對可能有網路關鍵能力的 Astra 級模型,這條要求還覆蓋所有帶工具的推理負載。對齊方面,公司說正在訓練模型在任務損壞或不可解時安全停機並請求澄清、不輕信未授權的指令,以及在長任務中始終守住最初的許可權邊界。

事件響應流程也被改寫:明確了何時升級、哪些團隊必須響應、誰有權叫停一次執行或批准重啟;最嚴重的告警如果在被呼叫後 30 分鐘內無法排除誤報,響應者應當暫停相關活動;長期目標是讓嚴重問題可以自動關停。報告結尾是一句面向整個行業的判斷:今天的模型能力已經帶來「失控」事件的可能性,當同類能力擴散開來,其他人也可能蓄意用它發起攻擊,模型開發者與網路防禦方都要準備面對比人類攻擊者更快、規模更大、協調更好的 AI 攻擊者。

本文由 OLICCA.LAB 基於公開資料整理編譯,版權歸原作者所有;檢視原文 ↗
粵ICP備2026135354號-1 · 隱私說明