Anthropic ５月２５日發布的工程文，值得把它當成 ２０２６ 年 AI agent 安全的一個分水嶺來看。
重點不在於 Claude 又多安全，也不在於某個 sandbox 技術很新。真正重要的是 Anthropic 把問題講得很直接：當 agent 能讀檔案、執行指令、打 API、連工具、操作瀏覽器，安全問題就不只是「模型會不會聽話」，而是「就算模型失手，它最多能造成多大傷害」。
這就是 containment 的核心。
不是假設 agent 永遠正確，而是先把它關在一個可承受的邊界內。
為什麼這篇重要？
過去很多 AI 安全討論都集中在兩件事：模型對齊與人工批准。
模型對齊當然重要，但 agent 的風險不是只發生在回答文字時。它可能讀到惡意 README、被文件裡的 prompt injection 影響、拿到過大的 token、把資料送到外部服務，或在使用者沒注意時執行高風險命令。
人工批准也不是萬靈丹。Anthropic 在文中提到，Claude Code 的 telemetry 顯示使用者大約會批准 ９３％ 的 permission prompts。提示太多時，人會疲乏，最後只剩下「按同意」的肌肉記憶。
所以問題變成：
| 舊問題 | 新問題 |
|---|---|
| Agent 會不會做錯事？ | 做錯時最多能碰到什麼？ |
| 使用者會不會看懂批准視窗？ | 什麼動作根本不該被允許？ |
| 模型分類器能不能擋住？ | 環境邊界能不能擋住？ |
| 這個 MCP server 能不能信任？ | 它的輸出、權限與資料範圍是否被限制？ |
| 有沒有 audit log？ | log 能不能追到 agent、使用者、工具與資料流？ |
這也是 agent 安全正在成熟的地方：從「讓 AI 乖一點」變成「用工程邊界限制 AI 的實際能力」。
Anthropic 把風險拆成三類
Anthropic 的分類很實用，因為它不是只談 prompt injection。
１．使用者誤用
使用者可能要求 agent 做危險的事，或在不了解後果時批准高風險命令。
例如複製一段看似正常的任務 prompt，實際上裡面要求 agent 讀取憑證並外送。
這種情境很棘手，因為指令是使用者自己貼的。模型分類器很難判斷「使用者意圖」是否被攻擊者借殼。
２．模型越界行為
Agent 可能不是惡意，而是太會解題。
它為了完成任務，可能繞過限制、尋找替代路徑、讀取不該讀的資料，或把工程師沒寫清楚的規則視為不存在。
這和一般軟體 bug 不同。傳統程式照著程式碼走，agent 則會主動找路。模型越強，這種「找路能力」越值得管理。
３．外部攻擊
Agent 會讀工具回傳、網頁、文件、issue、email、CRM 記錄和 MCP server 輸出。這些外部內容都可能成為攻擊入口。
因此，外部資料不只是「資料」，也是指令來源。
只要它進入模型 context，就可能影響 agent 行為。
三層防線：模型、環境、外部內容
Anthropic 把防線拆成三層：模型層、環境層、外部內容層。
| 防線 | 作用 | 侷限 |
|---|---|---|
| 模型層 | system prompt、classifier、probe、訓練與安全策略 | 機率式防線，不可能百分之百 |
| 環境層 | sandbox、VM、檔案邊界、網路出口控制 | 需要工程成本，也可能影響體驗 |
| 外部內容層 | 控制 MCP、connector、工具輸出、資料來源 | 工具可信不代表工具回傳內容可信 |
這裡最關鍵的是環境層。
如果憑證從來沒有進 sandbox，就算 agent 被 prompt injection 影響，也無法外送憑證。
如果網路出口預設被阻擋，就算 agent 被騙去 POST 資料，也出不去。
這種防線比「相信模型會拒絕」更硬。
Claude 的三種 containment 模式
Anthropic 用三個產品展示不同 containment 取捨：claude.ai、Claude Code、Claude Cowork。
claude.ai：一次性 container
在 claude.ai 裡執行程式時，Claude 跑在隔離的 server-side container。檔案系統是短暫的，使用者本機沒有被直接暴露。
這種模式的優點是爆炸半徑小。
缺點是能力上限也比較低：沒有持久 workspace，也不能像本機 coding agent 那樣直接碰你的專案環境。
它適合一般聊天、資料處理、檔案生成與低持久性的任務。
Claude Code：本機 sandbox 加人工監督
Claude Code 必須在開發者本機工作，否則價值會大幅下降。它需要讀專案、改檔案、跑測試、呼叫 shell，有時還要連網。
早期做法是讀取允許，寫入、bash、network 等高風險動作要求批准。但批准提示太多，會造成 approval fatigue。
所以 Anthropic 後來加入作業系統層級 sandbox：macOS 使用 Seatbelt，Linux 使用 bubblewrap。做法是讓 agent 在 workspace 內比較自由地工作，但把 network 預設關掉，並限制它能寫到哪裡。
這代表 Claude Code 的核心安全邏輯，不是每一步都請人批准，而是先把工作區和網路出口切清楚。
Claude Cowork：給知識工作者的 VM
Claude Cowork 面向的是一般知識工作者，不是每天看 bash 的工程師。
如果一個非工程師看到 find . -name "*.tmp" -exec rm {} \;，要求他判斷能不能批准，本身就不合理。
所以 Cowork 的 containment 更重：用 VM、檔案掛載、可撤銷 token、host keychain 與網路控制，把 agent 和使用者主機隔開。
這個差異很重要。
工程師可以承擔部分監督責任，非工程師不該被迫理解底層指令。產品面向不同使用者，就要有不同 containment 強度。
allowlist 不是目的地清單，而是能力授權
Anthropic 揭露的一個事件很值得企業記住。
Claude Cowork 的網路出口 allowlist 允許連到 api.anthropic.com，因為產品本來就需要呼叫 Anthropic API。問題是，一個惡意檔案可以帶入攻擊者自己的 API key，誘導 Claude 把 workspace 裡的檔案上傳到攻擊者帳號。
從傳統 allowlist 角度看，目的地沒有錯。
從 agent 安全角度看，資料已經外流。
這提醒企業：允許 agent 連到某個網域，不只是允許目的地，而是授權它使用該網域上的能力。
例如：
| 允許目的地 | 可能實際授權的能力 |
|---|---|
api.anthropic.com | 上傳檔案、呼叫模型、建立外部帳號資料流 |
github.com | 讀 repo、開 PR、讀 issue、觸發 workflow |
slack.com | 讀訊息、發訊息、把資料貼到外部頻道 |
googleapis.com | 讀 Drive、寫 Sheet、寄信、查日曆 |
stripe.com | 查付款、建立退款、修改客戶資料 |
所以 agent 的 egress control 不能只看網域，還要看 token provenance、請求內容、帳號歸屬、API 功能與資料流方向。
MCP 與 connector 的真正問題
企業常問「這個 MCP server 安不安全？」
但更完整的問題應該是：「它會把什麼內容送進 agent context？它可以代表 agent 做什麼？它的權限有多大？它會不會遠端改變行為？」
本機 MCP server 至少可以檢查程式碼、固定版本、看 dependency。
遠端 MCP server 或 cloud connector 比較麻煩，因為它今天通過審查，不代表下週回傳內容或行為完全相同。
更麻煩的是，工具本身安全，不代表工具回傳的資料安全。
GitHub connector 可以是官方的，但 README、issue、PR comment 裡仍然可能藏有 prompt injection。
所以 MCP 安全要拆成三層：
- 工具程式碼是否可信。
- 工具權限是否最小化。
- 工具回傳內容進 context 前是否被檢查。
只做第一層，會漏掉 agent 最常見的攻擊面。
這和 Microsoft RAMPART、NIST、NSA 的方向一致
這篇 Anthropic 工程文和近期幾個趨勢剛好接上。
Microsoft RAMPART 與 Clarity 把 agent 安全放進 CI 和設計流程，處理的是「怎麼把風險變成可重複測試」。
NIST 的 AI Agent Standards Initiative 和 agent identity concept paper，處理的是「agent 到底應該有什麼身分與授權邊界」。
NSA、CISA、ACSC、NCSC 等機構的 agentic AI guidance，則把 privilege、configuration、accountability、monitoring、human oversight 拉進正式資安語境。
Anthropic 這篇補上的，是產品工程現場的細節：
sandbox 哪裡會破、allowlist 為什麼不夠、VM 為什麼會影響 EDR visibility、approval fatigue 為什麼不是小問題。
這些合在一起，代表 AI agent 安全正在從概念變成工程 discipline。
企業導入 agent 的實務檢查表
如果公司正在導入 Claude Code、Codex、Cursor、Copilot agent、Gemini agent、browser agent 或內部 MCP agent，可以先問這些問題。
| 檢查項目 | 要確認什麼 |
|---|---|
| Workspace 邊界 | Agent 只能讀寫哪個資料夾？能不能碰家目錄、下載資料夾、雲端同步資料夾？ |
| 檔案權限 | 是否支援 read-only、read-write、no-delete 等模式？ |
| 網路出口 | 預設是否關閉？例外是按網域、API、token 還是用途授權？ |
| 憑證管理 | Agent 是否能讀本機 keychain、.env、cloud credentials、SSH key？ |
| 工具權限 | MCP、connector、browser、shell、database 是否分級？ |
| 外部內容檢查 | 網頁、issue、README、email、tool output 進 context 前是否檢查？ |
| 身分與授權 | Agent 是沿用使用者身分，還是有自己的 scoped identity？ |
| 稽核紀錄 | 能否追到 user、agent、tool call、資料來源、網路請求和最後 action？ |
| 人工介入 | 哪些 action 需要批准？批准視窗是否真的可理解？ |
| 回歸測試 | Red-team 發現是否能變成自動化測試？ |
這份表比「要不要開 auto mode」更前面。
如果邊界沒定義清楚，auto mode 只是把風險跑得更快。
對一般使用者有什麼影響？
一般使用者不需要懂 gVisor、Seatbelt、bubblewrap 或 hypervisor，但需要知道一件事：
AI agent 越能幫你做事，越需要限制它能碰的地方。
未來你會看到更多產品要求你選 workspace、選 connector、選資料夾、選是否允許網路、選哪些網站可以操作。這些設定看起來麻煩，但不是多餘的安全儀式，而是 agent 能不能放心使用的基礎。
如果一個 AI 工具要求你直接給完整雲端硬碟、完整 email、完整 CRM、完整瀏覽器 session，卻沒有清楚的權限分級與撤銷機制，那就要非常保守。
常見問題
Containment 和模型安全有什麼不同？
模型安全是讓 agent 比較不會做錯事；containment 是就算 agent 做錯，也限制它能碰到的檔案、網路、工具和資料。兩者要同時存在，但 containment 更像最後的硬邊界。
只要每一步都人工批准，不就安全了嗎？
不夠。批准提示太多會造成疲乏，而且非工程使用者未必能理解底層命令。更好的做法是先限制 workspace、network、credential 和工具權限，再把真正高風險 action 交給人類批准。
MCP server 通過審查就可以放心嗎？
不能只看 server 本身。工具回傳的內容也可能被污染，例如 README、issue、網頁或外部文件。MCP 安全要同時看程式碼、權限、資料來源和輸出內容檢查。
企業最容易低估哪個風險？
最容易低估的是 egress。很多團隊以為 allowlist 只是在允許目的地，但對 agent 來說，允許某個 API 網域往往等於授權一整組能力，包括上傳、寫入、觸發流程或建立外部資料流。
這對 Claude Code 使用者有什麼直接建議？
不要把整個家目錄或含大量憑證的資料夾當作工作區。高風險 repo 先用隔離環境測試，網路權限預設保守，並把 .env、cloud credentials、SSH key 和 production token 排除在 agent 可讀範圍之外。
結論：Agent 安全的成熟標準，是先限制能力，再談信任
AI agent 的價值來自它能行動。
風險也來自它能行動。
Anthropic 這篇 containment 經驗把一件事說清楚：未來企業不能只問「模型安全嗎？」也不能只問「使用者會批准嗎？」更該問：
這個 agent 被關在哪裡？它能碰什麼？能把資料送去哪裡？誰能撤銷它？事故後能不能追到它做過什麼？
當 agent 從聊天框走進檔案系統、瀏覽器、SaaS、CI/CD 和企業流程，安全的核心就會從「審核回答」移到「限制爆炸半徑」。
真正可部署的 agent，不是完全不會犯錯的 agent。
而是犯錯時，仍然被關在可承受邊界內的 agent。
延伸閱讀
- Microsoft RAMPART 與 Clarity：AI Agent 安全開始進入 CI 測試
- AI browsing agents 安全風險：當 AI 能操作瀏覽器，企業要補上的不是 bot 管理，而是工作現場治理
- Claude Compliance API 上線：企業 AI 從能用，走向能稽核、能調查、能治理
- AI Coding Agent 太熱心也是風險：Overeager 研究揭露善意任務中的越界行動