Anthropic 説明如何在 claude.ai、Claude Code 與 Claude Cowork 中限制 Claude 的影響範圍

12 個月前，如果有人提議讓 Claude 獲得足以令 Anthropic 一項內部服務停止運作的存取權限，我們一定會斷然拒絕。如今，這種程度的存取權限已是常態，Anthropic 的開發人員也因此更有效率。這些部署的風險由兩部分組成：失敗發生的可能性，以及一旦失敗可能造成多大損害。防護措施和模型訓練方面的進展，已持續降低前者；後者——理論上的影響範圍——則只會隨着能力和存取權限擴大而增加。然而，隨着代理程式逐漸能夠完成以往需要一個人甚至一個團隊才能完成的工作，不部署的代價也會變得高得多，令風險與回報的權衡大幅傾向採用，前提是產品能夠做到安全。工程上的問題便變成如何限制影響範圍。

大致有兩種方法。

第一種方法是由人類介入監督代理程式的行為。Claude Code 過去會在每一輪都詢問用戶是否授權，以防代理程式採取非預期行動。理論上這種做法可行，但我們發現它並非萬無一失。我們的遙測數據顯示，用戶核准了約 93% 的權限提示。用戶看到的核準要求愈多，對每一項要求便愈不留神，久而久之，在監督時也會疏忽得多。我們最近開發了 Claude Code auto mode，透過自動處理較安全的核準來減輕這種核准疲勞。不過，漏洞仍然存在——任何機率式防禦都有非零的漏判率。¹

限制影響範圍的第二種方法，也是本文大部分內容的焦點，是隔離。與其監督代理程式做甚麼，我們會透過沙盒、虛擬機器及對外連線控制等方式，強制設定存取界限，監督它能夠做甚麼。Anthropic 的工程團隊在這方面投入最多心力，而許多最令人意外的安全失效事件也發生在這方面。

過去兩年，我們推出了三款主要的代理式產品：claude.ai、Claude Code 和 Claude Cowork。每款產品服務的用戶羣各有不同，因此需要不同的隔離架構。本文分享我們一路走來哪些做法奏效、哪些出了問題，以及我們對代理程式安全的認識。

三類風險，三個防禦要素

代理程式面臨的安全風險大致分為三類：

用戶誤用： 用戶可能出於惡意或疏忽，指示代理程式做出有害行為。情況包括要求代理程式略過自己覺得煩人的檢查、執行自己不明白的破壞性命令，甚至明確指示代理程式造成傷害。

模型不當行為： Agent 採取了無人要求的有害行動。隨着模型能力提升，它們在大多數行為評估中的對齊表現都有所提升，但這不代表風險必然降低。能力較弱的模型較容易誤解情況，並犯下明顯錯誤。能力較強的模型犯錯較少，但也更擅長找出意想不到的方法達成目標，往往會避開那些沒有人想到要明文訂立的限制。

在 Anthropic，我們曾看到 Claude 模型為完成任務而「好心地」逃出沙盒、查看 git 歷史以找出編程測試的答案，以及自行辨認正在評測它的基準測試，以便解密答案鍵。每個模型都帶來一套新能力，這些能力有時會以意想不到的方式發揮作用。

外部攻擊者： 攻擊者透過工具、檔案或網絡存取等外部途徑攻擊 Agent。此類別包括提示注入，以及針對 Agent 執行環境、編排層或代理伺服器的傳統攻擊。

建立遏制及防禦系統時，我們會針對三個主要組成部分部署防禦措施：

Agent 執行的環境。 我們透過程序沙盒、虛擬機、檔案系統邊界及輸出流量管制，限制 Agent 可在哪裏及如何行動。目標是為 Agent 可接觸的範圍設下硬性界線。例如，如果憑證從未進入沙盒，就不可能被竊取外洩，不論原因是用戶、模型找到「有創意」的途徑，還是攻擊者所為。

嚴密的防護邊界亦代表可以放寬監督。Claude Code 的參考 devcontainer正是為了讓 Agent 可以在無人監督下執行，而無需逐項操作批准。

Agent 使用的模型。這方面的機制包括系統提示詞、分類器、探針及訓練調整。由於模型具有概率性，這些機制只能影響 Agent 通常 會採取的行為，而不能限制它理論上能夠做到的事。

這些防禦措施相當有效。在 Gray Swan 的 Agent Red Teaming 基準測試中，該測試評估模型容易受提示注入影響的程度，Claude Opus 4.7在單次嘗試中的攻擊成功率約為 0.1%，經過 100 次自適應嘗試後則約為 5–6%。Claude Code 自動模式約能在過度積極的行為執行前偵測出其中 83%。然而，即使採用業界頂尖的防禦措施，模型層面的防護也永遠無法做到 100% 有效，因此不能單靠這一層防護。

Agent 可接觸的外部內容。 MCP 伺服器、第三方外掛及網頁搜尋工具都會將來自你無法控制來源的內容送入 Agent 的上下文。連接器經過審核，不代表資料也經過審核；例如，GitHub 連接器即使通過惡意軟件檢查，仍可能直接將遭污染的 README 載入模型的上下文。細緻限制工具權限有助縮小影響範圍。例如，只有唯讀 DB 存取權限的 Agent，其部署範圍可以遠比能寫入正式環境的 Agent 廣。

防禦措施應彼此重疊、互相補足。當環境防禦措施不可用時，模型層就必須彌補不足（這正是 Claude Code 的 自動模式 所要做到的）。在本機環境中，環境和模型防禦措施可防範惡意工具輸出；此外，亦可透過限制工具的能力和存取權限，在整個流程中更上層的位置加入防禦措施。

限制 Agent 活動範圍的模式

聚焦於環境層，我們介紹三種隔離模式，以及如何因應各個 Claude 平台——claude.ai、Claude Code 和 Cowork——調整這些模式。每種設計都是逐步形成的，過程中我們找出 Agent 所需能力與用戶須介入程度之間的平衡。

模式 1：短暫容器（claude.ai 程式碼執行）

claude.ai 最為人熟悉的是聊天介面，但它也能編寫及執行程式碼、產生檔案和呼叫連接器。Claude 在 claude.ai 內執行程式碼時，會在隔離的基礎設施中的 gVisor 容器內執行。Agent 完全在伺服器端運作；本機電腦不會執行任何程式碼，而檔案系統則是短暫的（每個工作階段各自獨立）。因此，影響範圍極小，但 Claude 的能力上限也很低——沒有持續保留的工作空間，也無法存取用戶的檔案系統。

這也表示 claude.ai 面對的是較傳統的威脅模型。我們要保護的不是用戶電腦免受 Agent 影響，而是保護自己的基礎設施，並防止不同租戶互相影響。推出 claude.ai 前，我們的工作主要集中於傳統安全事項，例如網絡設定、內部服務驗證和編排。

這些工作再次印證了安全領域最古老的教訓：最薄弱的一層，往往是自行建構的一層。gVisor 和 seccomp 對抗資源充足的攻擊者，已有遠比 Agent 式 AI 存在時間更長的加固歷史，因此審查工作集中於我們圍繞它們建構的較新部分。稍後我們會再談到這點，因為在我們影響最深遠的一宗事故中，出故障的正是自訂代理伺服器。

模式 2：人類介入迴圈的沙盒（Claude Code）

Claude Code 在用戶的電腦上執行，並可存取其檔案系統、Shell 和網絡。若沒有這些存取權限，編碼 Agent 的用途便十分有限，因此必須設法安全地授予這些權限。

其中一種做法是讓人類介入迴圈。這種方案只有在 Claude Code 的情況下才切實可行，因為一般用戶都是熟悉編碼環境的開發人員：他們看得懂 Bash，明白 rm -rf 的作用，而且每星期都會多次從不受信任的來源執行 npm install。這表示當「允許此操作」對話框彈出時，他們很可能具備足夠的專業知識，準確評估 Agent 正嘗試執行的操作及其涉及的風險。基於此，Claude Code 推出時採用了最簡單可行的防禦措施：允許讀取；寫入、bash 和網絡存取則須經批准。

然而，正如前文所述，幾星期內就出現了批准疲勞。諷刺的是，這表示原本旨在提供監督的功能，反而可能產生相反效果——部分用戶可能乾脆不再留意。為了減少草率批准，我們首先推出了作業系統層級的沙盒（macOS 上的 Seatbelt、Linux 上的 bubblewrap），以加固安全邊界：允許讀取、允許在工作區內寫入，但預設禁止網絡存取。在沙盒內，Agent 執行時基本不會受到幹擾。結果是權限提示減少了 84%，而且我們已開源執行環境，讓安全邊界可以接受審核。

我們的匿名化使用數據亦顯示，資深用戶自動批准的頻率約為新用戶的兩倍，但他們也更常在 Agent 執行期間中斷它。資深用戶不會逐步把關，而是更可能只在 Agent 偏離方向時才監督它。這或許是人們使用 Agent 的工作方式自然演變的結果，但這種做法同樣容易出錯：用戶必須具備足夠技術知識並保持專注，才能及早察覺偏離。隨着模型能力提升，Agent 開始撰寫愈來愈複雜的 bash 指令，要察覺這類偏離也變得更加困難。而當用戶轉用多 Agent 系統時，這種做法作為有效監督策略的可能性亦會大幅降低。

我們忽略的風險：信任對話框出現前的所有操作

2025 年年中至 2026 年 1 月期間，我們透過負責任披露計劃收到有關 Claude Code 漏洞的報告。其中三個漏洞針對的是用戶尚未同意任何事項之前就會執行的程式碼。要了解這種情況如何發生，不妨看看最直接的例子：開發者複製一個儲存庫，以檢視合併請求，而該儲存庫內含有一個定義了 hook 的 .claude/settings.json。由於 Claude Code 會在啟動時讀取專案設定——早於顯示標準的「你信任此資料夾嗎？」提示——攻擊者編寫並提交的 hook 就會自動執行。其餘個案的結構也大致相似：在建立信任邊界之前，程式已解析來自尚未受信任目錄的輸入。

每個個案的修正方式都相同：延後解析和執行專案本機設定，直至用戶接受信任提示之後。如果你正在建構類似的系統，對待專案開啟、設定載入和 localhost 監聽器時，應如同對待任何來自互聯網的入站請求一樣。它們不應只因看似本機操作，且在用戶同意前發生，就被默認為可信。

我們忽略的風險：用戶成為注入途徑

2026 年 2 月，在一次受控的內部紅隊演練中，一名研究員成功以網絡釣魚手法誘騙一名員工啟動 Claude Code，並使用惡意提示詞。這次釣魚看起來像一般協作請求——一封寫着「可以幫我執行這個嗎？」的電郵，附有一段可直接貼上的提示詞；提示詞本身讀起來也像例行工作指示。但在某個設定步驟中，它委婉地要求 Claude 讀取 ~/.aws/credentials、將內容編碼，然後 POST 到外部端點。該提示詞重試 25 次，Claude 有 24 次成功外傳資料。

這是一次直接提示詞注入——攻擊者的指令是經由用戶傳入，而不是來自工具輸出或擷取的內容。我們的模型層防禦以用戶意圖為依據；當指令是由用戶親自輸入時，分類器便沒有異常情況可供識別。若由人類承包商執行同一套指令，也會做出相同的事。

在這種情況下，唯一有效的防禦措施是環境本身，具體而言，是無論意圖如何都會封鎖 POST 請求的出站流量控制，以及從一開始就阻止存取 ~/.aws 的檔案系統邊界。

（我們在內部 Slack 分享了可用的提示詞供討論時，有人指出部分內部 Agent 會讀取 Slack。酬載如今已成為環境中的常駐內容。我們在討論串加入了金絲雀字串，以便留意是否有任何東西讀取它。在 Agent 閲讀所有內容的世界裏，調查工具本身亦是攻擊面。）

模式 3：本機 VM（Claude Cowork）

Claude Cowork 在用戶的桌面電腦上執行，並可存取用戶選取的工作區資料夾。由於這個平台是為一般知識工作而非軟件工程而設，一般用戶不太可能熟悉 bash。

因此，由人類介入的沙盒策略未必適用；不應期望非技術背景的知識工作者能判斷 find . -name "*.tmp" -exec rm {} \; 之類的 bash 指令。若核准例外需要一般用戶不具備的專業知識，管理員就應設定絕對且持續啟用的界線。

為了做到這一點，Claude Cowork 的首個版本在完整虛擬機器中執行，使用平台供應商提供的 hypervisor（macOS 上的 Apple Virtualization framework，Windows 上的 HCS）。VM 擁有自己的 Linux kernel、檔案系統和程序表。用戶選取的工作區和 .claude 資料夾會掛載到 VM；主機上的其他內容一概無法看見。憑證會留在主機的 keychain，絕不會進入 guest machine。這種設計可防範 Claude 在某個時候出現不符合預期的行為。即使 Claude 遭到入侵，仍可能破壞工作區資料夾內的內容，因此這種架構旨在確保該資料夾是它唯一能存取的地方（直至用戶新增連接器），而且由用戶控制掛載的內容。

在原本的架構——我們稱之為完整 VM 模式——中，Agent 的執行循環本身在 guest 中運作，因此 Claude 以一般 Linux 用戶的身分執行，並不知道自己受到沙盒限制。相較之下，Claude Code 由一個位於沙盒外的高權限程序逐條命令決定是否執行限制；只要注入的提示詞夠有説服力，或用戶疲憊時按一下核准，該程序便可能執行未受沙盒限制的內容。在這裏，外部沒有掌握逃生通道鑰匙的程序，因此也沒有任何元件有權核准例外。

然而，我們很快便發現，以完整 VM 模式執行整個 Agent 會帶來實際問題：VM 啟動期間任何故障都會令 Cowork 無法使用。把 Agent 循環移到 VM 外，同時讓程式碼仍在 VM 內執行，Claude 就能繼續回應用戶並協助排查問題，而不會因錯誤而停頓。這項改動對安全性的影響很小，因為 VM 仍會對 Agent 執行的程式碼實施檔案系統及網絡控制。

另外，我們也把本機 MCP 伺服器移到 VM 外。在 VM 內執行這些伺服器，不但令審核更困難，也會在 VM 更新時造成脆弱的相依性問題，而且不支援需要與本機程序（例如資料庫）互動的 MCP；無論如何，這類伺服器都必須在主機上執行。這項改動令 Claude Cowork 的運作方式與 Claude Desktop 一直以來處理本機 MCP 伺服器的方式一致：把它們視為用戶可選擇安裝的任何軟件，並由管理員決定是否啟用本機 MCP，以及啟用哪些（如有）。遠端 MCP 伺服器不受影響，因為它們不會在用戶的裝置上執行。

檔案系統控制是另一項重要的架構選擇。Claude 必須能夠存取主機上的部分檔案才能發揮作用，但我們希望盡量縮小影響範圍，並讓用戶清楚瞭解本機檔案存取情況。我們發現，提供不同的檔案掛載模式有助更精細地控制風險；Claude Cowork 提供唯讀、讀寫，以及讀寫但不可刪除模式。這裏一個可能的陷阱是，必須在路徑驗證之前解析符號連結，而不是之後；否則，已授權資料夾內的符號連結可能指向資料夾以外，藉此繞過限制。對企業客戶，我們允許管理員透過 MDM 設定中的掛載路徑許可清單控制這項設定。

我們忽略的風險：透過已核准網域外傳資料

第三方披露的資訊，提供了一個透過已核准網域外傳資料的明確例子。Claude Cowork 的出站流量許可清單正確地放行了前往 api.anthropic.com 的流量——產品必須呼叫我們自己的 API 才能運作。在這個案例中，一個放在用戶已掛載工作區內的惡意檔案，藏有隱藏指示，並附帶一個由攻擊者控制的 API 金鑰。Claude 按照指示讀取工作區內的其他檔案，並使用攻擊者的金鑰呼叫 Anthropic 的 Files API。出站代理檢查目的地後，看到 api.anthropic.com，便放行了流量。檔案其後被上載至攻擊者的 Anthropic 帳戶。沙盒運作完全正常，但資料仍遭外傳。

以往，我們把許可清單視為目的地篩選器，用來告訴 Claude，這些網域可以連線。但把它理解為一種能力授權或許更恰當。透過許可清單上任何網域可存取的每項功能，如今都是攻擊面。放行 api.anthropic.com，就等同允許把檔案上載至任意 Anthropic 帳戶。

我們透過在 VM 內設置一個防護性中間人代理來修正問題，由它攔截通往我們 API 的流量。它只會放行帶有 VM 自身已配置工作階段權杖的請求；攻擊者嵌入的金鑰則會被代理拒絕。代理亦會封鎖可啟用伺服器端擷取功能的標頭。代理設於 VM 內，而非我們的伺服器上，因為只有 VM 知道請求的來源；從伺服器的角度來看，Cowork 請求與任何其他 API 用戶端的請求無法區分。

這亦再次印證一個原則：自行開發的軟件往往最薄弱。我們各項產品中的 hypervisor、seccomp 和 gVisor 一直運作可靠。出問題的是我們自訂的允許清單代理。

我們忽略的風險：VM 隔離亦令端點偵測軟件無法進入

評估 Claude Cowork 時，企業保安團隊問：「為甚麼我們的 EDR 看不到內部情況？」原因是，同一套令 Claude 受到隔離的機制，亦令以主機為基礎的端點偵測與回應軟件無法進入。從 EDR 的角度來看，Claude Cowork 只是一個不透明的 hypervisor 程序。它無法檢查客體。

隔離會降低可視性；對合規狀況取決於端點可視性的團隊而言，這種不透明性會帶來問題。我們目前的緩解措施是使用拉取式 OTLP 匯出，讓管理員事後擷取事件記錄，但這並不等同即時監察。如果你正在建構類似方案，請及早為這項討論預留時間。

信任 Agent 讀取的內容

企業經常問我們如何保障 MCP 連線的安全。這是個好問題，但更恰當的問題應涵蓋比 MCP 本身更廣的範圍。提供給 Agent 的任何外部資源都同時帶來兩種風險：傳統供應鏈意義上的程式碼執行風險，以及提示詞注入攻擊途徑。傳統的依賴項審核（固定版本、驗證簽章、審查原始碼）可處理第一種風險，卻會忽略第二種。

遠端與本機的分別，比看起來更重要。本機安裝的工具可以審核。你可以閲讀程式碼、固定版本，並確定它不會在你不知情下改變。遠端工具——例如託管的 MCP 伺服器或雲端連接器——在你批准後，仍可能隨時改變行為；你在安裝時作出的信任判斷可能不再適用。我們的連接器目錄透過持續審查處理這個問題，但目錄以外的任何項目都應視為不可信。請先使用虛構資料測試，並在能限制惡意工具影響範圍的環境中執行。

即使工具值得信任，其輸出仍然是攻擊面。先前提到的 GitHub README 範例正是這種情況；任何用於網頁的輸入掃描，都需要以同樣嚴謹的方式套用於具網絡連線能力的工具結果。即使這會增加延遲，而且並非萬無一失，我們仍傾向即時檢查：一旦受污染的工具回傳引導 Agent 外洩資料，日誌只會顯示一次成功且獲授權的 API 呼叫。事後沒有任何訊號可供追查。

在 Claude Code 和 Claude Cowork 中，工具呼叫會經由代理伺服器傳送，由代理伺服器執行網絡及檔案政策，並在回傳值進入模型的上下文前進行檢查。負責檢查的分類器可以是小型、快速的模型，不必是負責推理的模型。

展望未來

模型和產品正迅速發展。隨着它們不斷進步，風險也會轉變和演化，我們的緩解措施必須跟上步伐，才能應對這些風險。

持久記憶中毒。 Agent 上下文中會跨工作階段保留的部分持續增加，包括產品記憶、CLAUDE.md 檔案、已掛載的工作區，以及排程執行和長時間運作的 Agent 的狀態目錄。注入內容一旦進入其中任何一處，每次 Agent 啟動時都會重新載入。隨着更多 Agent 狀態在工作階段結束後仍然保留，從傳統的入侵後階段角度來看，新的持久化機制正構成威脅。在工作階段啟動時使用有效分類器，將需要變得更加普遍。

多 Agent 信任升級。一方面，子 Agent 可以隔離不受信任的內容，向主 Agent 回傳結構化事實，而非原始文字。另一方面，這也可能遭到濫用：如果子 Agent 的輸出被視為比原始工具結果更可信，只因為這些輸出來自「我們」，便會引入新的提示詞注入途徑。在多 Agent 系統中，分配不同信任級別與承受信任升級風險之間存在取捨。

Agent 身份。Claude Cowork 對 Agent 身份的處理方式相當具體：憑證保留在主機的鑰匙圈中，虛擬機器會取得每個工作階段專用、權限範圍受限的權杖，而且該權杖可獨立於用戶的權杖撤銷。不過，我們開始探討更廣泛的跨平台 Agent 身份問題：Agent 應否擁有自己的主體身份，還是應作為用戶的延伸，並繼承用戶的權限？最終答案或許會結合兩者。

隨着 Agent 的能力提升，攻擊面不斷變化。我們見過的故障類型，很可能會在不同業界和實驗室重複出現。我們需要共同投入資源，提升專為 Agent 設計的安全防護態勢，涵蓋共用基準測試、披露規範、通用身份標準，以及跨供應商紅隊測試。本文聚焦於遏制措施，但這只是 Agent 安全的一部分。如需瞭解治理、可觀測性及其餘技術堆疊，請參閲NIST 有關 AI Agent 身份與授權的項目、由澳洲 ACSC 牽頭，並與 CISA 及英國 NCSC 合作制定的六個機構關於採用 Agentic AI 的指引，以及 AI 管理標準ISO/IEC 42001。我們的 Glasswing 倡議是其中一項貢獻，但我們期待與合作夥伴和競爭對手攜手處理這個關鍵議題。

摘要

簡而言之，有幾項原則是我們一再強調的：

先在環境層設計隔離措施，再於模型層引導行為。 讓我們學到最多的兩宗事件——員工遭遇釣魚攻擊，以及第三方允許清單外洩——都涉及資料外流，即資料經由獲準路徑離開。在這兩宗事件中，模型層都無法提供幫助；沒有任何異常情況可供它偵測。當所有概率式防護都未能奏效時，受到攻擊的就是確定性邊界。

隔離強度應與用戶的監督能力相匹配。 能讀懂 bash 的開發人員，與不懂 bash 的知識工作者，面對的並非同一種威脅模型。用戶能否評估 Agent 即將執行的操作，應有助決定隔離策略；無論答錯哪一邊——對專家設下過多阻礙，或對非專家過度信任——本身都是一種失誤。

慎用自訂元件。 經過實戰驗證的虛擬機監控程式、系統呼叫篩選器和容器執行環境，經受過的對抗性檢驗遠多於你自行構建的任何元件。本文所述的每一種部署中，標準基礎元件都保持穩固，但我們自行構建的周邊部分卻暴露出缺陷。

歸根究柢，雖然 Agent 可能屬於一種全新的軟件類別，但它們在系統層面的互動並非新事物。它們仍會讀取檔案、開啟通訊端並建立程序；因此，利用成熟工具進行隔離，仍然是至關重要且切實可行的防禦方式。隨着 AI 發展，部署的風險與回報平衡會不斷變化，但嚴格限制事故影響範圍，往往能令這種平衡朝正確方向移動。

鳴謝

作者：Max McGuinness、Mikaela Grace、Jiri De Jonghe、Jake Eaton 和 Abel Ribbink。

我們亦感謝 Hanah Ho、Hasnain Lakhani、Pedram Navid、Molly Villagra、Maya Nielan、Akila Srinivasan、Travis Szucs、Sam Attard、Alfred Xing、Mohamad El Hajj、Gabby Curtis、David Dworken、Adam Jones、Amie Rotherham、Christian Ryan、Lucas Smedley、Brett Andrews 等人的貢獻。

特別感謝我們的安全及產品工程團隊，以及通報 Claude 產品漏洞的個人和機構。

註腳

1. Claude Code 自動模式會把命令核准交由基於模型的分類器處理；這種做法可減少操作阻礙（約 0.4% 的無害命令會被封鎖），代價是無法攔截其中一部分有風險的命令（約 17% 過度積極的操作會通過），因此它只是沙盒內縱深防禦的一層，不能取代沙盒。