跳轉到主要內容
對一個自主代理而言最安全的姿態是 default-deny：預設封鎖每個 工具，然後明確地只允許你代理打算使用的那少數幾個。一個代理拾起的 任何新東西——一個社群技能、一個設定錯誤的 MCP 伺服器、一個越獄 說服模型去用的工具——都會被拒絕，因為你從未把它加入允許清單，而 不是因為你記得要封鎖它。 本頁是 api.orcarouter.ai 上的代理工具允許清單模式：一個 deny 預設裁決，加上一個或多個以 tool_name_glob為鍵的 allow 規則。關於那些規則背後完整的匹配語言，參見 防火牆規則。
允許清單在主控台中於 Security → Firewall 下撰寫，或透過 /api/workspace/firewall/* 管理路由（你的工作階段／存取權杖——而非 中繼 sk-orca-… 金鑰）。只有你代理的 /v1/* 呼叫使用中繼金鑰。 建立或編輯一個政策是一項 Developer+ 動作。

​
1. 為何對代理採用 default-deny

一個封鎖清單（「拒絕 shell.exec、拒絕 db.delete、…」）永遠只能和 你想到的最後一個威脅一樣完整。一個允許清單則倒轉了舉證責任： 閘道拒絕政策未明確允許的一切，所以一個未知的工具在構造上就是 關閉的。

預設裁決 = deny

政策的底線。在沒有規則匹配時，每一次工具呼叫都被封鎖。

Allow 規則把工具重新加回

每條 allow 規則指名你實際使用的工具——以精確名稱或以 glob。
引擎會按優先順序走訪一個政策的規則，而第一個匹配者勝出；若無 任何匹配，它會落到政策的 default_verdict。所以一個允許清單就是： 為你真實工具設的高優先順序 allow 規則，加上一個捕捉其餘一切的 deny 底線。

​
2. 一個範例：對一個研究代理的工具做允許清單

假設你的代理只需要搜尋網頁並從一個知識庫讀取——名為 web.search 與 kb.read 的工具。其餘一切（shell、檔案寫入、資料庫變更、任何 prompt-injection 可能召喚出的工具）都必須被拒絕。 將政策建構為 預設 deny + 兩條 allow 規則：
1

以一個 deny 預設值建立政策

Security → Firewall → Policies → New policy。為它命名、讓 Enabled 保持開啟，並將預設裁決設為 deny。這是那個關閉的 底線——參見建立政策。
2

為每個工具家族加入一條 allow 規則

在規則編輯器中加入兩條規則，兩者皆 verdict = allow：
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search 是一個精確匹配；kb.* 是一個前綴 glob，它允許 kb.read、kb.search 與任何未來的 kb.* 工具，而無需重新編輯 政策。
3

將它綁定到你代理的金鑰

將金鑰的 firewall_policy_id 設為此政策（或將它設為工作區 預設值）。你代理的請求主體不變。
現在 web.search 與 kb.read 通過；一次對 shell.exec 的呼叫不匹配 任何 allow 規則，撞上 deny 底線，並在 inbound 介面上以 HTTP 400、 代碼 firewall_blocked 回來——參見 封鎖的樣子。
將 allow 規則撰寫為精確名稱或窄前綴（kb.*），而不是寬泛的 後綴。一個鬆散的 *.read 會允許 kb.read 以及 secrets.read——與 允許清單的用意正好相反。把 glob 保持得和工具命名所允許的一樣緊。

​
3. 一個畫面看懂 glob

tool_name_glob 是一個小而區分大小寫的文法——沒有 regex、線性 時間。對一個允許清單而言重要的形狀：
模式允許
web.search正好那個工具。
kb.*前綴——kb.read、kb.search（不含光禿禿的 kb）。
*.search後綴——web.search、kb.search，以及光禿禿的 search。
*.tools.*中綴——byo.tools.fetch 及類似者。
關於完整文法（中綴規則、邊界情況、技能名稱 glob），參見 Glob 語法與 防火牆規則參考。
一個 *.suffix glob 也會匹配那個光禿禿、未命名空間化的動詞—— *.search 允許一個字面名為 search 的工具，而不只是 web.search。 供應商與不做命名空間化的 MCP 伺服器會以光禿禿的動詞公開工具，所以 一個被允許清單的後綴比它看起來更寬。當你想要一個緊的允許清單時， 偏好精確名稱或前綴。

​
4. 推出而不弄壞你的代理

Default-deny 是最可能封鎖一個你忘了需要的工具的姿態。分階段進行：
開啟影子模式。政策會像 在即時下那樣完全相同地評估並記錄，但會將每個 deny 降級為 audit，原因加上前綴 [shadow] would …。跑真實流量，然後讀取 事件動態。
Discovered tools 列出工作區 看過的每一個工具，標記為 covered 或 gap。影子模式的 「would-deny」事件加上那些缺口，會準確告訴你還需要哪些 allow 規則。
Test 沙盒會對照一個樣本 工具呼叫乾跑該政策，並傳回裁決、匹配到的規則與原因——不派發、 不持久化任何東西。確認 web.search 允許而 shell.exec 拒絕，然後 關閉影子。
一個被拒絕的 inbound 呼叫不耗費任何模型權杖——它在上游模型 執行之前就被封鎖了——而且被標記為 skip-retry，所以一個被封鎖的 工具不會以重複封鎖燒掉一份重試預算。參見 裁決。

​
5. 接下來去哪裡

封鎖特定工具

反向——保留一個 default-allow 底線並拒絕指名的工具。

驗證引數

允許一個工具，但只在帶有安全引數時（db.query 但不含 DROP TABLE）。

規則優先順序

first-match-wins 如何將你的 allow 規則排在 deny 底線之上。

裁決

allow、audit、deny、sanitize、pending_approval、cap_cost。
關於此模式處理的威脅，參見 過度代理權與 危險的工具呼叫。關於 為何 default-deny 是代理基準，參見 為何零信任。