rm -rf / 的 shell.exec、帶過大轉帳金額的支付 API、
針對生產副本的資料庫工具。這就是代理工具濫用，
這是代理系統中最嚴重的風險之一，因為工具呼叫有通常是不可逆的真實世界副作用。
代理防火牆有三個分層的防禦。你可以單獨或組合部署它們。
1. 允許清單：拒絕你未明確許可的一切
最強的控制是允許清單。你不必試圖列舉每個危險工具，而是列舉此代理合法需要的工具—— 並拒絕其他一切。這是零信任基準。 帶有default_verdict: deny 和每個批准工具的明確 allow 規則的政策實現了這一點。
範例：一個應該只從 CRM 讀取的代理：
shell.exec、db.delete、payment.transfer 的任何呼叫——
無論是有意發出還是由注入指令觸發——都命中 * 兜底並返回 HTTP 400 firewall_blocked 錯誤。
代理看到一個結構化的工具錯誤且無法重試（封鎖被標記為 skip-retry），
所以它不能迴圈繞過拒絕。
將你的政策的
default_verdict 設定為 deny 以獲得完整的允許清單強制執行。
使用預設的 audit 裁決，未匹配的呼叫被允許並記錄但不被封鎖——在推出期間有用但本身不是安全控制。| 模式 | 它涵蓋什麼 |
|---|---|
crm.* | crm 命名空間中的所有工具 |
*.read | 跨所有伺服器的任何讀取動詞工具 |
db.query | 恰好這一個工具 |
* | 所有東西（用於你的兜底拒絕） |
allow 規則放在低優先順序數字，
將兜底 deny 放在高優先順序數字。
2. 引數驗證：允許工具，封鎖危險調用
工具名稱上的允許清單是粗粒度的——它完全封鎖shell.exec。
有時你想許可一個工具但限制它如何被呼叫。引數子句讓你能匹配工具呼叫引數
內的特定欄位，使用 JSONPath 和一組操作符。
範例：允許 shell.exec 但封鎖 rm -rf
shell.exec 被呼叫且 $.command 引數匹配破壞性命令正規表示式時才觸發。
帶有安全命令的正常 shell.exec 呼叫落到下一條規則（或預設裁決）。
將此規則放在比任何通用 allow shell.exec 規則更低的優先順序數字，使其先觸發。
完整的引數操作符集：
| 操作符 | 何時使用 |
|---|---|
eq | 標量值（字串或數字）的精確匹配 |
contains | 子字串匹配——例如 $.query contains DROP TABLE |
regex | RE2 模式匹配——在熱路徑上安全，沒有回溯 |
in | 值必須在給定陣列中——例如只允許特定環境 |
cidr_match | CIDR 區塊中的 IP 地址——對外向目的地檢查有用 |
gt / lt | 數字比較——例如支付上限的 $.amount gt 10000 |
args_match 區塊中的所有子句都是 AND 的。如果路徑在呼叫的引數中不存在，
子句評估為假且規則不觸發——呼叫落到下一條規則或預設值。
支付守護範例——拒絕任何超過閾值的支付工具呼叫：
3. 人工介入：為高風險呼叫保留審批
對於真正必要但高風險的工具——觸發部署、批准退款、發送大量電子郵件—— 你可以要求人工簽核，然後呼叫才能繼續。pending_approval 裁決保留呼叫
並向代理返回 firewall_approval_pending 回應：
pending_approval 與引數子句相容——你可以只保留匹配閾值的調用，
並讓例行的通過：
4. 被封鎖的呼叫是什麼樣子
在 inbound 表面被拒絕的呼叫（請求中公告的工具）返回 HTTP 400， 帶有錯誤代碼firewall_blocked。回應包含結構化的 metadata——匹配的規則標籤、
原因代碼和風險因子——並標記為 skip-retry，使迴圈不能反覆敲打相同的被拒絕呼叫。
在 response 表面封鎖的呼叫（模型已經發出 tool_calls）返回一個模型可見的工具錯誤，
讓它有機會反應——選擇不同的工具、詢問使用者或停止——而不是崩潰。
5. 第一個匹配者勝出的順序
優先順序很重要。引擎按升序優先順序走訪規則，並在第一個匹配時停止。常見模式：| 優先順序 | 規則 | 裁決 |
|---|---|---|
| 5 | shell.exec + 破壞性正規表示式 | deny |
| 10 | shell.*（通用） | allow |
| 20 | crm.* | allow |
| 9999 | *（兜底） | deny |
shell.exec 被拒絕，
即使 shell.* 有通用的 allow。沒有低優先順序的拒絕，allow shell.* 規則會先獲勝。
6. 用影子模式安全推出
在將新政策切換到強制執行之前，開啟影子模式。政策評估每次工具呼叫並精確地 按生產中的方式記錄裁決，但每個強制執行裁決（deny、pending_approval、sanitize）
都被降級為 audit——沒有任何東西被封鎖。事件日誌中的原因帶有 [shadow] would deny 前綴，
這樣你可以在Events 和 Runs 視圖中衡量影響。
一旦你確認政策在你預期的事物上觸發——以及沒有你不打算的事物——關閉影子模式。下一個呼叫被強制執行。
tight 自主等級自動套用 block_destructive_shell 預設值。如果你需要一個快速姿態而不撰寫規則，
從主控台套用 tight，它在一步中附帶破壞性 shell 呼叫的拒絕政策。然後你可以在它上面疊加你自己的允許清單規則。
參見自主等級。7. 相關威脅
代理工具濫用很少孤立出現。未授權的工具呼叫通常是另一個攻擊向量的後果：- 提示注入——攻擊者在擷取的內容中嵌入指令， 將代理引導到它不打算呼叫的工具。
- 過度代理權限——代理被授予比其任務需要更多的工具存取， 使任何注入或設定錯誤立即危險。
- 威脅模型——工具濫用如何適應代理系統的完整攻擊面。
防火牆規則參考
完整的匹配語言——工具 glob、引數子句、所有操作符、裁決和 API。
防火牆概覽
政策、表面、自主等級、HITL 審批和可觀測性。