憑證不進 sandbox，就無法外洩：拆解 Anthropic 跨產品的沙箱架構

多數沙箱產品的通病是文件含糊，讓使用者根本無從判斷該給它多少信任。Anthropic 最近公開了一份少見的詳細說明，把 Claude.ai、Claude Code 和 Cowork 三個產品各自怎麼做隔離說清楚了。對於正在自建 agent 的工程師，這份文件的含金量不在於「學 Anthropic 跟進」，而在於它把幾個在產品決策中很容易被跳過的問題強迫攤開來講。

三個產品對應三種架構，反映的是威脅模型與可用性之間的現實權衡。Claude.ai 跑在雲端，採用 gVisor，在使用者空間攔截系統呼叫，提供核心層隔離但不需要起整台 VM，適合大量短期對話。Claude Code 跑在使用者本機，macOS 用 Apple 的 Seatbelt、Linux 用 Bubblewrap，這是 OS 原生的程序沙箱，能限制檔案系統存取範圍和網路出口，但仍在宿主核心上執行。Cowork 是持久性多工作階段環境，直接拉起完整 VM，macOS 上走 Apple Virtualization framework，Windows 走 HCS，隔離強度最重，運算成本也最高。

選擇哪一層不是技術品味問題，是對「最壞情況下損失邊界」的商業判斷。

Anthropic 整套設計的核心原則只有一句話：憑證不進 sandbox，就無法外洩。不管是使用者失誤、模型自己走出非預期路徑，還是攻擊者透過 prompt injection 控制模型行為，只要 credentials 在執行環境邊界之外，攻擊者就沒有東西可以帶走。這個思路把安全責任從「模型行為要可預期」移到「架構設計要讓最壞情況無害」，是防禦縱深的正確層次。

但文件裡最有教育意義的部分是他們自己踩過的洞：`api.anthropic.com/v1/files` 這個外洩向量。即使 egress 控制鎖得很緊，只允許連到已知的信任端點，這些端點本身也可能成為資料外洩的管道。Files API 設計用來上傳檔案，攻擊者或被 jailbreak 的模型可以把沙箱內的敏感資料偽裝成「要上傳的檔案」推出去。白名單裡有能攜帶任意 payload 的 API，等於開了後門而不自知。

對正在自建 agent 系統的工程師，這裡有幾個直接可用的操作框架：

第一，egress 白名單要做到 API + method + payload schema 三層，光管 hostname 是不夠的。能上傳任意 blob 的端點（包含你自己的 object storage）都要特別對待。

第二，決定 sandbox 層級之前先回答：這個 agent 執行時能碰到什麼憑證？如果答案是「production DB 的 read key」或「用戶的 OAuth token」，那 Seatbelt/Bubblewrap 級別的隔離可能不夠，VM 邊界更乾淨。

第三，檔案系統邊界要在 agent 拿到工作前就劃定，而不是在 agent 執行中動態調整。運行時的存取控制容易被繞過，靜態的掛載點限制更可信賴。

Anthropic 同時有開源的 srt（Sandbox Runtime）工具，這份文件讓它值得重新評估。若你的 agent 基礎設施仍停留在「相信模型不會亂來」這個假設上，現在是認真補課的時機。