Anthropic 前陣子發了一篇關於他們怎麼在不同產品限制 Claude 的文章。技術細節不算多，但選擇架構的邏輯讓我多讀了幾遍。

Simon Willison 整理的重點大概是：Claude.ai 用 gVisor 做容器隔離，Claude Code 在 macOS 用 Seatbelt、Linux 用 Bubblewrap，Cowork 則是直接上完整 VM。同一家公司的三個產品，用了三種不同的沙箱方案，看起來有點亂，但其實有邏輯。

關鍵就一句：把可觸及邊界切乾淨，讓憑證不進沙箱就無法外流。

這句話讓我想起自己之前踩過的一個坑。

---

我之前在本地跑一個自動整理 Notion 的 Agent，用 LangChain 包了一組 tool set。圖方便，直接把 Notion API key 丟進環境變數，讓整個 Python 環境都看得到。測試一切正常。

後來加了「執行網頁搜尋」的功能，讓 Agent 去抓外部資料補進筆記。測試時發現，那個搜尋 tool 有個 bug，會把 environment 裡的所有變數當 context 傳給 LLM 做後續處理。

好在是自用環境，影響範圍有限。但那個當下我意識到：Notion token 差一點就被傳出去了。傳去哪？傳給 OpenAI API。然後 OpenAI API 的 response 有沒有 logging？我不知道。而且這整個過程跟模型行為完全沒有關係，純粹是 tool 的實作問題，是我自己寫的 Python 在正常呼叫流程下觸發的。

---

回到 Anthropic 的做法。他們的架構邏輯是「不預設 Agent 不會犯錯」，然後針對每個產品的風險面去挑方案。Claude Code 直接跑用戶的本地指令，風險最高，所以系統層的 sandbox profile 要夠細。Cowork 操作更複雜的環境，直接上 VM，把整個執行邊界拉到最清楚。

重點不是你用哪個工具，而是你有沒有想清楚你的邊界在哪。

我後來重整了一次自用 Agent 的部署方式：

• 憑證用 .env 管理，但 Agent runtime 只暴露它「應該知道的那幾個」
• 每個 tool 明確聲明需要哪些 permission，不用的不給
• 有外部 I/O 的 tool（搜尋、HTTP call）和有內部存取的 tool（Notion、Calendar）分開跑，不放在同一個 execution context

這個改動讓整個架構多了一點 context switch 開銷，大概慢了 10-15%，但我比較安心。

容易被忽略的事

大多數人討論 Agent 安全的時候，注意力放在「模型會不會做壞事」，像 prompt injection 啦、越獄啦之類的。但執行環境的設計失誤其實可以更直接造成問題，而且完全跟模型行為無關。

Anthropic 這篇文章沒有解決 prompt injection，它解決的是「即使 Claude 被某種方式說服要做壞事，它也動不到它不該動的東西」。這是兩個層的問題，後者更容易被確定地做到。

有在自建 Agent 的人，問自己一個問題：你的 Agent 能存取哪些憑證？它全部都需要嗎？如果某個 tool 的 bug 或一個惡意 prompt 讓它往外送資料，最壞的情況是什麼？

如果答不出來，可能值得重新看一下你的 permission 設計。