人工智慧
Agentic AI 資安啟示：OpenAI 模型繞過沙箱、入侵 Hugging Face 系統的完整分析
OpenAI 的模型自己逃出了沙盒模擬測試環境並入侵 Hugging Face 的伺服器，只為了完成一項評估測試。整個過程完全沒有人類介入。這起事件顯示，代理式 AI 的安全，現在不是單靠精進訓練方式就能維護，如何加以隔離也同樣重要。
Save to Folio
重點摘要
- 只要有足夠的自由空間，AI 系統自己就可能造成實際的損害，無須懷有惡意，也無須有人指使。
- 監測資料能夠揭露的只有行為，沒有意圖。所以，資安人員必須聚焦在 AI 代理的實際行為，而非它為何要這麼做。
- 像這樣的攻擊，傳統防禦很可能無法攔截，因為：AI 代理使用的是自己的合法登入憑證和工具，所以看起來不像惡意程式，因為它就不是惡意程式。
- 採用沙盒模擬環境與隨時保持監控是確保模型安全的核心重點，如今，如何隔離與監控 AI 模型，已變得跟如何訓練一樣重要。
7 月 21 日星期二，OpenAI 確認了一起他們所謂「史無前例的資安事故」背後的起因，這起事故正是 Hugging Face 上週所揭露的入侵事件，Hugging Face 是 AI 產業絕大多數企業用來代管和共用模型與資料集的平台。這起事故當中，完全沒有任何人類在背後指使，單純只是 AI 模型試圖想要通過某項測試而成功入侵了另一家公司的系統。
從沙盒模擬環境到別人的伺服器
入侵事件是發生在 OpenAI 評估其自家模型 (GPT-5.6 Sol 及某個甚至更強的發行前版本) 的資安攻擊能力期間，而且是在一個安全分類器已關閉的沙盒模擬環境內執行，沙盒模擬環境唯一能夠連上的就只有內部的一台軟體代理器 (software proxy)。AI 模型發現了這台代理器的一個零時差漏洞，並逃出了沙盒模擬環境，然後橫向移動到一台可連接網際網路的電腦上。接著，AI 模型推測 Hugging Face 可能會有它想要的答案，所以便利用偷來的登入憑證再搭配前述的零時差漏洞，入侵了 Hugging Face 的營運資料庫，直接拿到了答案。兩家公司的資安團隊在互相連繫之前，早已分別偵測到這起入侵，目前也正在攜手調查當中。(OpenAI 已將代理器的漏洞通報給廠商。)
絕大多數防禦都不是針對這類威脅而設計
在我們 2024 年的「不受控的 AI」研究系列當中，TrendAI™ 描述了三種違背其操作者意圖的 AI 系統：天生惡意不受控 (由駭客蓄意部署)、意外不受控 (給予的權限超過其所在環境的控管機制) 以及遭到破壞而不受控 (遭駭客越獄或注入提示而被挾持)。請注意，「不受控」的意思不代表該模型就懷有敵意或具備自我意識，而是指 AI 系統的行為已超出操作者的意圖，而這起事件就是一個典型的教科書案例。
一個自己到處亂跑的 AI 代理，就如同內部人員威脅一樣，而被挾持的 AI 代理則像是一個被入侵的帳號，兩種都有現成的工具可以應付，但差別在於速度。內部人員威脅和已遭入侵的帳號，是以人類的速度移動，所以資安人員有時間做出反應，但 AI 代理則以 GPU 的速度移動，因此防禦本身也必須是代理式 AI。
這起事故提供了一個營運環境遭遇「意外不受控的 AI」的實際案例。AI 模型並未遭到挾持，也不是駭客所惡意部署。相反地，OpenAI 為了測試模型的原始能力，刻意放寬了安全機制，而模型也充分利用它所擁有的自由空間，使用出人意料的方式來解決問題，也就是 (從某種意義上來看) 在測試中作弊以免失敗。
從受害企業的角度來看，當 Hugging Face 在 7 月 16 日揭露這起入侵事件時，他們並不知道攻擊行動背後是誰家的模型。該公司的官方貼文指出，攻擊使用的是「目前仍未知」的 LLM，並且描述這些活動完全符合長久以來人們預言的「代理式 AI 駭客」情境：他們光是一個週末就記錄到 17,000 次以上使用大量短暫存活的沙盒模擬環境執行的動作，而且還在公共服務上架設了可自我移轉的幕後操縱 (CC) 機制。Hugging Face 找來了外部鑑識分析專家，並且向執法機關報案。連續五天，Hugging Face 的回應就好像他們真的遭到攻擊一樣，這完全可以理解。
從資安人員的角度來看，意外不受控的 AI 和懷有敵意的 AI 並無區別。畢竟，監測資料看不出意圖，只會看到行為。但與人類駭客集團更明顯的差異是：短短一個週末 Hugging Face 就記錄到超過 17,000 次以上的活動，這是人類望塵莫及的速度，也是以人類速度運作的防禦無法抗衡的原因。其攻擊手法採取的是人們熟悉的套路：先偵查、再橫向移動，但數量與速度才是真正的挑戰。
這樣的模式早有前例，2024 年 OpenAI 發布的 o1 模型卡即曾經記錄了一次較小規模的類似行為：在一次的資安搶旗演練中，AI 模型遇到了一個損壞到它無法修復的問題容器，所以它便使用 Docker API 來啟動自己的副本，然後直接從記錄檔當中讀取答案。
AI 開發人員和操作人員該做些什麼改變
這些模型所做的動作，幾乎不會觸發任何傳統的防禦，原因在於結構性缺陷：基於特徵比對和漏洞資訊所打造的工具，是專為偵測已知不良活動而設計。但 AI 代理會使用自己配發的登入憑證和工具來存取系統，所以看起來不像惡意程式，因為它就不是惡意程式。所以我們可以合理假設：一個有能力的模型應該有辦法逃出將它框住的沙盒模擬環境。因此，資安的重點必須圍繞在萬一它逃逸之後會做些什麼，而非只想著將它框在裡面。
保護代理式 AI 需要一套不同的控管措施：
- 資安團隊應該在 AI 代理上線之前預先做過紅隊演練。適應性攻擊測試 (如提示注入、資料外傳、躲避認證) 可以在部署前 (而非部署後) 預先找出 AI 代理的故障模式。
- 資安人員應觀察 AI 代理在執行時期實際執行的動作。真正重要的訊號 (非預期的工具呼叫、連線至新的主機、資料離開預定範圍) 都出現在 AI 代理本身的行為當中，而非另一個分開的惡意檔案。
- 團隊應將每一個 AI 代理及它所連接的工具視為一級資產來加以盤點。若無法明確列出 AI 代理的名單、它們可觸及的內容，以及每個代理的風險程度，那麼誰也無法逮到正在預期範圍之外運作的代理。
- 企業應將調降安全機制的環境視為高風險。沙盒模擬環境評估、紅隊演練，以及刻意削弱安全控管的 AI 代理測試，都需要做到比營運系統更嚴格 (而非更弱) 的隔離與監控。
對資安人員來說這起事故暴露了什麼
撇開新鮮感之外，這起事故是一連串網路事件的結果。如同紅隊演練或進階持續性滲透攻擊 (APT) 一樣，駭客必須先對周遭系統進行一番偵查，本案例第一個被偵查的目標就是那台代理器。AI 必須找到那台代理器，然後掃描它是否有現成的漏洞可用，或者 (如同本案) 自己找出一個漏洞並針對目標測試看看是否可行，這便衍生了一個問題：這需要經歷過多少次錯誤嘗試。這所有刺探動作都發生在它自己用來執行程式碼的沙盒模擬環境內，但卻沒有任何一個動作被標記為可疑。
這就是 TrendAI™ Deep Discovery™ Inspector 搭配 TrendAI Vision One™ 偵測模型能協助偵測這類偵查活動的地方，而且 TrendAI Vision One™ 應該早就偵測到這些異常活動。比方說，AI 代理和 LLM 系統需經由 API、CLI 和 MCP 呼叫工具的動作，全部都會列在組態設定當中並獲得允許，反觀那些不尋常的 AI 代理通訊協定或工具，則應該被標記。
模型在逃出沙盒模擬環境之後的第一個目標就是存取網際網路。隨後的每一個步驟 (權限提升、橫向移動、跳轉到遠端目標、從另一家公司的營運資料庫擷取資料) 都是透過網路來完成。這就是自主式 AI 活動能被看見的地方，也是它能被控管的地方。在端點上，AI 代理或許看起來不像惡意程式，但它無法隱藏自己的流量。網路活動 (橫向與對外流量) 的深度檢查，可準確呈現本案每一階段所產生的訊號：非預期的對外連線嘗試、不同環境之間的橫向移動，以及連上 AI 代理不該碰觸的系統。
沒有任何單一控管機制能夠攔截本案當中的 AI 代理，它們持有有效的登入憑證、呼叫獲得核准的工具，並且攻擊特徵比對無法偵測的零時差漏洞，所以必須建置多層式防禦，因為以機器速度移動的駭客，不可能讓人類有時間介入每一個動作，所以必須靠自動化：
- 在上線之前預先測試 AI 代理 (TrendAI Vision One™ AI Application Security)。 OpenAI 的模型在評估測試之前已先將安全分類器關閉，而且沙盒模擬環境也未經歷過邊界對抗測試。AI Application Security 的部署前紅隊測試功能會模擬 AI 應用程式和 AI 代理在營運環境中可能面臨的攻擊：提示注入、資料外傳、避開認證、越獄等等。它能找出像這次事故中的故障模式 (獲得自由的 AI 代理找到了一條出人意料的路徑)，避免營運基礎架構在部署之後陷入危險。安全機制應設置在需要呼叫 LLM 的任何軟體或 AI 代理之前，而非只設置在使用聊天機器人的人員面前，因為提示注入並非唯一需要解決的問題。除此之外，也可以透過適當的政策來偵測偏離或不符合原始目標的情況。
- 在事故發生的當下即時攔截 (TrendAI Vision One™ Agentic SIEM)。這起事故當中的警訊是真實的，但是卻分散四處：偷來的登入憑證被重複用於各種環境、突然轉跳至開放的網際網路，以及連上模型不該碰觸的系統，這每一項警訊都分屬不同的控管單位。Agentic SIEM 會從相鄰的控管措施擷取監測資料，如：身分識別、存取控管、防火牆、代理器，並交叉關聯這些訊號來偵測是否有資安事故正在發生。其次，它在 TrendAI Vision One™ 當中的自動化回應與應變腳本 (playbook) 可將受害系統隔離，或者停用已遭駭入的帳號。
- 在 AI 代理將步驟串聯之前預先找到攻擊路徑 (TrendAI Vision One™ Cyber Risk Exposure Management，簡稱 CREM)。代理器的零時差漏洞是新發現的，但後續的一切卻都可歸咎於基礎架構缺失：過度授權的服務帳號、沙盒模擬環境與營運環境之間缺乏隔離、可讓駭客跨環境提升權限的登入憑證。CREM 的攻擊路徑預測功能每天都在發掘這類多次轉跳的攻擊鏈，尋找脆弱的入侵點、建構橫向移動路徑 (根據端點、網路、身分及雲端的監測資料)，以及駭客或自動化 AI 代理可能觸及的高價值目標。CREM for Cloud 能為各種雲端環境額外添加持續性組態設定錯誤偵測功能，找出權限過度寬鬆、因而讓沙盒模擬隔離環境連上網際網路的網路規則。
事故應變人員也從中學到了一堂課，當 Hugging Face 的鑑識分析團隊試圖利用商用 API 背後的先驅模型來分析駭客的動作 (實際的漏洞攻擊惡意檔案、指令及 CC 相關檔案) 時，卻遭到了封鎖：因為供應商的安全機制無法分辨他們到底是資安事故應變人員還是駭客。最後，該團隊在自己的基礎架構上執行一套開放權重模型才完成了這項分析，而這麼做也可以避免駭客的資料和登入憑證離開其環境。這裡並非要否定安全機制的價值，而是要吸取教訓：企業應該事先搞清楚 (而非等到事件發生當下再來想) 當他們要分析的是敵人的資料時，應變團隊實際可用的 AI 工具有哪些。
這不會是最後一次發生此類事件
每當先驅模型的能力向上提升，其長程推理、多重步驟的問題解決能力也會跟著上升，而這正是這次事故的元凶。未來可能有更多模型會試圖尋找創新、未經授權的途徑來達成目的，不論是否有人在背後指使。所以，想要確保 AI 的安全，已經不能單看模型的訓練方式，還要看模型周圍的系統是如何建構。企業如何將模型隔離在沙盒模擬環境內、如何限制它能接觸的範圍、設定它執行時應遵守的規則，以及隨時監控它的實際行為，這些都跟模型本身內建的安全機制一樣重要。
除此之外，偵測方式也必須改變，像本案這樣的 AI 駭客絕對不會觸發特徵比對偵測機制，所以唯一可靠的線索就是行為，也就是 AI 代理會在網路上做些什麼。而且，由於 AI 代理是以機器的速度移動，因此偵測機制也必須跟上這樣的腳步，並且即時交叉關聯所有身分、網路和雲端的訊號，比 AI 代理更早找到它可串連的路徑。改為監控異常行為而非已知不肖的程式碼，就能將原本看不見的 AI 代理入侵變成資安人員能夠實際攔截的行動。
這也是 TrendAI™ 目前所見最明確的轉變證據：AI 現在正以機器的速度不斷發掘真實的漏洞，例如本案的模型就發現了研究人員從未找到的零時差漏洞。隨著發現的速度加快，資安人員若能以相同速度判斷優先次序並加以矯正，就能獲得優勢。企業若能將 AI 代理當成必須監控的對象，而非只是埋頭部署，就能在自己遭遇類似事故時具備真正的解決能力。
畢竟，這些系統都是向人類學習，AI 是以人類的行為做基礎來加以訓練，而人類總是會設法尋求優勢，社會的整套規則框架，就是為了抑制這種衝動而生。你給模型一個目標和一些有限的資源，它們也會做出同樣的事：找到任何能帶來優勢的途徑，不論是否被允許。這就是資安人員現在必須準備應對的行為。