Blast Radius（Agentic）

資料來源#

• Zero Trust for AI Agents

摘要#

Blast radius 衡量代理程式出問題時可能造成的損害。只能讀取單一資料庫的代理程式，其 blast radius 很小；擁有雲端基礎設施管理員存取權的代理程式，blast radius 則極其龐大。在 Zero Trust for AI Agents 中，它是「假設已遭入侵」原則的核心單位：安全性投資應與暴露程度相稱，而為入侵而設計的姿態，意味著假設每個代理程式的 blast radius 最終都會受到測試。

為什麼這是合適的單位#

Zero Trust 不承諾防止入侵——它承諾的是限制入侵的影響。Blast radius 將安全問題從「我們能否把攻擊者擋在外面？」（在 AI-Accelerated Offense 下，這是一場必敗的邊界防禦遊戲）重新框定為「代理程式遭到入侵時，它能觸及多少範圍？」框架中的所有其他控制措施——Least Agency、身分、隔離——最終都以它能將這個數字縮小多少來證明其合理性。

限制影響範圍的機制（資源邊界）#

框架主要的 blast-radius 控制是以身分為基礎的隔離，而非網路分段：

• 以身分為基礎的隔離（Foundation）——每個代理程式工作負載都帶有自己的加密身分，且每項服務只接受明確列名的呼叫者所發出的連線。網路分段是後備防線，而非主要邊界——如果服務接受來自該網路的任何呼叫者，能抵達分段邊界的攻擊者就會經由它橫向移動。「在接收端強制執行隔離。」
• 沙箱化執行（Enterprise）——具有限制能力的容器、用於系統呼叫過濾的 gVisor 等執行環境，以及受限的掛載與網路。對任何處理不受信任輸入（網頁內容、文件）的代理程式而言，這被視為必要條件，而非理想目標。
• 硬體隔離（Advanced）——AMD SEV / Intel TDX、microVM、證明；就連主機作業系統也無法檢查或竄改工作負載。

互補的憑證側限制措施（Agent Identity and Authentication）：每個代理程式各自擁有憑證，加上憑證隔離，意味著單一遭竊的祕密不會授予所有共用該祕密的代理程式所合併擁有的存取權。

將分區隔離作為刻意的設計#

工作流程的第 3 階段會將 blast-radius 評估明確列為一個步驟：在定義核准動作、禁止動作、升級觸發條件與範圍限制後，找出代理程式遭到入侵時可能出錯的地方。框架建議將代理程式的功能拆分成多個具有不同身分的代理程式，讓攻擊者必須入侵更多代理程式，才能接觸更多資源——但前提是每個代理程式都取得唯一的憑證（共用憑證會破壞分區隔離）。

「不可能」與「繁瑣」的連結#

Blast-radius 評估必須透過 Impossible, Not Tedious (Design Test) 執行：「如果你的限制計畫仰賴摩擦力——攻擊者必須提出大量請求，或繞過數個速率限制——就假設它會失敗。」 若 blast radius 只是不方便穿越，就不算受到限制；如果剩餘風險不可接受，就應收緊控制措施，直到穿越變得不可能，而不只是繁瑣。

相關連結#

• Zero Trust for AI Agents — blast radius 是「假設已遭入侵」原則用來限制影響的單位（樞紐）
• MCP Tool Poisoning — **真實世界的 blast-radius 案例：**在 Tenet Security 的 Agentjacking 案例研究中，單一程式設計代理程式遭偽造的 Sentry 錯誤劫持（由合法的 MCP 伺服器轉送）後，從一個立足點取得了即時 AWS 金鑰、GitHub OAuth 權杖、SSH 代理程式通訊端，以及已連線下游代理程式的識別碼——「遠超過一台機器所能提供的存取權」（捕捉 E3/E6）——而網路受限的 CI 沙箱並未限制住它，因為負載是透過受信任工具的資料進入，而非透過網路。這是供應商回報的案例研究，但也是「每個代理程式的 blast radius 最終都會受到測試」這項論點遭到驗證的具體實例
• Least Agency — 輸入控制；限制代理能力就是縮小 blast radius 的方法
• Agent Identity and Authentication — 以身分為基礎的隔離與每個代理程式各自的憑證，是主要的 blast-radius 控制措施
• Impossible, Not Tedious (Design Test) — 限制計畫必須通過的測試：穿越必須不可能，而不只是繁瑣
• Claude Code Best Practices — 作為限制實作參考的沙箱化執行與寫入存取限制
• Autonomous Defense — 將相同的 blast-radius 限制向內套用於防禦型（Agentic SOAR）代理程式，而這些代理程式本身就是高價值目標
• Agent Identity Management System (AIMS) — AIMS 的交易權杖（縮減權限、繫結交易、不可重複使用）、禁止權杖轉送的反模式，以及短期且不可撤銷的憑證，都是內部微服務呼叫鏈的 blast-radius 限制措施——限制權杖竊取、重放與橫向移動
• Capability Gating Is Not Authorization — ScopeGate 是工具呼叫邊界上的 blast-radius 限制：「在產生副作用之前，依政策限制遭入侵模型可觸及的動作」——這是限制而非預防的姿態，套用於受治理工具呼叫可攜帶的引數值，而非身分可觸及的資源
• Off-Host, Identity-Bound Authorization — 主機外的 blast-radius 限制：aiAuthZ（Kodathala，arXiv 2607.05518）「防止受欺騙的模型在每次經由它路由的呼叫中，執行超出已驗證使用者權限的動作」，其憑證代理程式完全不在代理程式主機上留下長期祕密（代理程式依名稱參照祕密；閘道器只在授權後解析祕密）——因此遭入侵的代理程式主機沒有任何可供竊取的東西，是「假設已遭入侵，限制其影響」姿態最徹底的形式
• Non-Malleable Memory Authority (TMA-NM) — 為代理程式記憶體量身打造的 blast-radius 授權：建議 TMA-NM 的佐證門檻 k 隨動作的 blast radius 擴大而提高（例行／可逆動作為 k=2，大額付款／憑證變更／大量外傳為 k≥3，最高層級則需要新的使用者授權），並與其針對任何固定 k 的機器檢查不變量組合
• Foundation → Enterprise → Advanced: Is the Agent Access-Control Jump a Cliff? — 分階段遷移（先身分、再代理能力、最後限制），以及以身分為基礎的隔離 → 沙箱化 → 硬體隔離在層級階梯上的位置
• Acceleration Whiplash — 「blast radius」的不同含義： Faros AI 的「每次變更都有更廣的 blast radius」指的是程式碼變更足跡（平均 PR 大小 +51.3%、每個 PR 編輯的檔案數 +59.7%）深入程式碼庫的程度，而不是本頁追蹤的安全入侵範圍

開放問題#

• 框架偏好以身分為基礎的隔離，而非網路分段，但多數企業已在分段上投入大量資源。遷移路徑是什麼？雙軌執行是否會造成新的缺口？
• 多代理程式分區隔離會增加需要管理的身分數量；在什麼時點，身分管理負擔會形成自身的攻擊面？

資料來源#

• Zero Trust for AI Agents — blast radius defined in Part I; resource boundaries in Part III; Phase 3 blast-radius assessment in Part IV