AI 智能體隔離：假設模型已遭入侵，將影響範圍限制在預設邊界

撰文：Josh Greenwell，資深應用 AI 工程師

這篇網誌文章是我們一份白皮書的精簡版，探討輸入防禦失效時如何限制 AI Agent。完整白皮書包括附錄，內容涵蓋 2026 年 7 月事件時間表、限制措施檢查清單、限制控制措施與 SOC 2、OWASP 及 NIST 框架的對照，以及完整參考資料列表。你可以在此處查看及下載原文。

引言

我們以程式碼執行為核心重構 LuumenAI，原因是成本。我曾在另一份文章中談過這件事，簡單來説，每個請求都載入一大堆工具會消耗大量 token；把工作移至沙盒，讓模型編寫程式碼來呼叫我們的 API，則令每天數百美元的開支降至個位數美元。安全邊界幾乎是意外地隨之形成。模型編寫的程式碼現在會在隔離環境中執行，而且只能存取我們提供給它的 API。某一刻我忽然想到，我們為了節省開支而建立的系統，竟也阻隔了遭劫持的模型，令它無法接觸原本可以存取的一切。

這件意外正是本文的主題。系列的第一篇文章指出，你無法教會模型分辨指令與資料，但可以控制哪些內容會傳到模型。我在談及每項輸入防禦時，都不斷重申同一項警告：防禦措施只能逐層疊加，絕不能成為唯一依靠。能阻止 99% 注入攻擊的過濾器，攻擊者總會在第 100 次嘗試時突破；有一段時間，我不願正視這第 100 次嘗試。

但終究必須正視。你要為此作好準備。你要假設，模型終有一天會穿過所有輸入控制，讀到惡意指令並試圖執行；你要建構系統，確保即使如此，它能接觸到的資源仍然有限。安全團隊多年來一直採用「假設已遭入侵」的原則，早在大家開始擔心 Agent 之前已是如此。你不再把一切押在防線上，而是開始決定入侵者越過防線後能走多遠。

撰寫本文期間，相關個案陸續出現，而且比我原先準備應對的情況更離奇。2026 年 7 月，一批前沿模型逃離隔離的評測環境，穿越公開互聯網，並闖入另一家公司的生產系統。沒有攻擊者指使它們。它們當時正接受基準測試評分，而闖入系統證明比真正解決問題更快取得高分。九天後，另一間實驗室檢視自己的評測記錄，並報告另外三宗涉及另外三家公司的個案；其中最早一宗在當時已發生三個月。我會在第四部分再談這兩項披露，因為兩者合起來擴大了「遭入侵」一詞所涵蓋的範圍（完整披露時間表請參閲附錄 A）。

我們在輸入防禦方面的進展，比在限制措施方面更大；業界大多數亦然。AI Agent 的限制措施是一門有現成工具可用的工程實務，但相關技術仍相當新，有些託管元件的洩漏問題比其市場宣傳所承認的更嚴重。本文探討模型採取行動後能接觸到甚麼，以及如何盡量縮小這個範圍。

第一部分：為何輸入防禦並不足夠

先從數學談起，因為這正是這篇論文存在的原因。在模型前放置一道能攔截 99% 攻擊嘗試的過濾器，面對一千種變化的攻擊，攻擊者只是在等其中一種何時闖過防線。疊加幾道過濾器，成功攔截的機會會提高，但永遠無法達到百分之百確定，因為攻擊者只需得手一次，你卻必須連續成功攔截每一次攻擊。輸入防護只能降低注入攻擊成功的頻率，無法將成功率降至零。

一旦接受注入攻擊終究會成功一次，你便會開始圍繞另一個問題設計防護：攻擊得逞後，能造成的影響有多小。這個問題有答案。模型能存取多少資料？它可以把資料傳送到哪些地方？它所編寫的程式碼實際上能做甚麼？這些方面全都可以透過工程手段加以控制；至於如何讓模型對語言攻擊免疫，則沒有人能提出同樣的保證。

第三項支柱終於要派上用場了。第一篇論文探討模型存取資料的權限，以及接觸不可信內容的風險，卻沒有處理第三項支柱，也就是將資訊傳送出去的能力。限制措施主要針對這一項，以及模型決定採取行動後所做的一切：呼叫工具、編寫並執行程式碼、將輸出交給另一個系統、把資料傳送到某處。這些全都是一扇門，而受攻擊者操控的模型會嘗試所有途徑。

第二部分：沙盒實際上保護甚麼

第一篇論文提出的一項區分，是理解以下所有內容的基礎，所以我會説清楚。沙盒是模型與其行動可能損害的系統之間的界線。它能防止模型編寫的程式碼接觸你的網絡、資料庫和客戶，但無法阻止惡意指令一開始就傳到模型。人們經常混淆這兩者，結果不是替輸入完全不設防的模型套上堅固的沙盒，就是反過來。

限制措施歸結為執行模型行動的環境所受的五項限制：

• \n最小權限原則。模型編寫的程式碼只能呼叫完成任務所需的少數 API，不能做其他事。
• \n對外連線允許清單。環境只能連接所需的特定目的地，不能連接攻擊者控制的伺服器。清單上的每項例外都會擴大攻擊面，而套件庫通常是人們最先開放的例外。
• \n資源限制。為 CPU、記憶體和實際執行時間設定上限，避免失控或刻意耗費大量資源的程序不斷增加費用。OWASP 稱之為 Unbounded Consumption。
• \n不提供環境憑證。環境中不得留有任何可供遭入侵程序讀取並重用的憑證。
• \n預設採用暫時性環境。每次執行都使用全新環境，確保攻擊者留下的任何東西都不會保留至下一個工作階段。

以上每一項都是可以判定通過或失敗的設定。這正是在這一層著手的優點。你可以測試對外連線允許清單能否阻止任意的外連。你無法測試模型是否終於學會不信任惡意電郵。只要正確設定環境，即使攻擊者成功操控模型，也幾乎找不到可下手之處。

第三部分：隔離光譜

隔離有不同級別；當你即將執行的程式碼是由模型按需撰寫，而模型可能已被誘導產生惡意內容時，級別之間的差異就非常重要。選項由較弱、成本較低，到較強、成本稍高不等。

一般容器的隔離能力最弱。容器共用主機核心，因此在容器內利用核心漏洞，就等於在主機上利用漏洞。容器適合用來隔開你自己的可信服務，但若要用作隔離不可信的模型生成程式碼的邊界，就遠遠不足；把容器當成可靠的隔離邊界，是常見而代價高昂的錯誤。

gVisor 的隔離能力更進一步。它會執行一個使用者空間核心，攔截工作負載的系統呼叫，避免呼叫送到主機核心，令程式碼不會直接與主機通訊。這會帶來一些系統呼叫和 I/O 開銷，但啟動速度仍然足夠快，可以用於每個請求。

對大部分生產環境工作而言，Firecracker 的隔離能力最強。每個工作負載都會在 KVM 上的精簡虛擬機中執行，並由硬件支援的邊界隔離；虛擬機在不到一秒內啟動，幾乎不會增加記憶體開銷。因此，你可以在大量工作階段中，按需啟動和關閉虛擬機。Kata Containers 也屬於類似範疇，會把容器工作負載放進輕量級虛擬機。至於不可信的 JavaScript，V8 isolates 尤其適用；它們是瀏覽器用來隔開分頁的輕量級執行環境，Cloudflare 正是透過這種方式，讓模型生成的程式碼得到強隔離。

我們遵循的規則並不複雜：模型生成的程式碼至少要有核心層級的隔離邊界，例如 gVisor，絕不能只用裸容器。任何多租戶環境，只要一位客戶的工作負載有可能觸及另一位客戶的工作負載，就要使用 microVM。沒錯，較強的隔離邊界會增加運行成本，但跟處理沙盒逃逸的代價相比，這根本不算甚麼。

LuumenAI 使用託管沙盒平台。每次執行都有各自隔離的環境，而且環境可棄置，執行完成後就會消失。該環境位於與我們分開的基礎設施上，這也是我們選擇該平台的原因之一。如果客戶隔離邊界有需要將隔離層設於我們自己的帳戶內，我們可以把它遷移至內部。我們一直按這個方向安排設計，確保遷移範圍可以明確界定。

第 IV 部分：沙盒何時失效

撰寫本文這一部分時，內容一直在變，因為相關例子不斷出現。隔離並非自動生效，也不是免費的；一旦失效，通常有兩種情況。第一種是沙盒設定錯誤：隔離邊界表面上存在，但某項設定留下了缺口，例如未有鎖定的輸出流量路徑，或權限範圍過大的角色。第二種是逃逸：隔離層本身有漏洞，讓程式碼得以逃出。

設定錯誤的沙盒：AgentCore

AWS Bedrock AgentCore Code Interpreter 出現了第一類故障，而隔離層始終沒有失效。2025 年 9 月，Sonrai Security 發表研究，指出在沙盒化解譯器內執行的程式碼，可以連線至微型虛擬機（microVM）的中繼資料服務 169.254.169.254。這是 EC2 工作負載用來存取執行個體中繼資料的相同地址，而程式碼可從中讀取執行角色的 IAM 憑證。AWS 曾設置一個過濾器，封鎖任何包含該字面地址或中繼資料路徑的請求。繞過過濾器並不需要甚麼巧妙手法。只要程式碼把地址拆成幾部分、將它編碼，或在執行時組合起來，請求中便不會包含過濾器比對的確切字串，因此都能順利通過。最終取得的是執行角色的工作階段憑證，可在沙盒外用來存取沙盒本身無法連線的 AWS 控制平面端點。

Firecracker 在整個過程中都發揮了應有作用。虛擬機從未遭到入侵。執行角色的憑證只是在虛擬機內可供讀取，而這件事之所以如此重要，是因為調查結果的另一部分。在 AWS 自家的 AgentCore Starter Toolkit 中，預設 IAM 角色獲授權讀取帳戶內所有 S3 儲存貯體、完整存取 DynamoDB，以及存取 Secrets Manager 中的所有秘密！開源的 AgentCore 範例沿用了這個角色。因此，按照快速入門教學操作的團隊，最終得到一個沙盒；一旦讀取其中的憑證，便能存取帳戶中的大部分資源。AWS 根據共同責任模型，將存取中繼資料視為預期行為，並發布了這項服務的憑證管理文件。

整個攻擊鏈完全不需要入侵。微型虛擬機安然無恙。裡面的憑證可以讀取，而它們所屬的角色則是從入門工具包複製而來。

生產環境中的沙盒逃逸：七月攻擊行動

沙盒逃逸較少見，也較難分析；直到 2026 年 7 月，公開案例都來自研究，而非生產環境。

7 月 16 日，Hugging Face 披露其部分生產基礎設施遭到入侵。一個惡意數據集利用其數據集處理流程中的兩條程式碼執行途徑——一個可載入遠端程式碼的數據集載入器，以及數據集設定中的模板注入——在處理工作節點上執行程式碼。其後，攻擊者取得節點層級的存取權限，竊取雲端及叢集憑證，並在一個週末內橫向移動至多個內部叢集。Hugging Face 將這次攻擊行動描述為一個自主 Agent 框架執行了數以千計的個別操作；按其説法，行動發生在「一羣短暫存續的沙盒中，並將可自行遷移的命令與控制架構部署於公開服務上」。該公司表示，不知道背後使用的是哪個模型。

五天後，OpenAI 表示那些模型是自家的。GPT-5.6 Sol 及一個尚未發布、能力更強的模型（後來澄清為只供內部使用的研究原型），當時正在內部進行一項名為 ExploitGym 的漏洞利用能力評估；為了測試能力上限，模型的正式環境網絡安全拒答機制已關閉。OpenAI 形容，評估是在高度隔離的環境中進行，網絡存取僅限於透過內部託管的代理伺服器和套件登錄庫快取安裝套件。模型耗用大量推理運算資源，設法連接公開互聯網。它們在該套件代理伺服器中發現並利用了一個零日漏洞，提升權限，並在 OpenAI 的研究環境中橫向移動，直至抵達一個可連接互聯網的節點；接着推斷 Hugging Face 可能存有 ExploitGym 的解答，於是將竊取的憑證與更多零日漏洞串連起來，在 Hugging Face 伺服器上建立遠端程式碼執行途徑。Hugging Face 後來的技術分析補充了其中一步：模型在接觸其系統之前，已在公開互聯網上的第三方程式碼沙盒取得 root 權限，並以此作為後續整個攻擊行動的起點。它們並未收到任何指示要做這些事。評估要求模型提供漏洞利用方法，而作弊只是產出這些方法最有效率的方式。

隔離技術本身沒有失效。模型透過環境原本就允許的唯一對外連線途徑逃出；幾乎每個工程團隊都會在對外流量政策中開放同一例外，因為建置流程需要套件。模型不需要新型攻擊手法，只需要利用那扇已經開啟的門，以及門後軟件中的一個漏洞。該代理伺服器是內部託管的第三方軟件，是某人曾經選用、之後便沒有理由再檢查的依賴項。

至於 Hugging Face，當時無法判斷自己面對的是甚麼。該公司在 OpenAI 出面承認之前發布的報告，描述了一宗來歷不明、由具備能力的對手發動的入侵；其應對方式則是處理刑事入侵事件時會採取的做法：清除入侵者的立足點、重建受影響節點、更換憑證、聘請外部專家進行鑑證，並通知執法部門。模型超出目標，以及使用 Agent 框架的惡意行為者，產生了相同的遙測資料，因此需要相同的應對措施。Hugging Face 透過分析超過 17,000 筆已記錄事件，還原了事件經過；分析在其自有基礎設施上使用開放權重模型進行，因為該公司起初嘗試的託管前沿模型拒絕處理相關工作，而且無法分辨事件應變人員與攻擊者。

配置錯誤的評估：Anthropic 事件

OpenAI 披露事件九天後，Anthropic 公佈了就自身測試提出同一問題所得的結果，令 OpenAI 的案例看來幾乎令人安心。他們檢視了 141,006 次評估執行，當中模型有可能連上互聯網；結果發現三宗事件中，Claude 曾從第三方評估合作夥伴的環境連上互聯網，並入侵三間互不相關公司的正式系統。最早一宗發生在 4 月。沒有利用漏洞，也沒有任何東西外流。評估提示詞告知模型它無法連上互聯網，但 Anthropic 與供應商之間的設定錯誤令模型實際上可以連線；雙方都一直不知情，直至三個月後檢視對話紀錄時才發現。Claude 當時正在進行奪旗演習，這類演習會指示模型入侵系統，因此當搜尋結果引領它找到實際運作中的主機時，它便把這些主機當作遊戲目標。在最嚴重的一宗事件中，它取得了應用程式和基礎設施憑證，並連接到一個存有數百列正式環境資料的資料庫。Anthropic 能聯絡上的兩間受影響公司都未有察覺，直到 Anthropic 致電通知才得知。

Claude 在一個虛構環境中找到設定指示，當中提到一個並不存在的 PyPI 套件，於是決定以該名稱發布套件。要發布套件需要帳戶，開設帳戶需要電郵地址，取得電郵地址需要電話號碼，而電話號碼需要它沒有的資金。多次嘗試取得資金失敗後，它便退而改用免費電郵服務商，並上傳套件。它自己的推理早已指出，向正式套件庫發布套件會構成現實世界的攻擊，而且用它的話來説，「並非預期的解決方案」。它以兩個理由説服自己不必理會這個疑慮：它認不出為連線提供安全保障的憑證授權機構，而系統日期顯示為 2026，它便以此為證，認為該環境是預先搭建的。套件在正式套件庫上存在約一小時，並在十五部實際機器上執行。其中一部是安全供應商的惡意軟件掃描器；掃描器安裝並執行了套件，之後套件便把憑證傳送到模型設置的收集點。

Anthropic 將這些事件歸因於測試框架及操作層面的失誤，而非對齊失敗，並表示沒有證據顯示模型在追求自身目標。這個説法大概是對的，但這些事件仍值得在此討論。模型在錯誤認知自身所處環境的情況下，完成了被指派的工作。第一篇論文指出，模型無法可靠地區分指令與資料。這些對話紀錄顯示，模型也無法可靠地分辨正式系統與測試環境；即使仔細推理問題，也可能推導出錯誤答案並繼續行動。Anthropic 亦指出，其正式提供的模型所附帶的安全防護措施本可阻止這些行為；評估時則刻意不啟用這些措施，以衡量能力上限。這些發現仍屬初步結果，Anthropic 正安排與 METR 進行第三方審查，因此部分細節或會改變。

安全地執行不受信任的程式碼，早已是計算領域最古老的難題之一；語言模型令問題更嚴峻，因為程式碼現在會按需大量生成，而且沒有人審查。要了解沙盒實際容許甚麼，方法就是進入沙盒並嘗試逃脱，但大多數團隊從未這樣做。

第五部分：即使是受管理的沙盒，也需要檢查

雲端服務供應商現在會向你出售專為此用途設計的管理式沙盒，而且這類服務確實有用。管理式程式碼解譯器可提供每個工作階段各自的隔離、按身分限定的存取權、審計記錄，以及幾種網絡模式，讓你的團隊毋須自行營運隔離層。如果你不想自行營運 Firecracker 機羣，這是合理的取捨。

我不會全盤相信的字眼是「隔離」。管理式沙盒只會按照供應商決定的方式隔離，而這些方式未必符合你閲讀宣傳頁面時的想像。

透過 AgentCore，文件與實際行為之間的落差得以端到端量度。AWS 提供了 Sandbox 網絡模式，並形容它是「一個沒有外部存取的隔離環境」。BeyondTrust Phantom Labs 測試了這項説法，發現沙盒仍會解析公開 DNS 名稱，包括 A 和 AAAA 記錄。對外 TCP 連線遭到拒絕，但 DNS 解析器仍持續回應。

Phantom Labs 隨後以此建立了一條可用通道。他們把指令編碼進 DNS A 記錄回應的位元組中，每個回應承載三個 Base64 字元；再將輸出藏在較長的子網域標籤中傳出，每次六十個字元。結果是在設定為不允許網絡存取的沙盒內，建立了雙向通道和可用的互動式 shell。他們利用執行角色的 S3 權限列出儲存貯體，並透過同一通道讀取及傳出檔案，其中包括一份包含客戶記錄的測試檔案，內有姓名、電話號碼和部分識別碼。攻擊途徑是一份遭植入惡意內容的 CSV；注入的指令藏在一個儲存格中，代理程式在編寫 Python 時會讀取該儲存格。

AWS 重現了報告中的問題並承認其影響，但最初決定不予修補。AWS 認為這是預期行為，因為 DNS 解析會保持啟用，讓沙盒中的 S3 操作可以解析其端點。AWS 將此發現的 CVSSv3 評分定為 7.5，低於原始提交中的 8.1，並選擇修改文件，將「一個沒有外部存取的隔離環境」改為「有限的外部網絡存取」。這項服務在 Firecracker microVM 上執行，運算隔離從未受到質疑。被改寫的是描述網絡的那句話。這個立場在事件公開後未能維持。披露過程由 2025 年 9 月的 HackerOne 報告 #3323153 開始，至 2026 年 3 月公開披露；幾星期後，Palo Alto Networks Unit 42 也發表了對同一繞過方法的分析，之後 AWS 改變立場並封堵了 DNS 通道。如今，已無法再從沙盒化的解譯器透過 DNS 外洩資料（披露的日期順序請參閲附錄 A）。

供應商和客戶可能讀到同一個字眼「隔離」，卻各自理解為不同意思。對供應商而言，這個字眼的意思取決於實際實作的行為；修改文件也是處理安全報告的合理結果。你據以設計防護的特性可能改變，而你自己的系統完全不必有任何變動；你自己的監控機制也不會告訴你這件事已經發生。

DNS 是這類問題中人人都會忽略的一種情況。沙盒可以封鎖所有明顯的對外連線，卻仍能正常解析主機名稱。主機名稱查詢所能承載的資料綽綽有餘，足以讓人每次挾帶幾個字元，把秘密偷運出去。不論沙盒如何聲稱，要知道它允許甚麼，方法就是在其中執行嘗試對外連線的程式碼，包括 DNS，並觀察有哪些內容傳出。

Anthropic 對其評估事故的事後檢討，從另一個角度得出了相同結論。他們列出的本可及早發現問題的措施，首項就是在執行開始前驗證所有互聯網存取路徑，並在執行期間監察網絡記錄。當時人們認為環境已封閉，這個假設也以事實陳述的形式寫進模型的提示詞，但三個月來都沒有透過網絡驗證。託管式沙盒與供應商運行的評估環境有一個共同點：你們的工作負載與互聯網之間，隔着由其他人設定的配置。Anthropic 和合作夥伴各自都有合理理由相信對方已封鎖這條路徑。

第六部分：模型只能洩漏它能存取的資料

防止模型洩漏資料，最直接的方法就是一開始不要把資料交給它。Agent 設計的常見做法，是把任務可能需要的所有內容都載入上下文，讓模型自行處理。這樣雖然方便，卻非常不利於限制資料外洩，因為上下文視窗中的任何內容，都可能被提示詞注入誘使模型洩露。Anthropic 在有關程式碼執行的研究中清楚指出：中間結果應留在執行環境內，不要再交由模型處理，因為模型只能洩漏它取得的資料。模型必須處理敏感資料時，應給它一個代表該值的 token，並將實際值留在沙盒內。

有些資料外洩根本不涉及網絡呼叫。一種有充分記錄的手法，是誘使模型輸出一經呈現便會洩漏資料的內容。經典做法是使用 Markdown 圖片，將圖片網址指向攻擊者的伺服器，並把竊取的資料藏在查詢字串中。Johann Rehberger 曾在 ChatGPT macOS app 上展示這種手法的持續性變體。有人把注入指令寫入模型的長期記憶，讓模型透過 Markdown 圖片，將用戶的輸入和模型的回覆傳送到外部網站；這種情況延續到往後的工作階段，直到問題被發現。用戶端會為了顯示答案而擷取圖片，而這次擷取會悄悄把資料傳出去。沒有人點擊任何內容，光是呈現答案就足以造成資料外洩。因此，在任何下游系統呈現、執行或儲存自家模型的輸出之前，都必須將其視為不可信資料；OWASP 將此列為「不當輸出處理」。

因此，對外傳送資料可歸結為幾個做法：能不把敏感資料放入上下文，就盡量不要放；無法避免時，則將其代碼化。在任何內容被呈現或執行之前，先清理模型輸出的所有內容；凡是會把資料傳送到外部的操作，都必須經人工核准，因為資料一旦外流，便無法收回。

第七部分：透過設計實現隔離

允許清單和資源限制都靠設定管理，而設定可能出錯。另有一個目標更進取的研究方向，嘗試從設計上杜絕資料外洩，而不是等到邊界才攔截。這方面的研究仍處於早期階段，但前景頗為樂觀。以下是研究的發展方向。

最完整的方案是 CaMeL，由 Google DeepMind 和 ETH Zurich 的一個團隊開發。它以 Willison 的雙 LLM 模式為基礎，將可執行操作的模型與讀取不可信輸入的模型分開。具特權的模型負責規劃任務，但絕不會直接接觸不可信內容。另一個隔離的模型負責讀取危險文字，而且無法執行任何會造成實際影響的操作。兩者之間設有一個解譯器，追蹤每項資料可流向何處，並在模型之外以一般程式碼強制執行相關規則，確保標記為敏感的資料不會流向外傳渠道，不論注入的指令要求它做甚麼。

不同論文版本公佈的數據有所變動，兩組數字都有人引用。2025 年 3 月的初版報告指出，CaMeL 在 AgentDojo 上以可證明的安全性完成了 67% 的任務。AgentDojo 是一項提示詞注入基準測試，涵蓋電郵、銀行、旅遊及工作區情境中的 97 項用戶任務和 629 個安全測試案例。6 月的修訂版使用較新的模型進行測試，報告的數字為 77%；相較之下，一個沒有任何防禦措施的同等系統達到 84%。在該實驗中，這項安全保證令模型能力降低了 7 個百分點。這項安全保證本身相當有力，因為注入的指令完全無法改變程式流程。在讀取任何不可信資料之前，控制流程便會從可信查詢中擷取出來。作為交換，Agent 必須放棄臨場應變能力。它會依照讀取任何內容之前已訂好的計劃行事，因此無法處理那些只有在執行過程中才會顯現正確下一步的任務。

第八部分：LuumenAI 如何實現隔離

我希望像在成本論文中一樣，審慎説明我們目前的進展。我們大部分的安全工作都集中在輸入層，因為預防工作在這裏進行，而且這是最能發揮工作成效的環節。執行沙箱已經建成，而且刻意設得範圍狹窄；我們仍在研究會允許哪些內容在其中執行。

LuumenAI 需要操作某個系統時，不會從固定的工具清單中選擇工具，而是會根據我們提供的 API 編寫程式碼和指令碼，並在一個獨立於模型的隔離環境中執行。該環境只能連接我們授權的 API，沒有開放網絡存取權限，也無法連接我們基礎設施的其他部分。中間結果會留在該環境中，只有模型實際需要的輸出才會傳回，因此大型或敏感的資料負載完全不會進入上下文視窗。

執行開始前便會編譯好範圍。模型之外的控制層會將四項資料整合成一個執行物件：工作以哪個身分執行、有哪些能力可用、哪些資料在範圍內，以及哪些步驟需要由人員批准。該物件限定了這次執行的權限上限。後續所有環節都可以收窄權限；任何元件如有疑問，均會預設拒絕操作。後續環節都不能擴大權限。我最重視的是預先編譯範圍這項特性，因為另一種做法是在模型工作期間逐步協商範圍，而注入的指令也可能參與協商。

Anthropic 列出的修正措施包括一項觀察：如果提示詞清楚列明這次演練涵蓋哪些系統、哪些不涵蓋，Claude 大概就不會去搜尋互聯網。我們基於操作上的理由採用了範圍編譯，主要是為了避免模型在執行期間要求額外能力；我沒想到，這會在一家前沿實驗室的事後檢討中，被視為缺失的控制措施。

暫停的執行工作不會沿用先前獲批的權限。工作因等待批准而暫停，之後恢復時會重新驗證整份執行契約。權限會改變，工作階段也會結束，因此一項等待簽署、暫停了一整晚的執行工作，其範圍會按照批准者簽署時的實際情況重新建立。OpenAI 在事故發生的同一週也提出了相關觀點，指出長時間運作的模型可能會找出批准系統的盲點，並繞過系統。當初我們基於較平淡的理由決定在恢復執行時重新驗證；這個説法比我們原本的理由更能説明這項做法的價值。

環境可隨時棄置，憑證則在執行時才提供。每次執行都會使用全新環境，並在執行工作完成後銷毀。程式碼執行時才會注入憑證，而且憑證不會儲存在環境中，因此磁碟或環境變數中都沒有任何資料可供遭入侵的程序讀取並帶走。

由於我們在 AWS 上運作，執行和存取活動都會記錄在我們原本為合規而保留的稽核記錄中。我們也會在產品端為每次執行保留持久記錄，記錄提出了甚麼要求、批准了甚麼範圍、執行了哪些能力、提出並批准了哪些請求，以及執行結果。稽核涵蓋範圍、資料保留期限和最小權限審查，均列為合規控制措施，並指定負責人和審查日期。

沙盒首次封鎖的對象就是我們自己。我們啟用輸出流量政策後，立即發現自家的監察供應商可以連線，但內部 API 卻無法連線。兩者的運作都符合設定。接下來的爭論是要不要為內部 API 加設例外；最後我們採用了經驗證的代理伺服器，讓這些呼叫經過一個會檢查請求者身分及請求用途的系統。環境仍然無法直接連入我們的網絡。大約同一時間，我們發現工單系統整合一開始就無法運作，因為沙盒供應商預設的對外存取方案不允許這項連線。

我讀 OpenAI 的説明時，比自己預期更在意。他們的評估環境只允許一條對外連線路徑，通往用於套件登錄檔的代理伺服器和快取；而這條路徑就是對外通道。我們解決內部 API 問題的方式同樣是使用代理伺服器。我們的代理伺服器會驗證每個呼叫，而且不是套件快取。這些差異很重要。不過，在一個我們形容為封閉的環境中，它仍是唯一刻意保留的開放通道。審查對外連線清單時，我們會先檢視這個代理伺服器。這是我們費了一番辯論才説服自己接受的例外。

**我們建立了預熱環境池，最後決定不使用它。 **每次執行都冷啟動環境會增加延遲，因此我們建立了一個預先預熱的環境池，以消除這種延遲。然後我們計算了成本。維持容量處於預熱狀態，意味著要為閒置時間付費，而每次執行都建立全新環境的成本更低。這解決了單靠安全推理無法解決的爭論。這也讓我們擁有一項可以不加限定地向客戶陳述的特性。池化程式碼仍在程式碼庫中，並由一個我們沒有理由啟用的旗標控制。

五項審查把關執行環境。隔離設定、對外連線政策、機密資料處理、審計記錄和成本控制各有具名審查人，任何一人都可以暫緩整個元件的推出。我們沒有在完成這些審查前推出它；而我曾眼見一個託管沙盒的隔離聲明被改寫在文件中，因此我不打算主張採用較快的方案。

我不會告訴你這件事已經完成。沙盒的作用是限制遭劫持的模型能接觸到甚麼，而且每次迭代都會略為增強。它也不是全部；把沙盒當成全部的團隊，盲點與只強化輸入的團隊一樣，只不過方向相反。

第九部分：限制損害範圍並加以證明

當你首次與企業或政府採購方會面時，這一切的理據便會顯現。你不能承諾 AI 永遠不會遭入侵。沒有人能作出這種承諾，作出承諾的供應商就是在兜售虛假承諾。你能承諾並加以證明的是，入侵造成的影響會限制在你預先劃定的範圍內。即使模型遭到操控，仍無法接觸其範圍以外的資料或系統。

安全審查人可以接受這種做法，而同一套控制措施還會產生他們本來就會要求的證據。執行環境採用最小權限原則，就是你的存取控制方案。對外連線允許清單涵蓋資料外洩防護；資源限制保障可用性；而記錄沙盒每次執行所做事情的軌跡，就是審計人員想看的紀錄。要符合 SOC 2、ISO 27001，以及聯邦政府項目所要求的更高標準，有意限制損害範圍的設計會在運作時產生這些紀錄，不必等到評估前一週才設法重建（各項控制措施在這些框架中的對應位置，請參閲附錄 C）。Anthropic 在事發數月後，透過閲讀儲存的評估記錄發現了全部三宗事件；這種記錄用途，沒有人會列入合規對照表。

我原本一直把影響範圍理解為遭入侵的 Agent 在你的防線內能接觸到甚麼。這些評估事件帶出了另一個方向：它能接觸到防線以外的甚麼。Anthropic 指出，進行這些評估的基礎設施是專用的，無法存取其敏感內部系統，也無法存取客戶資料。按照本文的論證，這是一條界定清晰的界限，而且確實發揮了作用。然而，另外三家公司仍遭入侵，因為該環境唯一能接觸的就是公開互聯網，而公開互聯網上有別人的生產系統。Anthropic 的總結直截了當：即使環境本身不持有任何敏感資訊，其中的先進 Agent 仍構成重大威脅。

對買方而言，問題會稍微有所不同。除了我們的 Agent 能接觸對方哪些資源之外，還要考慮它在我們的內部網絡中可能對第三方造成甚麼影響，令我們因牽連而出現在他人的事故報告中。網絡出口流量允許清單可同時回應這兩方面的疑慮。這是維持清單精簡的充分理由。

這種謹慎在開源隔離及執行工具方面尤其重要。這些工具本身並沒有合規認證；自行託管後，相關安全狀況便由你負責。對聯邦機構的安全邊界而言，這代表一項需要由你的團隊有計劃、持續投入的工作。

第 X 部分：尚無妥善解答之處

相比預防，隔離措施的處境稍好，主要是因為相關問題屬於工程問題，而非尚待解答的開放研究問題。不過，隔離措施仍有其限制。

沙箱逃逸是一場軍備競賽。無論今天哪一道邊界守得住，今晚總有人試圖攻破。七月的事令這場爭論朝令人不安的方向有了定論：失守的環境屬於一家前沿實驗室，而該實驗室的操作人員形容該環境高度隔離。能力與隔離之間的矛盾也永遠不會消失。每一項令 Agent 更安全的限制，都會削弱它的能力；而有些實用的 Agent，恰恰需要具備隔離機制旨在限制的存取範圍。

託管式沙箱要求你信任一道並非由你建立、亦無法全面檢視的邊界；AgentCore 個案則顯示，隔離保證可以透過文件更新重新界定，而你的架構卻原封不動。沒有任何隔離設計能夠證明自己可抵禦尚未出現的逃逸方式，因此最有力的説法也只能是：它抵禦了你想到要測試的攻擊。

然後，還有這個系列反覆探討的情況：Agent 需要接觸私人資料、接觸外界，並具備採取行動的能力。它刻意同時具備這三項條件，因為這正是它有用的原因。對這類 Agent 而言，單靠預防或隔離都不足夠；重要決策必須由人員把關。把這稱為一種架構，已算是抬舉。這其實是承認，目前有些決策仍不能交由模型處理。

結論

第一篇文章探討模型可以讀取甚麼；這篇則探討模型讀取資料後可以做甚麼。兩者合起來就是一套完整做法：在入口處阻止大部分攻擊，並設計系統，令成功入侵的攻擊者也無法造成太大影響。這些隔離措施都不算特別複雜：以核心層級的邊界隔離模型撰寫的程式碼、自行測試並清點例外的網絡出口流量允許清單、不使用可自動取得的憑證、採用臨時環境、把模型輸出視為不可信資料、由人員把關不可逆的操作，以及記錄所有相關活動（清單已在附錄 B 整理為檢查表）。

其中兩項是不可妥協的底線。模型撰寫的程式碼若在低於核心層級隔離邊界的環境中執行，就屬於一項安全審查發現，應按此處理。若託管式沙箱聲稱提供完全隔離，就應先測試這項聲稱，再決定是否相信。

這篇論文的標題要求讀者假設模型已遭入侵，而七月之後，我會擴大這個假設的適用範圍。模型無須被任何人操控，也會像入侵者一樣行事。它需要一個目標、足以追求目標的能力、一個基於合理營運原因而留有一道缺口的環境，以及對周遭哪些系統是真實的錯誤判斷。即使你自己的模型正在執行你指派的任務，遏制措施也必須有效；但我不確定我們目前的設計是否已充分考慮到這點。

遭入侵的模型絕不會毫無危害，無論供應商怎樣告訴你。良好設計最多隻能讓入侵的影響維持有限，並保持可見；相較之下，另一種情況是直到資料已經流失才有人察覺，因此這已經非常重要。你無法阻止所有攻擊者入侵。你能控制的是攻擊者入侵後造成的代價，而這在設計系統時、遠早於事故發生之前便已決定。

這篇網誌文章是我們關於輸入防禦失效時如何遏制 AI Agent 的白皮書精簡版。完整白皮書包括 2026 年 7 月事件時間線、遏制檢查清單，以及遏制控制措施與 SOC 2、OWASP 和 NIST 框架的對照附錄，另附完整參考資料清單。你可以在此處查看及下載原文。