跳轉到主要內容
一條防火牆規則會在一次工具呼叫生命週期中的某個特定點觸發。那個 點就是它的介面（stage）——四個強制執行介面之一，每一個都看見 該呼叫的不同切片。把一條規則固定到錯誤的介面，它就會看見錯誤的 資料：inbound 介面上的一個 egress 允許清單沒有目的地可檢查； inbound 上的一個引數子句尚無呼叫時引數。 本頁是針對這四個代理防火牆介面的聚焦指南：每個介面觀察什麼、 一條規則何時應該指向它，以及同一個意圖在不同介面上被表達的那一個 具體方式。完整的規則詞彙請參見 防火牆規則；圍繞它的政策模型請參見 防火牆。

​
1. 四個介面一覽

每一次評估都被標記上恰好一個介面。一條沒有介面（""）的規則會 套用於全部介面；一條固定到某個介面的規則只在那裡觸發。
介面該介面看見什麼
inbound代理在請求上公告的工具
response模型在其回覆中發出的 tool_calls
mcp透過 MCP 閘道派發的一次 tools/call
egress某工具觸及的一個外送 host / IP / CIDR
介面名稱是穩定的 enum 值——你在規則編輯器的介面欄位中逐字設定 它們，或在透過 API 撰寫時作為 stage 屬性設定。
介面治理的是哪些資料在範圍內，而不是裁決有多嚴格。一個 deny 在任何介面上都是一個 deny；改變的是規則是否擁有它需要匹配的 引數、工具名稱或目的地。

​
2. inbound——代理公告的工具

最早的介面。在模型還沒執行之前，你的代理會送出它願意讓模型呼叫的 工具定義清單。inbound 介面看見那個被公告的工具集，並能在模型 甚至無法選擇某個危險工具之前就將其封鎖。 這個介面上沒有呼叫時引數——模型還沒決定要如何呼叫任何東西——所以 inbound 規則匹配的是工具名稱（以及可選的擁有它的技能），而不是 args_match_json。
inbound 上的一個 sanitize 裁決沒有可遮罩的東西（尚無引數存在）， 所以它升級為封鎖。請將 inbound 規則撰寫為明確的 allow / deny， 並把 sanitize 留給執行介面。
這裡被拒絕的呼叫會傳回 HTTP 400，帶有代碼 firewall_blocked，以 工具與原因命名，並標記為 skip-retry。

​
3. response——模型發出的工具呼叫

一旦模型回覆，它可能會發出一個或多個 tool_calls——帶有真實引數的 具體呼叫。response 介面看見那些，所以引數層級的規則屬於這裡：不是 「封鎖 shell.exec」，而是「只在指令為 rm -rf 時才封鎖 shell.exec」。 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
由於模型所選的引數已存在，sanitize 在這裡可運作——它會從呼叫的 引數中遮罩匹配到的子字串並轉送清理後的呼叫。（Sanitize 只遮罩 工具呼叫引數；它絕不觸及工具回傳的內容。）

​
4. mcp——透過閘道派發的呼叫

當一個代理透過 OrcaRouter 的 MCP 閘道 觸及一個工具時，每一次 tools/call 都會在 mcp 介面上、在它被派發 到已註冊的伺服器之前被評估。這是治理 Model Context Protocol 流量的 介面——與 response 相同的 glob／引數／裁決詞彙，套用於 MCP 派發。 這裡的封鎖會以一個工具錯誤（firewall deny: <reason>）呈現，而 不是傳輸失敗，所以模型會看見該拒絕並能做出反應——選擇另一個工具、 詢問使用者，或停止。
mcp 介面與每伺服器治理搭配：每個已註冊的 MCP 伺服器都有它自己的 健康探測與加密憑證，而透過它載入的技能會攜帶一個風險帶與一個 強制執行模式。參見 防火牆 MCP與 防火牆技能。

​
5. egress——某工具觸及的外送目的地

最後一個介面。當一個工具回報一個外送網路目的地時，egress 介面 會對它進行匹配——SSRF 與資料外洩介面。Egress 規則不單靠工具名稱 模式匹配；它們匹配的是一個 host / IP / CIDR 清單： 
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\"],\"allow\":[\"api.openai.com\"]}"
}
各條目會以一個 CIDR、一個 IP 字面值，或一個不區分大小寫的主機名稱 進行匹配。你自己撰寫 host 與 CIDR 拒絕規則——cloud-metadata 端點 （169.254.169.254）與 RFC-1918 範圍是要拒絕的典型對象。關於 allow/deny 極性，參見 防火牆規則 §6。
沒有任何預設集附帶 CIDR 規則。tight 自主等級的 SSRF 姿態拒絕的是擷取形狀的工具名稱（例如 http_fetch、 web_search、fetch_url）；一個基於目的地的 egress 拒絕，是你為 你的代理絕不能觸及的主機與範圍而撰寫的東西。

​
6. 選擇正確的介面

同一個安全目標往往有一個最佳介面。把意圖匹配到實際攜帶你需要 資料的那個介面：
如果模型甚至不應看見某個工具，就在 inbound 上拒絕它。封鎖會 落在模型呼叫之前，所以它不耗費任何模型權杖。
引數子句需要模型所選的引數，那只存在於 response 與 mcp 上。 對一個危險的引數做 deny，或用 sanitize 剝除代理放進某個引數中 的密鑰或 PII 值。
透過 MCP 閘道路由的呼叫會在派發前於 mcp 上被評估——每個已註冊 伺服器工具的咽喉要道。
基於目的地的規則——封鎖 cloud-metadata IP、拒絕一個 CIDR、將你 核准的主機加入允許清單——只在 egress 上才有意義。
一條沒有介面的規則會在全部四個介面上執行。將它用於一個一刀切的 default_verdict 風格規則，或一個你在每個出現處都拒絕的工具。

​
7. 介面與影子模式

一個政策的 shadow_mode 旗標與介面無關。開啟它，每個強制執行的 裁決——在任何介面上——都會被降級為 audit，原因會被加上前綴 [shadow] would …，所以你能在一條規則改變即時流量之前確認它在 正確的介面上觸發。參見 影子模式與 強制執行模式。

​
8. 介面在更大圖景中的位置

四個介面是強制執行的在哪裡；模型的其餘部分則是做什麼與由誰。

裁決

每個介面一旦匹配後能做什麼——allow、audit、deny、sanitize、保留 待審批、設定成本上限。

工具允許清單

用 inbound 來約束一個代理公告的工具集。

驗證引數

撰寫 response / mcp 引數子句，依工具被如何呼叫來把關它。

Egress 控制

在 egress 介面上封鎖外送目的地——外洩邊界。
關於這些介面如何坐落在審查路徑上，參見 OrcaRouter 如何審查與 強制執行路徑延遲 說明。關於每個介面處理的威脅，參見 危險的工具呼叫、 資料外洩，以及 MCP 工具投毒。