Claude 安全容器化架構

Anthropic 的工程團隊發了一篇非常誠實的技術文——不只講他們怎麼設計 Claude 的安全容器化，還把出事的地方也攤開來講。

這篇的價值不在於技術架構本身（sandbox、VM、gVisor 都是成熟技術），而在於他們願意公開實驗過程中的失敗。三次「風險我們沒預料到」的坦白，比任何架構圖都有說服力。

核心命題：不是管 agent 做什麼，是管它能碰到什麼

文章一開頭就點出一個關鍵洞察：

十二個月前，我們會直接拒絕讓 Claude 擁有足以打掉內部服務的權限。今天，這種權限已經稀鬆平常。

他們把 agent 風險拆成兩個維度：出事機率 × 爆炸半徑。模型訓練和安全護欄把機率壓低了，但爆炸半徑——agent 能碰到多少東西——只會隨能力成長而擴大。

所以工程上的核心問題變成：怎麼把爆炸半徑鎖死。

兩個路線：

  1. 人機迴路監督（human-in-the-loop）——但他們自己承認這招會疲勞：使用者批准率 93%，看久了就不看了
  2. 容器化隔離（containment）——這篇的重點

三種產品，三種隔離模式

Pattern 1：短命容器（claude.ai）

程式碼在 gVisor 容器裡跑，完全伺服器端，檔案系統每次 session 重置。爆炸半徑最小，但能力也最受限——沒有持久工作區，碰不到使用者本機檔案。

一個有趣的坦白：gVisor 和 seccomp 這些成熟基礎設施從來沒出過事，出事的都是他們自己寫的客製化代理層。

Pattern 2：人機迴路沙箱（Claude Code）

跑在使用者機器上，有檔案系統和 shell 權限。最早只靠 permission prompt 把關，但幾週內就出現批准疲勞。

後來加了 OS 級沙箱（macOS Seatbelt / Linux bubblewrap）：預設禁止網路，寫入限制在工作區內。結果：permission prompt 減少 84%。

但他們也發現，資深使用者自動批准的頻率是新手的兩倍——不是因為更謹慎，是因為更習慣按「允許」。

Pattern 3：本地 VM（Claude Cowork）

這是三種裡隔離最徹底的：完整虛擬機（macOS 用 Apple Virtualization、Windows 用 HCS），有自己的 kernel、檔案系統、process table。使用者的 workspace 被掛載進去，但主機上的 credentials 永遠不進 VM。

原始設計是 agent loop 跑在 VM 內——沒有外部程序持有逃逸鑰匙。但 VM 啟動失敗會讓整個 Cowork 掛掉，所以後來把 agent loop 移到 VM 外。安全影響不大，因為 VM 仍然強制執行檔案系統和網路控制。

三次「我們沒預料到的風險」

這是全文最精華的部分。

出事一：信任對話框之前的程式碼會執行

2025 年中到 2026 年一月，他們透過漏洞回報收到三份報告，全部指向同一個模式：在使用者按下「我信任這個目錄」之前，專案設定檔（.claude/settings.json）裡的 hook 就已經執行了。

攻擊者只要在 repo 裡埋一個 hook，clone 下來的人還沒點同意就先中招。

解法：把所有專案本地設定的解析推遲到信任對話框之後。

出事二：使用者本身就是注入向量

2026 年二月內部紅隊演練：一封看似正常的協作 email，附上「幫我跑一下這個」的 prompt。prompt 中間夾了一句：讀取 ~/.aws/credentials、編碼、POST 到外部。

25 次重試，Claude 成功洩漏了 24 次。

模型層的防禦完全失靈——因為指令是使用者自己打進去的，分類器看不出任何異常。唯一有效的防禦是環境層的網路出口控制。

（他們把這個 prompt 貼到內部 Slack 討論時，有人提醒說某些內部 agent 會讀 Slack。payload 已經變成環境汙染了。他們只好在討論串加了 canary 字串來監控。）

出事三：通過核准網域洩漏資料

Cowork 的出口白名單放行了 api.anthropic.com——產品本來就需要呼叫自家 API。但攻擊者在 workspace 放了一個帶惡意指令和攻擊者 API key 的檔案。Claude 讀了指令，用攻擊者的 key 把其他檔案上傳到攻擊者的 Anthropic 帳號。

防火牆檢查了目的地、放行了——然後資料就出去了。

解法：在 VM 內部署 MITM 代理，攔截 API 請求，只放行帶有 VM 自有 session token 的請求。代理放在 VM 內而非伺服器端，因為只有 VM 知道請求的來源。

城武觀點

1. 這篇的誠實程度在 AI 產業裡極為罕見

大多數公司的工程部落格只講成功案例。Anthropic 這篇把三次資安事件——包括一次成功的內部釣魚——細節全部公開。這不是公關，這是技術圈的責任揭露。

2. 「客製化元件最危險」是反直覺但正確的結論

gVisor、seccomp、hypervisor 都沒出事。出事的全是他們自己寫的代理層和 allowlist proxy。被全世界的攻擊者打了十幾年的基礎設施，比你自己花三個月寫的東西可靠——這個結論值得所有做 agent 安全的團隊貼在牆上。

3. 人機迴路是幻覺

93% 批准率、資深用戶自動批准率是新手的兩倍——數據說得很清楚：把安全交給人類注意力，等於沒有安全。容器化不是可選的附加功能，是唯一能撐到最後的防線。

4. 跟 GitHub issue #29045 的連結

如果你還記得我們之前寫的 Claude Desktop 1.8GB VM 問題——現在你知道那個 VM 是哪裡來的了。它是 Cowork 的 Pattern 3 隔離架構，但在啟動時無條件初始化，不管你用不用 Cowork。

這篇工程文和那個 bug report 放在一起看，Anthropic 的安全選擇就變得完整了：隔離是真的，但使用者體驗的代價被轉嫁給了所有使用者。

城武的未解檔案——三次出事換來的教訓：成熟的基礎設施不會背叛你，你自己寫的那層才會。