上一篇討論了 Agent 怎樣通過非預期路徑取得測試答案。放到真實工作裏，同樣的問題會更加具體：它為了完成任務，可能讀取不該讀取的文件，修改範圍之外的數據，或者把資料發送給錯誤的接收方。
Agent 安全因此需要同時回答兩個問題：怎樣減少錯誤行動，以及錯誤發生後，怎樣限制它能造成的影響？ 前者關注判斷，後者關注權限。模型更善於理解意圖，並不自動意味着它應該獲得更大的訪問範圍。
Anthropic 的《How we contain Claude across products》把行為監督與 Containment（限制實際行動能力）放在一起討論。本文沿着風險來源、控制方式、資源邊界和運行環境四個層次，整理一套理解 Agent 安全的框架。
貫穿説明採用一個假設場景：用户讓 Coding Agent 修復項目中的 CSV 解析問題，允許它修改項目、運行測試，並讀取必要的開發文檔。這個任務不需要訪問個人憑證，也不需要上傳項目資料。下面的權限安排是教學示例，不是對當前電腦配置的描述。
一、Agent 的安全風險來自哪裏h2
Agent 會把讀到的信息轉成行動，而行動會經過工具作用於真實系統。因此，安全分析不能只檢查模型最後説了什麼，還要沿着“信息從哪裏來、動作由誰提出、實際使用什麼權限”追蹤。
1. 風險來源：用户誤用、模型偏離與外部攻擊h3
原文區分了用户誤用、模型不當行為和外部攻擊。它們都可能產生有害動作，但進入系統的位置不同，防禦也不能只盯着其中一種。來源：Anthropic
用 CSV 修復任務解釋：
| 風險來源 | 場景中的表現 | 需要關注什麼 |
|---|---|---|
| 用户誤用 | 用户粘貼一份來歷不明的排障步驟，其中包含讀取個人憑證的要求 | 用户發來的內容是否真的符合任務目的 |
| 模型偏離 | Agent 為了讓測試通過，擅自刪除失敗用例或大範圍清理文件 | 自主選擇的動作是否越出任務範圍 |
| 外部攻擊 | 開發文檔混入指令，誘導 Agent 上傳項目資料 | 不可信內容是否被當成了操作授權 |
外部攻擊也不只有 Prompt Injection。執行惡意腳本、利用 Runtime 缺陷、攻擊代理或工具服務，仍然屬於傳統軟件安全問題。Agent 增加了“內容影響決策”的路徑，並沒有替代原來的攻擊面。
三種風險還可能連在一起。攻擊者把指令包裝成排障指南，用户再把指南交給 Agent，表面上就像用户親自提出的要求。僅判斷“這句話是不是用户發來的”，不足以證明動作安全。
2. Blast Radius：錯誤概率與影響範圍h3
Blast Radius 可以理解為一次失誤或攻擊能夠波及的範圍。對 Agent 來説，它與可訪問的數據、可修改的資源、可使用的身份，以及可到達的服務有關。
假設兩個 Agent 同樣把一條惡意文檔當成指令：
- 一個只能處理臨時項目副本，拿不到個人憑證，也不能任意訪問網絡。
- 另一個繼承開發者的廣泛權限，能讀取家目錄，並使用生產服務憑證。
兩者都發生了判斷錯誤，後果卻可能完全不同。第一個仍可能破壞副本中的代碼；第二個的影響還可能越出項目，涉及其他資料和服務。
所以風險需要沿兩個方向控制：減少錯誤發生的可能性，也縮小錯誤能夠觸及的資源範圍。 模型升級主要改善判斷，不會替我們自動收回過寬的文件權限或憑證。
安全邊界的設計由此有了一個明確目標：先確定任務需要什麼能力，再把不需要的能力留在邊界之外，而不是先開放全部權限，再期待每一步都判斷正確。
二、行為監督與環境隔離怎樣分工h2
這兩種控制回答不同問題。行為監督判斷“這次動作應不應該做”；環境隔離規定“這個執行通道實際上能做什麼”。它們可以配合，但不能互相替代。
3. Human Oversight：審批動作與注意力成本h3
人工審批有價值，因為用户可以確認任務意圖和重要取捨。例如，運行項目測試與把整個目錄發送到外部服務，顯然不該只用一句“為了排障”來概括。
問題在於，審批本身需要時間、信息和專業判斷。複雜命令可能隱藏多個動作；不斷彈出的低風險請求，又容易讓用户把確認變成習慣操作。
Anthropic 在原文中報告，Claude Code 用户批准了大約 93% 的權限提示，並討論了 Approval Fatigue（審批疲勞）。這個比例不意味着 93% 的動作有風險，也不能單獨證明用户都沒有認真看；它提醒的是：提示出現，不等於有效監督已經發生。 來源：原文的監督討論
在示例任務裏，如果讀取項目文件、執行常規測試都需要反覆確認，真正重要的“讀取項目外憑證”請求反而可能淹沒其中。更合理的分工，是先為日常工作劃定受限範圍，把人工注意力留給清晰、具體的例外。
自動分類器可以承擔部分判斷，但它也可能漏判。審批來自人還是模型，會影響判斷方式，不會改變一個事實：只要執行權限本身沒有限制，判斷放行之後的影響仍然可能很大。
4. Containment：限制實際可執行的能力h3
Containment 不要求 Agent 每次都同意安全規則，而是在執行層約束文件、進程和網絡等能力。比如，進程嘗試讀取未授權文件時，由權限機制拒絕，而不是再讓模型解釋一次為什麼不該讀。
在 CSV 場景中，可以為任務準備一個受限工作區：允許修改項目副本和啓動測試，不提供個人憑證，不開放任意網絡出口。即使模型被文檔帶偏，它也不應因此獲得新的資源訪問權。
這與在 Prompt 中寫“不要碰其他目錄”不同。Prompt 影響動作選擇；執行邊界檢查真實動作。一個解釋聽起來合理的請求，也仍然可能被邊界拒絕。
圖中的邊界有效，有一個具體前提：真實執行必須經過這些檢查。若 Shell 被限制，另一個高權限工具卻能代為讀取文件或發請求，權限只是換了入口，並沒有消失。
同樣，Containment 不等於任務結果正確。Agent 仍可能在允許的項目內寫壞代碼。它控制的是可觸及範圍；代碼審查、測試和恢復機制負責另一部分問題。
三、安全邊界需要覆蓋哪些資源與信息h2
“放進 Sandbox”只是一個起點。要説明邊界實際保護了什麼，需要把資源、訪問方式和跨界通道拆開。
5. 資源權限：文件、進程、網絡與憑證h3
對示例任務，可以按下面幾個維度檢查能力是否超出需要：
| 維度 | 應明確的邊界 | 只檢查一半會遺漏什麼 |
|---|---|---|
| 文件 | 哪些可讀、可寫，工作區外哪些不可見 | 禁止寫入，不代表敏感內容不能被讀取 |
| 進程 | 可以啓動什麼，子進程如何受約束 | 主入口受限，派生程序卻擁有更大權限 |
| 網絡 | 可訪問哪些服務、執行什麼操作 | 不能寫本地文件，仍可能把資料向外發送 |
| 憑證與身份 | 暴露哪些授權，能操作哪些賬號和資源 | 受限進程持有高權限憑證，仍可影響遠程系統 |
| 宿主機接口 | 掛載目錄、連接器和本地服務怎樣暴露 | 環境看似隔離，卻通過額外接口訪問宿主資源 |
這幾個維度互相影響。例如，限制文件寫入能保護項目外的數據完整性，卻不一定保護機密性。只讀訪問允許資料進入 Agent 的處理過程；如果網絡出口又很寬，資料仍可能被髮送出去。
網絡權限也不能只理解成“域名是否可信”。Anthropic 報告過一個案例：允許的服務域名接收了使用攻擊者憑證上傳的文件。域名檢查通過，數據卻進入了錯誤賬號。來源：原文的出口控制案例
由此可以理解，訪問一個服務實際上授予了一組能力。評審時應繼續問：這次允許的是查詢文檔，還是上傳文件？使用誰的身份，進入哪個賬號，處理哪些數據？域名只是其中一項條件。
6. 內容信任：工具可信與返回內容可信h3
一個工具實現可靠，不意味着它取回的每份內容都可以成為指令。瀏覽器可以正確打開惡意網頁，倉庫工具可以準確讀取被投毒的 README。工具沒有出錯，內容仍然可能試圖改變 Agent 的目標。
在 CSV 場景中，文檔可以告訴 Agent 某個庫怎樣解析引號，但不能因為文檔寫了“排障必須上傳完整目錄”，就自動獲得用户授權。內容的參考價值與行動授權是兩種不同角色。
同一原則也適用於項目配置和腳本。打開一個陌生項目、讀取配置、運行初始化代碼，分別涉及不同信任程度；不能等不可信代碼已經執行之後，才詢問用户是否信任目錄。
如果資料經過子 Agent 摘要返回，它的來源性質也不應因此提高。否則，原本不可信的要求可能以“同事 Agent 的建議”重新進入主流程，掩蓋了最初來自外部文檔的事實。
內容掃描、清楚的指令層級和來源標記可以幫助減少誤用；環境權限則在誤用發生時限制後果。這正是兩層控制需要共同存在的原因。
四、不同運行環境怎樣組合安全控制h2
同樣的任務能力，放在遠程臨時環境與開發者本機上，涉及的數據、身份和監督條件並不相同。隔離方案應當圍繞這些差異設計。
7. 隔離模式：臨時容器、本地 Sandbox 與 VMh3
原文以三類產品説明這種取捨。下面概括的是該文發佈時的架構背景，不是所有 Agent 產品都應採用的固定方案：
| 環境案例 | 主要隔離思路 | 對安全模型的啓發 |
|---|---|---|
| claude.ai 代碼執行 | 服務端、按會話使用的臨時容器 | 限制執行環境接觸本地機器，並處理租户間隔離 |
| Claude Code | 本地 Sandbox 與審批配合 | 保留開發所需能力，同時減少範圍內的重複干預 |
| Cowork | VM 承載受限代碼執行，暴露選定工作目錄 | 降低對用户判斷複雜命令的依賴，明確宿主資源入口 |
產品案例來自 Anthropic 原文。原文也描述了 Cowork 將 Agent Loop 移到 VM 外、保留 VM 內代碼執行的演進，本地 MCP 服務另有宿主機信任邊界。因此，“使用 VM”不能簡化成“所有組件都在 VM 內”。
臨時環境的價值是減少跨會話殘留和暴露範圍，不是讓所有副作用都自動撤銷。文件一旦被導出、上傳，或者遠程服務已經發生變更，銷燬容器不會把這些結果一起收回。
VM 也不是對工作目錄的全面保護。如果用户把重要資料以可寫方式掛載進去，Agent 仍然可能修改它們。邊界保護的是沒有暴露的部分；掛載進來的內容還需要相應的讀寫策略與恢復安排。
選擇方案時，還要考慮用户是否有能力監督例外。能讀懂命令的開發者與只希望整理文件的普通用户，不應承擔同樣的審批負擔。安全性、必要能力和可理解的操作體驗，需要共同決定邊界。
8. Defense in Depth：模型、環境與內容的協同防禦h3
縱深防禦不是把幾個安全功能依次打開，而是給不同控制分配清楚職責：
- 模型與行為判斷： 理解任務，識別可疑要求，減少越界動作。
- 環境與權限控制： 即使前面的判斷漏過，仍然限制真實訪問與執行。
- 外部內容與工具控制： 限制信息入口和工具能力，避免不可信材料直接升級為授權。
人工監督則負責重要意圖和例外取捨。邊界需要放寬時，應當明確放寬哪項能力、為哪個動作、影響哪些資源，而不是把一次確認變成以後都不再受限。
這幾層並不天然獨立。如果它們都把同一份惡意文檔視為可信，檢查數量再多，也可能一起放行。環境控制之所以重要，是因為它可以依據資源規則拒絕動作，不必重新相信那份文檔的解釋。
但環境機制本身也依賴正確實現。路徑驗證、代理、身份傳遞和高權限例外，都可能成為缺口。“操作系統強制執行”不意味着整個產品的安全設計從此沒有漏洞；需要檢查規則覆蓋了哪些執行入口，以及邊界組件本身是否可靠。
回到項目修復任務，一份基本安全模型應當説清：Agent 能讀哪些材料、修改哪個目錄、啓動哪些程序、使用什麼憑證、向哪裏發送數據，以及誰可以批准例外。最後再問：假設模型和審批都判斷錯了，哪些資源仍然不可觸及？ 這比單獨寫一句“Agent 不應執行危險操作”更接近可檢查的工程邊界。
幾個關鍵問題，串起監督、權限與影響範圍h2
模型更可靠之後，為什麼仍然需要限制權限？
更可靠主要降低錯誤發生的可能性，不會自動縮小既有訪問範圍。一次少見失誤若能使用高權限憑證，後果仍可能很大。判斷質量與權限範圍需要分別控制。
有人工審批，為什麼不能認為動作已經安全？
審批取決於用户看到了什麼、能否理解，以及是否保持注意力。它可以確認重要取捨，但不能替代實際權限檢查，也不能證明一次批准覆蓋了所有隱藏副作用。
Sandbox 內允許執行，就代表動作符合任務目的嗎？
不代表。Sandbox 判斷的是技術權限，任務目的仍需要模型、規則和監督來約束。在可寫目錄內刪除測試，可能沒有越過文件邊界，卻仍然違背修復任務。
只允許讀文件，是否已經避免資料泄漏？
沒有。只讀保護寫入行為，不阻止內容被讀取。還需要看資料是否應當暴露，以及工具、網絡和憑證是否允許把它發送到其他地方。
工具經過審核，為什麼返回內容還要保持較低信任？
實現可信與數據可信是兩回事。經過審核的搜索或倉庫工具仍可能返回攻擊者控制的文本；這類文本可以用於研究，不能自行授予新的行動權限。
使用 VM 或臨時容器，是否就沒有剩餘風險？
不是。掛載目錄、允許的服務、暴露的憑證，以及 VM 外的連接器仍可能產生影響。隔離環境需要明確覆蓋範圍；環境內的破壞和已經發往遠程的副作用也不會憑空消失。
縱深防禦最重要的檢查是什麼？
不是有多少層提示，而是每層保護什麼、由誰執行，以及一層失敗後其他層是否仍然有效。尤其要確認，所有真實動作都經過了相應的資源邊界，而沒有高權限旁路。