從 OpenAI 沙盒逃逸事件看 AI Agent 資安:風險鏈、多層防護與企業治理

OpenAI 先前在一場內部資安評測中,讓一組包含 GPT-5.6 Sol 與能力更強的內部研究模型的 AI Agent 持續挑戰 ExploitGym。這是一套測試 AI Agent 能否把程式漏洞發展成實際攻擊的資安評測基準。模型最後突破了評測使用的沙盒(Sandbox),也就是原本用來限制模型與外部系統互動的隔離環境,並影響 Hugging Face 的部分正式基礎設施(Production infrastructure)

這起事件帶出一個使用者擔憂的問題:如果連沙盒都能突破,現有的隔離措施還足以承接 AI Agent 日益增長的智慧與行動能力嗎?

本篇 Aiworks 將依 OpenAI 截至 2026 年 7 月 28 日公布的初步調查,說明模型如何在內部資安評測中突破沙盒並影響 Hugging Face,以及企業該如何透過多層防護與持續治理來限制事故影響。

OpenAI 沙盒逃逸事件:AI Agent 突破隔離環境的評測條件

ExploitGym 評測設定讓 AI Agent 得以執行高風險任務

ExploitGym 的目的,是觀察模型能否運用複雜攻擊路徑解決資安挑戰,藉此估算模型的能力上限。OpenAI 說明,參與評測的模型降低了對執行資安任務的防衛指令,評測也沒有啟用正式環境中用來阻止高風險資安活動的分類器(Classifier)。因此模型會持續追求測試目標,即使遇到隔離或環境限制,也不會像日常使用 AI 工具時一樣輕易停止。

這項調整讓研究人員能看見模型在較少限制下可以展現的能力到哪裡,卻也構成這起事件發生的背景條件之一。

用途受限的套件代理通道,成為沙盒逃逸入口

OpenAI 的評測環境有對外的連線權限,但沒有用以一般用途的直接連網。這項設定跟一般完全內網的企業環境不太一樣。為了評測,OpenAI 保留一條用途受限的套件取得通道。模型只能透過這個內部代管 Artifactory 代理與快取服務安裝套件。

但問題在於,模型並沒有把這項限制視為阻礙。它反而投入大量運算資源,在套件代理軟體中找到一項先前未知的零時差漏洞 (Zero day) ,進而取得離開隔離環境的路徑。OpenAI 後續已將這項漏洞及其他發現通報給軟體供應商。

模型取得突破隔離環境的路徑後,持續提升權限並橫向移動,直到抵達可連接網際網路的節點,接著接觸到 Hugging Face 的正式基礎設施。Hugging Face 表示,有限範圍的內部資料集與數個服務所使用的憑證遭到未授權存取。

AI Agent 資安風險鏈

攻擊路徑從套件代理漏洞延伸至正式基礎設施

沙盒逃逸只是一條風險鏈的起點。模型先利用研究環境內第三方套件代理的漏洞取得突破隔離環境的路徑,再於 OpenAI 的研究測試環境中提升權限、橫向移動,直到抵達可以連接網際網路的節點。接著,它推測 Hugging Face 可能存有 ExploitGym 相關模型、資料集與解答,便開始尋找可以直接取得評測答案的路徑。

OpenAI 表示,其中一條路徑串連了遭竊憑證與多個零時差漏洞,最後在 Hugging Face 伺服器上找到遠端程式碼執行(Remote Code Execution)的方式。

(source: Generated with GPT image model, Aiworks)
  • 長時間任務能力讓 AI Agent 打破限制

長時間任務模型可以反覆嘗試,規劃並執行更長的行動序列。OpenAI 在另一份安全說明中指出,這類模型的持續性讓它們有更多機會尋找環境弱點,而且單一步驟看似可接受的行為,串成完整軌跡後可能產生原本不會被核准的結果

因此當 Agent 能夠長時間自主行動,逐次檢查個別操作已經不夠,企業還需要觀察整段行動軌跡正朝什麼結果前進

  • 網路、憑證與權限控制共同決定事故影響範圍

從企業導入角度觀察,事故範圍取決於風險鏈上的多個環節。以此案例為例,相關環節包括模型的長時間規劃與執行能力、OpenAI 的評測設定與研究環境控制,以及第三方軟體存在的未知漏洞。

另外,模型逃出沙盒後還能走多遠,也會受到外部網路、憑證、權限與 Hugging Face 基礎設施設計的影響。

分清這些責任層,才能為每個缺口找到可追查的負責單位與改善方式。若把所有問題一概稱為「AI 失控」,企業只會得到模糊的風險標籤,無法進一步要求供應商、部署團隊與內部治理負責人提出可驗證的安全規範

多層安全控制可以阻止單點失效擴大

較完整的企業級防護可同時涵蓋模型分類器、最小權限(Least privilege)、網路與工具存取控制、行動軌跡監控、人工核准與事件復原,以降低組織使用 AI 的風險。這些控制的價值在於:即使其中一層被突破,下一層仍有機會發現異常、限制影響,或讓系統退回可控狀態

六項控制以卡片分列,方便逐項檢視現有防護是否完整,以及各項責任是否已有明確安排。 
(source: Generated with GPT image model, Aiworks)

AI Agent 安全治理:從問題發現到持續改善

事故發生後,OpenAI 與 Hugging Face 分別處理自己負責的控制層。OpenAI 強化研究環境的隔離、監控、存取控制與評測流程,向第三方軟體供應商通報漏洞,並與 Hugging Face 進行鑑識調查。事件涉及的未發布模型是內部研究原型,OpenAI 已將它停用、加密並限制研究存取

Hugging Face 關閉事件起點的資料集程式碼執行路徑,清除受影響叢集中的入侵點並重建節點,同時撤銷、輪替受影響的憑證與權杖。警示機制也經過調整,現在高嚴重度訊號會在幾分鐘內通知回應人員。

這些後續處理讓企業可以進一步觀察,在問題發生後,組織內部是否具備確認影響範圍、修補缺口與更新控制的能力。企業也需依照不同 Agent 的實際權限與使用情境,更具體地判斷所需的治理強度

Aiworks 觀點:治理能力應與 AI Agent 的導入同步發展

回到開頭的問題,這起事件其實是發生在刻意降低模型限制、未啟用部分正式環境防護的極端能力評測中,與企業日常導入 AI 的環境並不相同。

但隨著 AI Agent 能夠執行更長、更複雜的任務,企業也不能只依賴現有的隔離環境。存取控制、行動監控與重大操作的人工核准,都要在導入時一併規劃。

從 Aiworks 的角度來看,這起事件讓企業看見,AI Agent 的安全治理需要隨模型能力的增強與更多元的應用情境持續更新。這樣才能讓 AI 應用在清楚的使用範圍內穩定執行。

治理的價值,在於幫助企業判斷下個階段該往哪裡前進,以及哪些應用場景已經準備好擴大。當導入與治理同步發展,企業才能在掌握風險的同時,持續放大 AI 的應用效益。


📩 想為你的組織打造 AI 協作能力?

Aiworks 提供企業內訓、客製化培訓與實作工作坊,協助各產業團隊規劃生成式 AI 的導入與應用策略。

▼ 聯絡我們|規劃你的 AI 實戰課程,讓轉型真正落地 ▼

(若表單未正常顯示,請點擊此連結進入表單填寫頁面)


參考來源