當我們在開發 AI Agent（人工智慧代理人）時，最容易陷入的誤區是認為只要在 System Prompt（系統提示詞）中告訴 AI 不要做壞事，或者在執行危險操作前跳出一個確認視窗讓使用者點擊同意，就能確保安全。然而，Anthropic 最近分享的技術細節告訴我們：對於具備執行能力的 AI 來說，依賴模型自身的行為控制或使用者的主觀判斷是非常危險的。
真正的安全應該建立在確定性的環境限制上。這意味著我們不能問 AI 是否應該訪問某個檔案，而應該從基礎設施層面讓它根本無法觸及該檔案。
模型行為的機率性與環境控制的確定性
Anthropic 將 AI Agent 的風險來源分為三類：使用者的惡意濫用、模型本身的行為失控，以及透過外部檔案或網路內容傳入的攻擊。
這裡有一個核心概念：模型是機率性的（Probabilistic）。無論是透過分類器（Classifiers）過濾、調整提示詞還是強化學習，模型產出的結果永遠存在機率誤差。因此，模型層級的防護只能影響行為，不能保證結果。
相對地，執行環境（Execution Environment）是確定性的（Deterministic）。如果我們將 AI 關在一個沒有網路權限的沙箱中，無論 AI 想要如何嘗試外洩資料，在物理層面上這件事就是不可能發生的。
針對不同產品場景的隔離策略
針對不同的產品形態，Anthropic 採取了三種不同強度的隔離方案，這對工程師設計 Agent 權限具有很高的參考價值。
首先是 Web 端（Claude.ai）。由於這是完全由雲端控制的環境，它使用了 gVisor 容器。gVisor 是一種輕量級的虛擬化執行環境，能將應用程式與主機核心隔離。在這裡，代碼執行是在臨時的隔離環境中完成，完全無法訪問使用者的本地檔案系統。
其次是開發者工具（Claude Code）。這類工具運行在開發者的本地機器上，權限要求較高。最初，Anthropic 嘗試使用權限提示（Permission Prompts），要求使用者在寫入檔案或執行指令前手動同意。但實務發現，使用者對 93% 的請求都會直接點擊同意，這導致人為審核幾乎失效。
為了修正這個問題，他們引入了作業系統層級的沙箱（OS-level Sandbox），在 macOS 上使用 Seatbelt，在 Linux 上使用 bubblewrap。這種做法將權限限制在特定的工作空間內，並預設禁用網路訪問。結果是權限提示減少了 84%，且安全性大幅提升。
最後是針對一般用戶的 Claude Cowork。由於這類用戶通常缺乏審核 Shell 指令的能力，防禦強度最高。它將代碼執行完全隔離在虛擬機（VM）中，僅將必要的工作空間掛載進去，而敏感的憑證則保留在宿主機的鑰匙鏈（Keychain）中。
信任邊界與允許清單的陷阱
在實作過程中，Anthropic 遇到了兩個關鍵的安全性教訓，這對所有開發 Agent 的工程師來說都非常重要。
第一個教訓是關於信任邊界（Trust Boundaries）。在 Claude Code 的早期版本中，系統會在使用者同意信任該資料夾之前，就先解析資料夾內的設定檔。攻擊者可以利用這一點，在設定檔中定義一個啟動鉤子（Hook），在使用者還沒點擊同意前就執行惡意代碼。這告訴我們：在使用者正式授予信任之前，絕對不能解析或執行任何來自外部環境的配置。
第二個教訓是關於允許清單（Allowlist）的誤區。在 Cowork 的設計中，系統允許 AI 訪問 api.anthropic.com 這個域名。然而，攻擊者發現可以利用這個漏洞，透過 Anthropic 自己的 Files API 將工作空間的檔案上傳到攻擊者的帳號中。
這證明了允許清單並非絕對安全。允許訪問一個域名，就等於允許訪問該域名下所有的功能接口。為了修復此問題，Anthropic 在虛擬機內加入了代理伺服器（Proxy），強制要求請求必須攜帶特定的會話令牌（Session Token），並封鎖伺服器端抓取標頭，確保請求僅限於授權的會話。
總結：安全設計的優先順序
對於 AI Agent 的安全設計，我們應該遵循一個簡單的原則：不要依賴 AI 認出惡意意圖，而要限制惡意動作能造成的最大損害。
安全防禦的層級應該是：環境隔離（沙箱/虛擬機）大於 確定性限制（網路/檔案權限）大於 權限提示（使用者確認）大於 模型控制（提示詞/分類器）。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。