防火牆規則綱要參考

一個防火牆政策是一份有序的規則清單,而一條規則只是一小袋欄位:它匹配哪些工具呼叫、在哪個介面上,以及對它們做什麼。當你需要讀一條別人寫的規則——或精確地推理一條你正在建構的——你想要欄位清單集於一處。那就是本頁。你在主控台規則編輯器中撰寫規則（寫入需要 Developer+）;編輯器寫入下面的結構化欄位。本頁是欄位層級的地圖;深入的匹配引擎存在於防火牆規則。

1. 防火牆規則綱要一覽

每條規則攜帶同樣的欄位。只有 verdict 總是必填——其餘一切都收窄 規則匹配什麼或設定所選的裁決,而一個缺席的匹配器是空虛地為真。

欄位	用途
`priority`	評估順序——較低先執行。
`verdict`	規則匹配時的動作（必填）。
`stage`	要限定到的介面;空 = 全部。
`tool_name_glob`	工具名稱上的 Glob。
`args_match_json`	JSONPath 引數判定式,作為一個 JSON 編碼字串。
`egress_json`	Host / CIDR 允許拒絕清單（egress 規則),作為一個 JSON 編碼字串。
`sanitize_json`	遮罩設定（當 `verdict = sanitize` 時),作為一個 JSON 編碼字串。
`cap_cost_cents`	以 USD 分計的執行成本上限（當 `verdict = cap_cost` 時）。
`sequence_json`	有序的多步驟鏈判定式（序列規則),作為一個 JSON 編碼字串。
`label` / `notes`	人類名稱與理由——在事件中顯示,被引擎忽略。

一條規則在它所有宣告的匹配器同時成立時觸發——介面匹配（或為空）、工具 glob 匹配、引數子句匹配（或缺席）、egress 範圍匹配（僅 egress 規則）。引擎按優先順序走訪規則,而第一個匹配者勝出;若無任何匹配,則套用政策的 default_verdict。

2. `priority`——評估順序

一個整數序數。較低先執行;同一優先順序的兩條規則以規則 id（插入順序）決勝。把你特定的切出放在你寬泛的捕捉一切之上——一個優先順序 10 上對一個受信任工具的 allow,勝過一個優先順序 100 上的 deny *。

留下間隔（10、20、30）,這樣你稍後能在兩條既有規則之間插入一條新規則而無需重新編號整個政策。關於排序策略,參見規則優先順序。

3. `verdict`——動作

那唯一必填的欄位。當一條規則匹配時,它的裁決決定該呼叫發生什麼：

裁決	效果
`allow`	讓呼叫通過,會被記錄。
`audit`	允許並記錄以供審查——常見的 `default_verdict`。
`deny`	封鎖呼叫。
`sanitize`	從工具引數中遮罩匹配到的子字串,然後轉送。
`pending_approval`	為一個人類審查者保留呼叫。
`cap_cost`	一旦某代理執行的累計花費跨越一個上限就拒絕。

一個 deny 在 inbound 介面上傳回 HTTP 400 firewall_blocked, 或在 mcp 介面上傳回一個工具錯誤。一個被保留的呼叫傳回 HTTP 400 firewall_approval_pending,帶有一個代理輪詢的 id。在影子模式下,每個強制執行的裁決都被降級為 audit,原因加上前綴 [shadow] would …。完整的表格與封鎖形狀參見裁決。

4. `stage`——強制執行介面

把規則固定到防火牆的某個介面。將它留空,規則就套用於所有介面：

inbound — 公告的工具定義

一個代理在請求上向模型公告的工具。在模型甚至無法選擇它之前封鎖一個危險工具。

response — 模型發出的 tool_calls

模型在其回覆中發出的 tool_calls。

mcp — tools/call 派發

透過防火牆 MCP 閘道路由的一次 tools/call。

egress — 外送目的地

某工具觸及的一個外送 host / IP / CIDR——SSRF 與資料外洩介面。

某些裁決 + 介面的搭配在儲存時被拒絕,因為該裁決無法在那裡觸發: cap_cost 是一個派發前的執行成本上限,在 response 與 egress 上惰性;pending_approval 只在 inbound 保留,所以一個明確的 response/egress 固定會被拒絕。編輯器隱藏這些組合;API 拒絕它們。參見介面。

5. `tool_name_glob`——哪個工具

工具名稱上一個小而區分大小寫的 glob——shell.* 對應一整個家族、 *.delete 對應跨伺服器的一個動詞、http_fetch 對應一個精確工具。空或 * 匹配每個工具。一個可選的技能名稱 glob（相同文法）對 擁有它的技能做一個第二條件的 AND,所以你能信任一個來自內建技能的工具並把關一個來自社群技能的。完整文法——前綴、後綴、中綴、精確,以及那些絆倒人的邊角——是它自己的參考:Glob 模式語法。

6. `args_match_json`——以哪些引數

glob 回答哪個工具;args_match_json 回答以哪些引數——「封鎖 shell.exec」與「只在指令為 rm -rf 時封鎖 shell.exec」之間的差別。它的值是一個攜帶一組 JSONPath 子句的 JSON 編碼字串, 全部做 AND。解碼後,子句物件看起來像：

{
  "clauses": [
    { "path": "$.command",    "op": "regex",      "value": "rm -rf|drop table" },
    { "path": "$.connection", "op": "in",         "value": ["prod", "replica"] },
    { "path": "$.ip",         "op": "cidr_match", "value": "10.0.0.0/8" }
  ]
}

在一個請求主體中,該欄位將那個物件攜帶為一個跳脫的字串,例如 "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf\"}]}"。運算子是 eq、contains、regex、in、cidr_match、gt 與 lt。一個缺席的 args_match_json 是空虛地為真——規則僅靠 glob 匹配。完整的判定式語言、path 語法,以及一個壞掉子句的失敗關閉行為,在驗證引數與引數食譜中。

7. `egress_json`——哪些目的地

用於 egress 介面:一個 JSON 編碼字串,持有一個對照某工具觸及的外送目的地匹配的 host / CIDR 允許與拒絕清單。解碼後,該物件看起來像：

{
  "deny":  ["169.254.169.254", "10.0.0.0/8"],
  "allow": ["api.openai.com"]
}

各條目以一個 CIDR、一個 IP 字面值,或一個不區分大小寫的主機名稱匹配。極性跟隨裁決——以一個強制執行的裁決,deny 清單定義什麼被封鎖,而 allow 從中切出例外。

Baseline 防火牆範本附帶一條 egress deny 規則,帶有一個現成的 SSRF / cloud-metadata 拒絕清單（metadata IP 169.254.169.254、 RFC-1918 範圍、loopback、link-local,以及 metadata.google.internal）, 所以你不必手動撰寫那些。在其上加入你自己的目的地以把關任何其他你想把關的東西。完整食譜參見Egress 控制, 為何它重要參見資料外洩。

8. `sanitize_json`——遮罩引數

當 verdict = sanitize 時使用:一個 JSON 編碼字串,指名哪些預設集／自訂 regex 在清理後的呼叫被轉送之前,從工具引數中遮罩匹配到的子字串——對剝除一個代理丟進一個引數的密鑰或 PII 值而不封鎖整個動作很有用。解碼後,該物件看起來像：

{ "presets": ["email", "ssn_us"], "custom": ["foo-\\d+"] }

Sanitize 只遮罩引數——絕不遮罩工具回傳的內容。一條 sanitize 規則必須指名至少一個預設集或自訂模式（一個空的淨化器會被拒絕）。在 inbound 介面上沒有呼叫時引數可遮罩,所以那裡的一個 sanitize 裁決 升級為一個 deny。

預設集庫與遮罩形狀參見淨化回應。

9. `cap_cost_cents`——一個花費上限

當 verdict = cap_cost 時使用:一個每規則的執行成本上限,一個以 USD 分計的整數。當規則匹配時,一旦代理執行的累計花費跨越該上限呼叫就被拒絕——一個針對失控迴圈的斷路器,在事件中解析為 allow 或 deny。該上限必須明確且非負,而該規則不能被固定到 response 或 egress（那裡裁決惰性）。完整行為在成本上限中。

10. 一條完整的規則

把欄位組合起來——拒絕 shell.exec,但只在指令看起來具破壞性時, 限定到模型發出的工具呼叫：

{
  "priority": 10,
  "label": "block destructive shell",
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|:\\\\(\\\\)\\\\{\"}]}",
  "verdict": "deny",
  "notes": "fork bombs and recursive deletes only — plain shell.exec audits"
}

介面匹配 response 介面、glob 挑選 shell.exec、單一子句收窄到一個破壞性指令,而裁決拒絕。任何其指令不匹配該 regex 的 shell.exec 都會落到下一條規則或政策預設值。將一個金鑰綁定到該政策（金鑰上的 firewall_policy_id）,它就在下一次呼叫時即時——無需重新部署。

在你依賴它之前,確認一條規則恰好在你預期的東西上觸發: 測試規則對照一個樣本工具呼叫乾跑一個政策,並傳回裁決、匹配到的規則與原因,而不派發任何東西。

11. 欄位如何組合

一條有效規則最少需要什麼？

一個 verdict。其餘一切都是可選的:一個空的 stage 匹配所有介面、一個空的 tool_name_glob（或 *）匹配每個工具,而一個缺席的 args_match_json 匹配任何引數。一個光禿禿的 { "verdict": "audit" } 是一個有效的捕捉一切。

匹配器是 AND 還是 OR？

它們做 AND。一條規則只在它的介面、工具 glob、技能 glob、引數子句與 egress 範圍全部成立時才觸發。要表達 OR,寫獨立的規則。

哪些欄位與哪個裁決搭配？

sanitize_json 只為 sanitize 裁決讀取;cap_cost_cents 只為 cap_cost;egress_json 只在 egress 介面上。主控台在儲存時驗證這些搭配,所以一條顯示一種行為但永遠無法強制執行它的規則無法被持久化。

如果兩條規則都匹配會怎樣？

較低的 priority 勝出（同分以規則 id 決勝）——第一個匹配者勝出,而評估在那裡停下。參見規則優先順序。

建立政策

撰寫你的第一個政策並綁定一個金鑰。

Glob 語法

完整的工具名稱 glob 文法。

裁決

每個裁決,以及一個封鎖的樣子。

驗證引數

深入的 JSONPath 引數子句。

管理政策

編輯、版本控制與還原政策。