沙箱切邊界這件事，我之前確實想得太粗了

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%，但我比較安心。