Anthropic 如何在不同產品裡圍住 Claude？一篇看懂代理式 AI 的隔離設計

原文連結：https://www.anthropic.com/engineering/how-we-contain-claude

文章說明

這是一篇由 Anthropic 工程團隊撰寫的技術長文，分享他們如何在 claude.ai、Claude Code 與 Claude Cowork 三種產品中設計 containment。文章重點不是抽象安全原則，而是把實際踩過的洞、錯失的風險，以及最後採用的隔離架構講得非常具體。

內容介紹

作者一開始先把代理式 AI 的風險分成三類：使用者誤用、模型自行做出危險行為，以及外部攻擊者透過工具、檔案或網路輸入進行利用。對應這些風險，Anthropic 主張防線不能只放在模型層，而要同時看三個面向：模型本身、代理所執行的環境，以及代理可以讀到的外部內容。

文章最有價值的部分，是把三種產品拆成三種不同 containment pattern。claude.ai 的程式執行環境採用短生命週期容器，重點在於把風險控制在服務端的暫時性工作區內。Claude Code 則是典型的本機開發者場景，早期依靠 human-in-the-loop 逐步授權，但很快遇到 approval fatigue，因此後來改採 macOS 的 Seatbelt 與 Linux 的 bubblewrap 進行 OS 級沙箱隔離，讓工作區內寫入被允許、網路預設被拒絕，將授權提示減少了 84%。

Claude Cowork 面對的是較不熟 bash 的知識工作者，所以不能假設使用者有能力判斷每一條指令是否安全。Anthropic 因此採取更強的完整 VM 模式，以宿主機 hypervisor 建出獨立 Linux 環境，僅掛載使用者允許的工作區與設定資料夾，並讓憑證留在主機 keychain，不進入客體系統。這種方式犧牲了一些成本與可觀測性，但把 blast radius 壓得更死。

文章沒有粉飾太平，反而詳細列出幾個他們錯過的風險。例如 Claude Code 曾在「信任這個資料夾」提示之前，就先解析了專案內設定檔，讓惡意 hook 能提早執行。另一個更關鍵的案例，是 Claude Cowork 即使做好網域 allowlist，仍然可能透過允許的 api.anthropic.com 上傳檔案到攻擊者帳戶。這使團隊重新理解 allowlist 不是單純目的地過濾，而是 capability grant。

文章最後總結出幾個工程原則：先從環境邊界設計開始，再用模型層做第二層防護；讓隔離強度匹配使用者是否能有效監督代理；盡量依賴成熟的 hypervisor、seccomp、sandbox runtime，而不是過度自製關鍵安全元件。這些原則對任何想把 agent 放進真實產品的人都很實用。

你可以帶走的重點

1. 對代理式 AI 而言，最可靠的防線通常不是模型，而是環境層的硬邊界。

2. human-in-the-loop 不是萬靈丹，當提示過多時，使用者會很快失去判斷力。

3. allowlist 不只是「可連到哪些網域」，而是「實際授予了哪些能力」。

4. 本機開發者與一般知識工作者的風險模型不同，隔離策略也不應相同。

5. 成熟安全基礎設施通常比自製代理周邊元件更值得信任。

適合誰閱讀

• 正在設計 AI agent、coding agent 或企業內部自動化工具的工程團隊
• 關心代理式 AI 安全、prompt injection 與資料外洩風險的安全人員
• 想理解 Claude Code 與 Claude Cowork 背後產品設計取捨的讀者