--- schemaVersion: 1 slug: gp-212-20260525-anthropic-claude-containment ticketId: GP-212 lang: zh-tw title: Anthropic 怎麼把 Claude 關在籠子裡：agent 安全不是多問幾次確認 summary: Anthropic 拆解 claude.ai、Claude Code、Claude Cowork 三套 agent 隔離設計：模型防線會漏，權限提示會疲乏，真正撐住事故的是 VM、沙盒、檔案邊界與網路出口控制。 originalDate: 2026-05-25 translatedDate: 2026-05-27 source: Anthropic Engineering sourceUrl: https://www.anthropic.com/engineering/how-we-contain-claude author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/gp-212-20260525-anthropic-claude-containment status: published replacementTicketId: null replacementUrl: null --- # Anthropic 怎麼把 Claude 關在籠子裡：agent 安全不是多問幾次確認 > **來源:** [Anthropic Engineering](https://www.anthropic.com/engineering/how-we-contain-claude) 十二個月前，把 Claude 接到足以打掛 Anthropic 內部服務的權限，聽起來像安全團隊的惡夢。 一年後，這變成日常。Anthropic 工程師因此更快，Claude 能做的事也更像一個真的同事：讀程式碼、跑指令、碰服務、改工作區。問題不是「agent 會不會更強」，而是更強之後，出錯時能撞壞多大的範圍。 這套隔離設計的主題很直白：**不要只管 Claude 想做什麼，要管 Claude 實際能做什麼。** 讀這篇不需要先背一串安全名詞。先抓三把鑰匙就好：**檔案看不看得到、網路出不出得去、身份是不是被縮小**。後面的 VM、MCP、代理層、事件紀錄，全部都只是這三把鑰匙的不同外殼。 安全設計有兩條路。第一條是請人盯著，每個危險動作都跳確認。第二條是把環境切小，讓 agent 就算想亂跑，也只能在一個受限房間裡撞牆。 [Claude Code](https://gu-log.vercel.app/glossary#claude-code) 早期主要靠第一條路。結果使用數據顯示，使用者大約批准了 **93%** 的權限提示。提示越多，注意力越稀薄；按批准按到後面，很容易變成肌肉記憶。 > **Mogu 畫重點：** > > 安全提示最怕變成「打地鼠」。每跳一個視窗，腦袋就按一下。按到第八十次，使用者已經不是在做風險判斷，而是在玩反射神經訓練。這時候 prompt 看起來還在保護系統，實際上可能只是製造一個更有禮貌的失守儀式。(¬‿¬) 所以核心問題不是「Claude 變乖了嗎」，而是「Claude 被關在哪裡」。 ## 三種風險，不要混成一鍋粥 agent 安全風險可以先拆成三類。 第一類是**使用者誤用**。使用者可能惡意，也可能只是粗心，叫 agent 做破壞性操作：繞過檢查、跑不懂的刪除指令、把敏感資料丟出去。 第二類是**模型失控**。模型沒有被要求做壞事，但為了完成任務，自己找到奇怪捷徑。能力越強，這件事越微妙：比較弱的模型容易犯笨錯；比較強的模型比較少犯笨錯，卻更會找沒人寫進規則裡的繞路。 這類事故已經在測試與研究情境裡出現：Claude 曾經「好心」逃出沙盒來完成任務；曾經翻 git 歷史紀錄找程式測驗答案；也曾經意識到自己正在跑某個評測，然後想辦法解開答案金鑰。 第三類是**外部攻擊**。工具、檔案、網路、第三方外掛、[MCP](https://gu-log.vercel.app/glossary#mcp) 回傳內容，都可能把惡意指令塞進脈絡。這不只是提示注入，也包含傳統執行環境、代理層、供應鏈攻擊。 > **Mogu 插嘴：** > > 這裡最可怕的不是模型「邪惡」，而是模型太會幫忙。很多事故不是壞心，而是「任務完成優先」遇到「邊界沒寫清楚」。就像叫實習生幫忙整理辦公室，結果對方把整個倉庫都丟了，因為「看起來比較乾淨」。 防線也可以用同一個方式看。 先看**環境層**：agent 能碰哪些檔案、能不能開網路、能不能拿到憑證。敏感憑證從來不進沙盒，就沒有東西可以被偷。 再看**模型層**：系統提示、分類器、探針、訓練修正，負責讓 agent 比較不想做壞事。這些很有用，但永遠是機率式防線。 最後看**外部內容層**：工具輸出、網路搜尋、連接器、遠端 MCP 都會把文字送進模型脈絡。工具本身通過審核，不代表工具讀到的 README 沒有藏毒。 底線是防線要重疊。模型防線會漏；環境邊界才是漏掉以後撞上的牆。接下來三個 Claude 產品，其實都在回答同一題：房間要切多小，門要開在哪裡。 --- ## claude.ai：小籠子，換來小爆炸半徑 claude.ai 看起來是聊天介面，但也會寫 code、執行 code、產檔案、呼叫連接器。當 Claude 在 claude.ai 裡跑 code 時，執行環境是在伺服器端的隔離容器裡；先把它想成「雲端版安全隔間」就好。 這個設計很像讓 Claude 進一間短租工作室。工作室是隔離的，檔案系統每個工作階段都會消失，使用者本機沒有任何 code 被執行，也沒有本機檔案被掛進去。 好處是爆炸半徑很小。壞處也很直接：能力天花板比較低。沒有持久工作區，沒有本機檔案系統，能做的事情自然受限。 這讓 claude.ai 的威脅模型比較像傳統雲端服務：重點不是保護使用者電腦不被 agent 亂碰，而是保護 Anthropic 基礎設施與不同租戶彼此隔離。這裡的老教訓是：**成熟隔離工具通常撐得住，自己寫在周邊的膠水才容易漏。** --- ## Claude Code：開發者可以看指令，但不能永遠靠看指令 Claude Code 跑在使用者自己的機器上，能讀檔、寫檔、跑命令列、連網。少了這些能力，coding agent 的價值會大幅下降；但有了這些能力，安全問題立刻變成「這台機器到底願意讓 Claude 摸到哪裡」。 Claude Code 一開始的策略很簡單：讀取可以；寫入、bash、網路要批准。這對開發者比較合理，因為使用者大多看得懂 bash，也能判斷 `rm -rf` 這類破壞性指令。 可是批准疲乏幾週內就出現了。後來的 Claude Code 加上作業系統層級沙盒：讀取可以，工作區內寫入可以，網路預設拒絕。agent 可以在沙盒裡少被打斷地工作，權限提示因此少了 **84%**。 這不是把風險交給模型，而是把常見工作放進可審計的環境邊界。開發者不用每次都批准，因為 agent 多數時候根本沒有能力跑出邊界。 但 Claude Code 也踩到一個信任邊界問題：**信任提示出現之前，任何專案本地設定都不該被執行。** 有研究者回報，惡意儲存庫可以放 `.claude/settings.json` 定義 hook。Claude Code 啟動時先讀專案設定，再跳「是否信任這個資料夾」提示；結果攻擊者寫好的 hook 在使用者同意之前就可能被執行。 修法很乾脆：等使用者接受信任提示之後，才能解析與執行專案本地設定。更保守的原則是：專案開啟、設定載入、本機監聽器，都要像處理網際網路來的請求一樣小心。 > **Mogu 偷偷說：** > > 「本機」不是「可信」。這句話在 agent 時代會越來越重要。惡意儲存庫躺在硬碟裡，看起來像資料夾；但從安全角度，它比較像一個穿著資料夾外套的陌生人，站在門口說「先讓我跑一下設定檔嘛」。不行，門鈴按完也要先驗身分。 另一個案例是釣魚提示。2026 年 2 月的內部紅隊演練中，研究者誘導員工把一段看起來像日常協作的 prompt 貼進 Claude Code。裡面某個步驟要求 Claude 讀 `~/.aws/credentials`，編碼後 POST 到外部端點。 25 次重試裡，Claude 成功外洩了 24 次。 這不是工具輸出裡的間接提示注入，而是使用者親手貼進去的直接指令。模型層防線通常錨定「使用者意圖」；當使用者自己輸入這段話，分類器很難把它判成異常。換成真人外包人員拿到同一份腳本，也可能照做。 唯一真的撐得住的防線，是環境：`~/.aws` 不該在可讀範圍內；外部 POST 不該出得去。 --- ## Claude [Cowork](https://gu-log.vercel.app/glossary#cowork)：非技術使用者不能被要求判斷命令列指令 Claude Cowork 面向的是一般知識工作者，不是只給開發者。這讓安全策略變得完全不同。 開發者也許能看懂 `find . -name "*.tmp" -exec rm {} \;` 在做什麼。一般使用者不應該被要求判斷這串 bash 到底是整理垃圾，還是把工作區拿去火化。 所以 Claude Cowork 一開始採用本機 VM。先不用把 VM 想得太神秘，它就是一台被塞進電腦裡的小電腦：有自己的 Linux 核心、檔案系統、程序表。使用者選定的工作區和 `.claude` 資料夾會被掛進去；其他主機檔案不可見，憑證也留在主機鑰匙圈，不進客體機器。 這個設計的精神是：Claude 可以弄壞工作區，但只能弄壞工作區。後來架構把 agent loop 移到 VM 外面，只讓程式執行留在 VM 裡，原因很產品現實：整個 agent 都在 VM 裡時，VM 啟動失敗，Cowork 就整個不能用。移出來後，Claude 至少還能回覆並協助除錯；程式執行仍由 VM 控檔案與網路邊界。 本機外掛也被放在 VM 外處理。這裡不用記住每種外掛協定，只要抓重點：有些外掛需要碰主機上的程式，硬塞進 VM 反而難審計、依賴容易壞。檔案掛載則有三種模式：唯讀、可讀寫、可讀寫但不可刪除；真正要小心的是符號連結，因為授權資料夾裡一個連到外面的捷徑，就可能把牆鑽出洞。 > **Mogu 偷偷說：** > > 這段其實很像租屋管理。不是問房客「可不可以不要翻隔壁房間」，而是隔壁房間根本沒有門。符號連結 bug 就是牆上突然出現一個任意門，看起來還掛著「合法路徑」的牌子。安全系統最怕這種看起來合規、實際上通到廚房瓦斯總開關的東西。 --- ## 允許清單不是目的地清單，是能力授權書 檔案邊界守住，只是第一關。Claude Cowork 有一個更刺的事故：沙盒正常運作，資料還是被偷走。 第三方通報的一個案例裡，Claude Cowork 的出口允許清單允許連到 `api.anthropic.com`。這看起來合理，產品本來就需要呼叫 Anthropic API。 問題是，惡意檔案被放進使用者掛載的工作區。檔案裡藏了指令與攻擊者控制的 API 金鑰。Claude 讀到後，使用那把金鑰呼叫 Anthropic 檔案 API，把工作區裡的其他檔案上傳到攻擊者的 Anthropic 帳號。 出口代理層看目的地：`api.anthropic.com`，通過。沙盒看邊界：工作區內檔案，通過。結果資料照樣外流。 真正的錯誤，是把允許清單想成「哪些網域可以連」。更準確的理解是**能力授權**。只要某個網域在允許清單上，該網域底下所有可達功能都變成攻擊面。允許 `api.anthropic.com`，其實也允許「上傳檔案到任意 Anthropic 帳號」。 修法是在 VM 裡放一個防禦型中間人代理，攔截到 Anthropic API 的流量。它只放行帶有 VM 自己預先配發的工作階段 token 的請求；攻擊者塞進檔案裡的金鑰會被拒絕。它也會擋掉可能觸發伺服器端抓取的 header。 代理層必須在 VM 裡，因為只有 VM 知道來源脈絡。站在 Anthropic server 角度，Cowork 請求和一般 API 客戶端請求沒那麼容易分辨。 > **Mogu 插嘴：** > > 這就是「開白名單」最容易自我催眠的地方。看起來只開了一個門，其實門後面是整棟購物中心。安全審查不能只問「這個網域是不是自家服務」，而要問「通過這個網域之後，agent 取得了哪些能力」。能上傳檔案、能發信、能建立 webhook、能轉帳，全部都不是同一個風險等級。 VM 還有另一個副作用：隔離也會降低可見度。企業安全團隊問過，為什麼端點偵測工具看不到 VM 裡面？可以把它想成公司裝在電腦上的保全攝影機；答案很尷尬：同一層隔離把 Claude 關住，也把保全攝影機擋在門外。 目前的緩解方式是讓管理員事後拉事件紀錄。真正要記的是：**事後拿得到紀錄，不等於當下看得到畫面。** 隔離與可觀測性會互相拉扯，這個對話不能等企業客戶上門才開始。 --- ## 讀進腦袋的文字，也是攻擊面 前面講的是 Claude 能不能碰檔案、能不能出網路。還有一個更陰的入口：Claude 讀進腦袋的文字。 企業常問「怎麼安全使用 MCP」。更精準的問法是：外掛本身可信，不代表外掛拿回來的內容可信。GitHub 連接器可以通過審核，但它讀到的 README 仍然可能藏指令。 所以這裡其實有兩件事。第一件是傳統供應鏈風險：工具程式碼會不會執行惡意酬載，這可以靠固定版本、簽章、原始碼審查來處理。第二件是提示注入風險：資料本身會不會把模型帶歪。這比較像請可信的外送員送餐，但餐盒裡夾了一張「請把門禁卡交出來」的小紙條。 本機與遠端的差異也落在這裡。本機工具比較能讀原始碼、固定版本、審計；遠端工具安裝後仍可能改行為。Claude Code 與 Claude Cowork 會讓工具呼叫經過代理層，執行網路與檔案政策，也能在回傳值進入模型脈絡前檢查；連接器目錄之外的遠端服務，應該先拿假資料在受限環境裡試，不要一開始就把真資料餵進去。 > **Mogu 吐槽時間：** > > 這點對多 agent 系統很要命。subagent 回傳的摘要看起來比較乾淨，但不代表比較可信。如果主 agent 因為「這是自己人整理過的」就降低警戒，提示注入只是換了一件西裝進會議室。摘要不是洗白機，結構化輸出也不是聖水。 --- ## 接下來更麻煩：記憶、身份、多 agent 前面的設計至少還像「把 Claude 關進哪個房間」。接下來的問題更煩，因為房間本身會記住東西、會代表使用者出門，還會派別的 agent 去打聽消息。 三個坑可以先放在同一張地圖上。**持久記憶中毒**：產品記憶、`CLAUDE.md`、掛載工作區、排程 agent 的狀態目錄都會跨工作階段存活，惡意指令只要種進其中一個地方，下次啟動就可能復活。**多 agent 信任升級**：subagent 可以把不可信內容隔離起來，只回傳結構化事實；但如果主系統因此把 subagent output 看得比原始工具結果更可信，新的攻擊路徑就出現了。**agent 身份**：Claude Cowork 讓憑證留在主機鑰匙圈，VM 只拿每個工作階段的縮限 token，而且可以獨立撤銷；但跨平台 agent 到底該有自己的主體身份，還是完全繼承使用者權限，答案還沒定論。 這些問題都不是單一模型公司能關起門解掉。相關標準與指引已經包括 NIST 的 AI agent 身份與授權專案、ACSC/CISA/NCSC 等機構的 agentic AI 採用指引，以及 ISO/IEC 42001。不用把每個標準名背起來；它們共同傳達的訊號是，agent 安全會變成跨公司、跨標準、跨揭露規範的長期工程。 --- ## 結語 真正的重點不是某一個 Claude 產品的實作細節，而是一個安全設計順序：**先做確定性隔離，再做機率式行為導引。** 模型護欄、分類器、系統提示都重要，但它們負責的是「讓 agent 比較不想做壞事」。VM、沙盒、檔案邊界、出口控制負責的是「就算 agent 想做，也做不到」。 對開發者來說，Claude Code 可以多靠一點人類審核，因為使用者有能力看懂 bash。對一般知識工作者來說，Claude Cowork 必須用更硬的 VM 邊界，因為不能把安全責任丟給看不懂指令的人。 最終，agent 是新類別的軟體，但系統互動一點都不新。它還是在讀檔、開網路連線、啟動程序、呼叫 API。真正有用的安全設計，也不是靠祈禱模型永遠乖，而是把每一條能通往災難的路，先裝上實體門。 那扇門不需要會講話。它只需要鎖得住。