5 月 27 日 Anthropic 丟出一份 36 頁的電子書，標題叫《Zero Trust for AI Agents》。這不是一般的行銷白皮書——它給了具體的架構、實施路徑和威脅分類，而且每條建議都對應到成熟度等級，讓你知道自己該做到哪一層。

我把重點整理出來，順便加上我自己在用 Claude Code 和各種 Agent 工具時踩過的坑。

為什麼現在要談 Agent 安全

先說結論：AI Agent 跟傳統軟體最大的差別，是它會自己做決定。

傳統軟體執行你寫好的邏輯。Agent 不一樣，它解讀目標、選擇工具、執行多步驟操作，全程不需要你點頭。這帶來一個根本性的安全問題——你給它的權限，它會用自己的判斷去使用。

Anthropic 在文件裡點出了五個 Agent 特有的安全考量：

  1. 自主執行：不用人工批准就能完成整條工作流程
  2. 工具存取：能操作 API、資料庫、檔案系統、MCP 伺服器
  3. 決策模糊性：人類覺得無害的指令，Agent 可能解讀出完全不同的結果
  4. 跨 session 記憶：記住上次對話的偏好和知識——也記住被注入的毒
  5. 多 Agent 協作：Agent 之間的信任關係，讓攻擊者可以從一個跳到另一個

我自己有過一次經驗：某個 Agent 工作流裡，一個只該讀取資料的 sub-agent 被傳了上層 agent 的完整存取權限。不是惡意攻擊，只是開發時圖省事沒做權限隔離。但如果那是生產環境，任何一個 prompt injection 都能順著這條鏈拿到所有東西。

五種你該知道的 Agent 威脅

Anthropic 整理了 OWASP 識別出的 Agent 威脅。每一種我都見過至少一個真實案例或研究報告。

Prompt Injection：最老但最難防

分直接和間接兩種。直接的是使用者自己輸入惡意指令；間接的更陰險——把惡意指令藏在網頁、郵件、文件裡，Agent 在處理外部資料時自動執行。

微軟研究院（Greshake et al., 2023）明確指出：LLM 無法可靠地區分「資訊」和「指令」。另一篇研究（Zou et al., 2023）則發現，演算法產生的 adversarial suffix 在多個模型家族上達到接近 100% 的攻擊成功率。

Tool Poisoning：信任的工具背叛你

這個比 prompt injection 更實際。攻擊者篡改 MCP 工具的描述、schema 或 metadata，Agent 根據假的能力描述去呼叫工具，導致意料之外的動作。

第一個被記錄在野外的惡意 MCP 伺服器，偽裝成合法的郵件服務，暗中把所有發出的郵件複製了一份。

還有一種更隱蔽的：Tool Chaining 攻擊。攻擊者不碰任何一個單獨的工具，而是騙 Agent 把合法工具串在一起——用 CRM 工具讀客戶資料，再用郵件工具發出去。每個指令都走的信任路徑，host 層的監控看不到任何惡意軟體。

記憶投毒：一次注入，永久生效

Agent 的跨 session 記憶被植入惡意指令後，不只影響當次對話，而是所有後續 session。攻擊者只要成功一次，Agent 就會持續為攻擊目標服務。

RAG 投毒也是同一個邏輯——往向量資料庫裡塞毒資料，Agent 查詢時自動撈出來。

權限繼承與帳號共用

實務上最常見的問題其實不是什麼精密攻擊——是多個 Agent 共用同一個 service account。攻破一個就等於攻破全部，而且你根本分不清是哪個 Agent 做的。

另一種狀況是 manager agent 派任務給 worker 時沒做 scoping，worker 直接繼承了 manager 的完整權限。在多 Agent 系統裡，信任關係是動態且隱式的，一個被攻破的低權限 Agent 可以透過看似合法的指令讓高權限 Agent 代為執行——經典的 confused deputy 問題。

供應鏈風險：模型本身可能就有後門

Anthropic 自己的研究（Hubinger et al., 2024）顯示，往訓練資料裡注入 250 筆惡意文件，就能在 6 億到 130 億參數的 LLM 裡植入後門——而且這些後門在 SFT 和 RLHF 之後依然存在。

三層零信任架構

Anthropic 把防禦措施分成三個成熟度等級，每一層疊加在上一層之上：

等級 定位 適合誰
Foundation 最低可接受安全姿態 小團隊、初始部署
Enterprise 多數組織的目標 有規模的正式部署
Advanced 高風險場景基線 金融、醫療、政府

Anthropic 自己也說，隨著威脅演化，今天的 Advanced 會變成明天的 Enterprise，Enterprise 會變成 Foundation。門檻只會往上升。

重點一：Agent 身份必須密碼學綁定

不是給個字串 ID 就夠了。Foundation 層就要求每個 Agent 實例有獨立的密碼學識別——能簽章、能驗證、能追蹤。

Enterprise 層用 X.509 憑證，Advanced 層把憑證綁到 HSM 或 TPM 硬體上。

做法 風險
❌ agentId = "agent-customer-service-01" 字串標籤 任何人都能偽造，無法做 non-repudiation
✅ 密碼學金鑰對 + 每次請求簽章 身份偽造在數學上不可行
✅✅ X.509 憑證 + HSM/TPM 硬體綁定 即使主機被攻破，金鑰也無法匯出

重點二：靜態 API Key 已經不合格

原文寫得很直白：「Static API keys and shared service-account passwords are among the first things an attacker with model-assisted code analysis will find. Treat them as already-compromised.」

Foundation 層的新基線是短期 token + 自動 refresh。不是「API key 定期 rotate」——rotate 一個可以被 grep 出來的 credential，對 AI 輔助的攻擊者來說沒有意義上的成本增加。

重點三：「麻煩」不等於「安全」

文件裡有個設計測試我覺得非常精準：

問一個問題：這個控制措施是讓攻擊不可能，還是只是麻煩？

Rate limit、非標準 port、多跳轉——這些對人類攻擊者有用，對 Agent 攻擊者沒用。Agent 有無限耐心和接近零的每次嘗試成本。能活下來的控制措施有個共同模式：硬體綁定的 credential、會過期的 token、密碼學身份、不存在的網路路徑（而不是存在但不方便的路徑）。

重點四：最小代理權（Least Agency）

OWASP 新造的詞。比最小權限更進一步——不只限制能存取什麼，還限制每個工具能做什麼、多頻繁、在哪裡。

1
2
3
4
5
6
7
✅ 資料庫工具：唯讀查詢
✅ 郵件工具：只能讀和摘要，不能發送和刪除
✅ API 工具：最小 CRUD 操作

❌ 「這個 Agent 負責客服」（太模糊）
❌ 所有 Agent 共用同一個 service account
❌ Worker agent 直接繼承 manager 的全部權限

八階段實施流程

Anthropic 不只講原則，還給了一條具體的實施路徑。完整八階段是：

  1. 識別需求 → 2. 管理供應鏈風險 → 3. 定義 Agent 邊界 → 4. 防禦 Prompt Injection → 5. 工具存取安全 → 6. 保護 Agent 憑證 → 7. 記憶安全 → 8. 衡量指標

Phase 1-2 偏流程治理（盤點法規要求、做 AI-BOM、評估依賴健康度），Phase 6 跟前面的 token/憑證段落高度重疊，Phase 8 講 dwell time 和 coverage 指標。我挑四個對開發者最直接有用的展開：

Phase 3：定義 Agent 邊界

這是最容易被跳過、但最關鍵的一步。

  1. 列出批准的動作清單（不是「幫忙處理客服」這種模糊描述）
  2. 列出禁止的動作清單
  3. 定義升級觸發條件——什麼情況要暫停等人類審核
  4. 限定存取範圍——客服 Agent 不需要碰 HR 系統
  5. 算出爆炸半徑——如果這個 Agent 被攻破，最壞能造成多大的損害

算完爆炸半徑之後，拿「不可能 vs 麻煩」的測試再過一遍。如果你的防護計畫靠的是「攻擊者要發很多請求」或「要繞過好幾個 rate limit」——在 Agent 攻擊者面前，這些等於零。

Phase 4：防禦 Prompt Injection

三個手段疊加使用：

  • Input Isolation：所有自然語言輸入視為不受信任。微軟的 Spotlighting 技術用 schema 把系統指令和使用者輸入明確區隔，把間接注入的成功率從 50% 以上壓到 2% 以下
  • Constitutional Classifiers：Anthropic 自家研發的 AI 分類器，專門偵測操控企圖。官方測試裡擋住了 95% 的 jailbreak，而且不會大幅增加誤拒率
  • 縮小攻擊面：限制誰能跟 Agent 互動。能限定到受信任人員和資源的話，大部分問題直接消失

Phase 5：工具存取安全

每個工具要有 allow-list，未列入的一律拒絕。工具認證不能用靜態 API key——要用憑證認證或跟 Agent 身份綁定的短期 token。

參數驗證要做兩層：Agent 端驗一次，工具端驗一次。

Phase 7：保護 Agent 記憶

  • Session 隔離：一個對話的資訊不能影響另一個
  • 完整性驗證：每次讀取記憶時用 hash 檢查有沒有被竄改
  • 保留策略：高風險的 context 要有 TTL，不能永久存在

別只防輸入——輸出也要管

文章前半大量篇幅在講輸入端（prompt injection、工具投毒），但 Anthropic 框架裡同樣強調 output controls。邏輯很簡單：就算 Agent 被操控了，如果輸出端有攔截，資料也出不去。

Foundation 層：掃描輸出裡的 PII、credential 等敏感模式，命中就遮蔽或阻擋。Enterprise 層：語意分析——偵測試圖把敏感資料用編碼方式藏在回應裡的行為。Advanced 層：高風險操作（發信、寫入外部系統）需要 human-in-the-loop 核准。

另外，原文還有一整段在講 Compliance 對齊（HIPAA、FINRA、GDPR、FedRAMP、EU AI Act），這部分偏 CISO/GRC 視角。對開發者來說，先把 audit log 做好、資料分級做對、權限變更有紀錄，就已經覆蓋了大部分合規要求的技術基礎。

防禦運營：你的 SOC 跟得上 Agent 攻擊者的速度嗎？

文件最後一個 Part 我覺得是給 CISO 看的，但有一個觀點對開發者也很重要：

自動化處理文書工作，不是自動化決策。模型負責記筆記、蒐集證據、追蹤調查線索、起草事後報告。人類負責做封鎖決定、披露決定、客戶溝通決定。

Anthropic 建議的起步方式很務實：先挑一條誤報率最高的告警規則，接上一個有唯讀 SIEM 權限的 triage agent，跑兩週看跟人類審查員的判斷一致性。不要一次自動化整個佇列。

另一個建議：桌面推演別只模擬一個事件——模擬五個同時發生。當漏洞利用的時間從數月壓縮到數小時，你的回應流程要能承受同時處理多起事件。

讀完之後我的判斷

這份文件最大的價值不在於告訴你「要做零信任」——這個大家都知道。價值在於它把 Agent 特有的安全問題（跟傳統軟體不一樣的那些）系統化地梳理出來，並且給了可操作的分級建議。

不過有幾點我覺得值得注意：

這終究是 Anthropic 的行銷文件。 每個 chapter 都有「Pro-tip: Claude Code supports this by...」。他們推的是自家的 Claude Security 產品。框架本身是通用的，但要帶著這個意識去讀。

Foundation 層的門檻被拉得很高。 密碼學身份、短期 token、身份隔離、自動化初步分診——這些現在是「入門要求」而不是「目標狀態」。對很多中小團隊來說，光 Foundation 就需要不少工程投入。

最關鍵的其實是 Phase 3。 那些花俏的密碼學和硬體安全模組固然重要，但多數安全事件的根因是權限給太大、邊界沒定義清楚。先把「這個 Agent 能做什麼、不能做什麼、出事了爆炸半徑多大」寫清楚，比什麼都管用。

下次我在 Agent 工作流裡加新工具的時候，至少會多問自己三個問題：這個工具需要的最小權限是什麼？token 會不會過期？如果這個 Agent 被注入了，它最遠能摸到哪裡？

原文連結：Zero Trust for AI Agents（含 36 頁 PDF 下載）