防火牆

防護欄審查流經模型的文字。而防火牆治理代理採取的動作——它呼叫的工具、它觸及的 MCP 伺服器、它載入的技能，以及它通訊的主機。它是 防護欄在動作層的對應物：相同的 工作區範圍限定、相同的綁定一次模型、相同的「政策存在於 閘道中，而不是你的應用程式中」承諾。 本頁是概念總覽與操作參考。三個 配套頁面深入說明各個運作環節：

​

1. 什麼是防火牆

AI 代理不只是產生文字——它會行動。它會呼叫 shell.exec、 查詢 db.query、擷取一個 URL、載入一個社群技能，或透過 第三方 MCP 伺服器路由一次工具呼叫。其中每一項都是具有 真實世界後果的動作，而提示詞層級的防護欄看不見它們。 防火牆是一個工作區層級的、命名的政策，閘道會在 每次工具呼叫時對它進行評估。你撰寫一次政策，將一個 API 金鑰綁定 到它（或將其中一個設為工作區預設值），從此該金鑰發出的每一次工具 呼叫都會在抵達工具之前被對照該政策檢查。 每個政策是一份有序的規則清單。一條規則決定一件事—— 它套用於哪些工具呼叫（一個工具名稱 glob，可選擇性地限定到某個 技能與某個強制執行介面），以及要對它們做什麼（一個 裁決：allow、audit、deny、sanitize、保留待審批，或設定成本 上限）。引擎會按優先順序走訪規則，第一個匹配者勝出， 若無任何匹配則回退到政策的預設裁決。 編輯政策會在下次呼叫時對綁定到它的每個金鑰生效。 無需重新部署。無需修改代理程式碼。政策在閘道處強制執行 ——你的代理像以前一樣繼續發出工具呼叫。

​

2. 四個強制執行介面

每一次工具呼叫都會對照恰好一個介面進行評估——即 防火牆在請求生命週期中看見它的那個點： 沒有指定 stage 的規則會套用於所有介面；當某裁決只在某個 介面上才有意義時（例如 egress 允許清單），請將規則固定到該介面。

​

3. 核心概念

​

範圍限定與解析

政策的解析方式與防護欄和 API 金鑰完全一致——當你有作用中的 工作區時為工作區共享。對任何工具呼叫，閘道會按此順序解析政策：

1. 金鑰綁定——如果呼叫的金鑰有 firewall_policy_id，則套用該 政策（當它存在且已啟用時）。
2. 工作區預設值——否則套用工作區已啟用的 is_default 政策。
3. 兩者皆無——不執行任何強制。在觀察模式開啟時，呼叫會被 允許並記錄為一個缺口；在它關閉時，呼叫會被靜默允許 （與從未啟用此功能的工作區位元組完全一致）。

每個工作區最多只能有一個政策作為預設值；晉升一個新的 預設值會在同一交易中降級舊的那個。

​

4. 裁決

一條規則（或預設裁決）會產生以下其中之一： 在影子模式下，deny / sanitize / pending_approval 全都會被降級 為 audit，讓你能在某政策改變流量之前先衡量它的影響。

​

5. 一次工具呼叫如何被評估

1. 一次工具呼叫抵達閘道（在 inbound 公告、在回應中發出、 透過 MCP 閘道派發，或被回報為 egress）。
2. 引擎解析作用中的政策（§3）。
3. 它按優先順序走訪政策的規則（優先順序較低者 先；同分時以規則 id 決定）。當一條規則的介面、它的 工具名稱 glob、它可選的技能名稱 glob、它可選的引數 子句，以及它可選的 egress 範圍全都匹配時，該規則才匹配。
4. 第一個匹配者勝出 → 套用該規則的裁決。若無任何規則匹配 → 政策的 default_verdict。
5. 如果該呼叫由一個受治理的技能擁有， 則該技能的強制執行模式會疊加套用於其上——處於 block 模式的技能會強制 deny；處於 quarantine 模式的技能會將任何 未達 deny 的裁決升級為 pending_approval。
6. 決策會被記錄為一個防火牆事件（除非它是一次乾跑）， 並與該代理執行和工作階段相關聯。

​

6. 封鎖的樣子

在 inbound 介面上被拒絕的呼叫會傳回 HTTP 400，帶有一個 OpenAI 形狀的錯誤主體、錯誤代碼 firewall_blocked，以及一條 指明工具與原因的訊息——例如 tool "shell.exec" blocked by firewall: destructive shell command。該錯誤會攜帶結構化的 metadata（原因代碼、風險因子、分數），並被標記為 skip-retry （重跑同一個呼叫只會再次被封鎖）。 透過 MCP 閘道派發的呼叫會被封鎖為一個工具錯誤 （firewall deny: <reason>），而不是傳輸失敗，因此模型 會看到該拒絕並能做出反應——選擇另一個工具、詢問使用者，或 停止——而不是崩潰。 一個被保留的呼叫（pending_approval）會傳回 HTTP 400，帶有代碼 firewall_approval_pending 以及一個客戶端用於輪詢的審批 id。

​

7. 人工審批（HITL）

一個 pending_approval 裁決會把一次工具呼叫變成一次頻道外的審查：

1. 引擎將一筆審批記錄排入佇列，並傳回一個攜帶其 id 的 「保留中」回應；該呼叫不會抵達工具。
2. 一位審查者解決它——從主控台（Developer+），或透過一個 HMAC 簽署的 webhook 回呼到你自己的審批系統。
3. 你的代理（或 MCP SDK）對該審批 id 進行輪詢；一旦獲批，它 會帶著一次性的 X-OrcaRouter-Firewall-Approval 標頭重新提交原始 呼叫，閘道便會讓它通過那一次。

決策是先寫者勝出且具冪等性。如果底層規則在保留之後被 編輯過，豐富化資訊會記下 rule_changed，好讓審查者知道 情境已經改變。

​

8. 自主等級——一個開關掌控你的整體姿態

逐條規則調校政策是精確的路徑；自主等級則是 快速的路徑。單一控制項會在一次交易中以一鍵還原的方式，原子性地 取代你工作區的防火牆與防護欄姿態： 還原會從稽核快照還原出完全相同的先前狀態。

​

9. 異常偵測

在靜態規則之外，防火牆會學習每個工作區正常的工具使用 形態，並在一個檢視者可讀的動態上標記偏差：

• 速率／成本飆升——每個工具的活動會被對照一個習得的 週小時基線（一個 14 天的滾動平均）評分，所以即使每次呼叫 各自都被允許，「週日凌晨 3 點的 100 次 db.query 呼叫」仍會顯得突兀。
• retry_loop——一個代理反覆敲打同一個失敗的工具。
• novel_path——這個工作區從未做過的一次工具到工具的轉移。

該動態只回報工具名稱、遮罩過的權杖 id 與計數。你可以 在調查期間**暫停（snooze）**一個異常達 7 天。

​

10. 可觀測性

防火牆會留下你可以採取行動的軌跡，全部都是工作區層級的：

​

11. 與閘道其他部分的關係

​

12. 將一個代理連接到防火牆閘道

工具呼叫抵達引擎有兩種方式：

• MCP 閘道——將你的 MCP 客戶端（Claude Desktop、Cursor、一個 代理框架）指向 https://api.orcarouter.ai/api/v1/firewall/mcp。 閘道會公開每個可觸及的已註冊伺服器的工具，以 <server>.<tool> 命名空間化，並就地評估每一次 tools/call。參見 MCP 伺服器。
• Evaluate hook——在派發一次工具呼叫之前，從你自己的 代理迴圈呼叫 POST /api/v1/firewall/evaluate，並依裁決行動。

兩者都需要一個防火牆閘道範圍的權杖——為此目的鑄造的 專用 API 金鑰。一般金鑰在這些路由上會得到 403。

​

13. API 參考

所有主控台路由都透過工作區情境進行工作區限定，並一致地 強制執行 RBAC：讀取與 test/simulate 沙盒對每個成員開放； 寫入需要 Developer+。

​

政策與設定

​

姿態、預設集與沙盒

​

可觀測性

規則、MCP 伺服器與技能各自有它們自己的端點——參見 規則、 MCP 伺服器，以及 技能。

​

閘道（機器對機器）

這些在一個防火牆閘道範圍的權杖上執行，而不是主控台工作階段：

​

14. FAQ

​

延伸閱讀

想更深入了解代理安全？**保護你的代理（零信任）**指南會將此功能放入零信任工作流程中。