跳轉到主要內容
一個防火牆政策會對你的代理發出的每一次 工具呼叫決定一件事：一個裁決。要麼一條規則匹配並產生一個裁決， 要麼沒有任何規則匹配而由政策的預設裁決接管。本頁涵蓋兩者—— 每個防火牆裁決做什麼、cap_cost 如何解析，以及為何 audit 是你 從之起步的預設值。 關於裁決在規則文法中的位置，參見 防火牆規則；關於在建立政策時挑選 一個預設裁決，參見建立與綁定。

​
1. 六個規則裁決

一條規則恰好產生六個裁決之一。在主控台規則編輯器中撰寫它們； 引擎會按優先順序走訪規則，而第一個匹配者勝出。
呼叫原封不動地進行。它仍會作為一個 allow 落入 事件動態，所以你保有一條 稽核軌跡而不封鎖任何東西。將它用作 default-deny 政策中的一個 明確許可。
流量結果與 allow 完全相同，但該呼叫會被標記為你想觀察的某個 東西。這也是預設裁決開箱即用所落在的值——觀察一切、封鎖 無物，直到你準備好強制執行為止。
呼叫永遠不會抵達工具。在 inbound 介面上中繼會傳回 HTTP 400， 帶有錯誤代碼 firewall_blocked，指名工具與原因；在 mcp 介面上 它會以一個工具錯誤回來，這樣模型能做出反應。參見 封鎖的樣子。
從工具呼叫引數（代理放進 command 或 body 欄位的一個密鑰 或 PII）中遮罩匹配到的子字串，並轉送清理後的呼叫。它只遮罩 引數——絕不遮罩工具回傳的內容。在 inbound 介面上尚無呼叫時 引數，所以 sanitize 會升級為封鎖。參見 淨化回應。
把呼叫變成一次頻道外的審查。中繼會傳回 HTTP 400，帶有代碼 firewall_approval_pending 與一個審批 id；該呼叫不會抵達工具。 一位審查者在主控台或透過 webhook 回呼解決它，而代理會帶著一個 一次性的審批標頭重新提交。參見 審批。
一個成本斷路器——撰寫為一條規則，但在評估時解析為 allow 或 deny。參見 §3與 成本上限。
影子模式會壓平強制執行。 在 影子模式下，每個強制執行的 裁決（deny、sanitize、pending_approval，以及一個解析為 deny 的 cap_cost）都會被降級為 audit，原因會被加上前綴 [shadow] would …。以這種方式推出一個強制執行的政策，並在你將它切換為 即時前觀察事件動態。

​
2. 預設裁決

預設裁決（政策上的 default_verdict）是當沒有任何規則匹配某 工具呼叫時政策所做的事。它是你姿態的底線，而且與規則裁決不同， 它只接受三個值：
default_verdict當無規則匹配時…
audit （預設）允許呼叫，但記錄它。最安全的起點。
allow允許並記錄，無審查記錄。
deny封鎖任何規則未明確允許的東西——一個 default-deny 姿態。
一個新政策預設為 audit：它觀察每一次工具呼叫，並在你加入 強制執行的規則之前封鎖無物。三個僅限規則的裁決——sanitize、 pending_approval 與 cap_cost——不能作為預設值；一個預設裁決 是一刀切的回退，而那些裁決只在限定於某個特定匹配時才有意義。
作為預設裁決的 deny 是 default-deny：你的規則未明確 allow 的 任何工具呼叫都會被封鎖。對一個鎖緊的代理很強大，但它會擋下你忘了 加入允許清單的呼叫。將它與明確的 allow 規則搭配 （工具允許清單），並先在 影子模式下推出它。

​
3. cap_cost 解析為 allow 或 deny

cap_cost 是那個不會出現在你事件中的裁決。你撰寫一條帶有 cap_cost_cents 上限的規則，但在評估時引擎會在事件被記錄之前將它 解析為一個具體的 allow 或 deny——所以 事件動態從不攜帶一個字面的 cap_cost 裁決，只有代理實際看見的 allow/deny。 上限是每代理執行的：引擎會將該執行的累計花費對照你的上限比較。
  • 在上限之下 → 解析為 allow。（內部上這被視為不匹配，所以 評估會繼續到下一條規則，而不是讓 cap_cost 以 first-match 勝出而 作為一個許可。）
  • 超過上限 → 解析為 deny，原因會指名該執行的總額對比上限。這是 終端的、斷路器式的結果。
// A rule that caps a run at $5.00 of accumulated spend.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost 只在派發前介面（inbound、mcp）上觸發——那是封鎖一個 呼叫仍能防止花費的點。在派發後的 response 與 egress 介面上它是 惰性的（已沒有東西可阻止），所以引擎會在那裡跳過它。

​
4. 一個裁決如何被選出

對任何工具呼叫，無論哪個裁決勝出，解析方式都相同：
閘道挑選綁定到呼叫金鑰（firewall_policy_id）的政策，或工作區 預設值——參見 解析。
規則以 priority ASC 順序執行。第一條其介面、工具 glob、可選的 引數子句以及可選的 egress 範圍全都匹配的規則會產生裁決。
若無任何規則匹配，則套用政策的 default_verdict——除非你改過它， 否則是 audit。
如果該呼叫由一個受治理的技能 擁有，則一個 block 模式的技能會強制 deny，而一個 quarantine 模式的技能會將任何未達 deny 的裁決升級為 pending_approval。

​
5. 一個 deny 的成本與重試行為

inbound 介面上的一個防火牆裁決會在上游模型呼叫之前觸發，所以 那裡的一個 deny 不耗費任何模型權杖。該錯誤被標記為 skip-retry——重跑同一個被封鎖的呼叫只會再次被封鎖，所以閘道會 告訴客戶端不要重試它。 這與一個防護欄 封鎖不同，後者審查的是提示／回應文字（PII、密鑰）而非工具動作， 並傳回它自己的 guardrail_blocked 錯誤。一個請求可以同時通過兩個 平面。
每個裁決都留下一條軌跡。 每一次評估——allow、audit、deny、 解析後的 cap_cost、被保留的審批——都會被記錄為一個防火牆事件，可按 裁決、介面、工具與執行篩選。事件動態就是你確認一個政策正在產生你 預期裁決的方式。參見 事件記錄與 分析。

​
接下來去哪裡

建立與綁定政策

挑選一個預設裁決並將一個政策綁定到金鑰。

成本上限

撰寫一個花費上限，以及它如何每執行解析。

影子模式

在你衡量影響時將每個強制執行的裁決降級為 audit。

規則參考

一個裁決背後完整的匹配語言。
要了解這些裁決意在阻止的威脅，參見 危險的工具呼叫與 過度代理權。