依政策允許清單 MCP 工具

一個已註冊的 MCP 伺服器會公告它想要的任何工具——而一個代理 會樂於呼叫其中任何一個。安全的姿態是相反的：決定你 實際需要的那一份短清單、恰好允許那些，並拒絕其餘的。 那就是一個允許清單，而在 OrcaRouter 上你用在 mcp 表面上 評估的 tool_name_glob 規則來建構它。 每一次跨越 MCP 閘道的 tools/call 在它抵達真正的伺服器之前都會透過你的防火牆政策 執行。所以允許清單不是建議性的——一次對 你未允許的工具的呼叫永不派發。

​

1. 為何要為安全 mcp 工具設一個預設拒絕的允許清單

一個拒絕清單——「封鎖危險的工具」——在一個伺服器加上 一個新工具、重新命名一個，或你連接第二個伺服器的那一刻就失效。危險 工具的集合是無止境的；你打算使用的那一組是小而 已知的。一個允許清單反轉了預設，所以未知被拒絕，而非 准入：

• 新工具預設被拒絕。 一個在你連接它之後長出一個 delete_repo 工具的伺服器，在你把它加入允許清單之前無法被 呼叫。
• 範圍是每伺服器的。 <server>.<tool> 命名空間讓你能允許 github.create_issue，同時拒絕 github.* 下的其他一切。
• 一個咽喉要道。 同一個政策治理隨附伺服器與 閘道後方的每個 BYO 伺服器，所以有一個地方能讀取 允許清單。

​

2. 兩個部分

一個允許清單是一個 default_verdict 加上一組有序的規則。 該 glob 會對照命名空間化的工具名稱匹配——github.create_issue、 shell.exec。* 匹配任何工具（謹慎使用；一條帶有 * 的 allow 規則會抵消整個允許清單）。一個前導的 <server>. 把該 glob 限定 到一個伺服器。

​

3. 一個具體範例

你連接了一個 github 伺服器，而你只想讓代理讀取與 開啟 issue——永不刪除或管理任何東西。在主控台中，開啟 Firewall → Policies、把政策的預設裁決設為 deny，並 加上兩條 allow 規則： 那就是整個允許清單。在預設為 deny 的情況下：

• github.create_issue → 匹配規則 1 → allow，派發。
• github.delete_repo → 沒有匹配 → 預設 deny。

一個被拒絕的 MCP 呼叫會作為一個工具錯誤 （firewall deny: …）回到模型——與任何失敗工具回傳的形狀相同——所以 代理能適應而非崩潰。（在 inbound 表面上，一個 deny 反而是 一個 HTTP 400，帶有錯誤碼 firewall_blocked。）

​

4. 用引數收緊

一個在允許清單上的工具名稱仍可能被以壞引數呼叫。 透過為該規則加上一個 args_match 子句（JSONPath + 一個 像 eq、contains、regex、in 或 cidr_match 的運算子）來進一步收窄，或 透過在 allow 之上為一個特定引數形狀疊加一條 deny 規則—— 例如，允許 github.create_issue 但在目標 repo 不在一個核准清單上時 deny 它。關於完整的運算子 集合，請見防火牆規則參考。

​

5. 安全地推出

在正式環境中翻轉一個全伺服器的預設拒絕，你冒著弄壞一個 悄悄依賴一個你忘記的工具的代理的風險。兩個設定能降低風險： 一旦 shadow 日誌乾淨——沒有合法的呼叫會被拒絕—— 清除 shadow_mode，允許清單就強制執行。

​

6. 驗證它運作

在強制執行後，確認被拒絕的工具確實被拒絕：

• Dry-run 一次對照政策的 tools/call（Developer+）以看見 裁決以及哪一條規則——或預設——產生它，而不送出 真實流量。傳入一個工具名稱、表面與範例引數；引擎會 評估它們並回傳裁決軌跡而不記錄一個事件。
• 觀看事件。 每一次被封鎖的呼叫會記錄一個 Developer+ 能在 主控台中讀取的防火牆事件； 稽核事件頁面涵蓋該動態及其 欄位。

​

相關