跳轉到主要內容
一個會說 Model Context Protocol （MCP）的代理，其安全性只取決於它所連接的伺服器。每個 MCP 伺服器都是 一組全新的工具、一份全新的憑證，以及全新的網路觸及範圍——而 代理直接撥接其中一個的那一刻，就沒有人在看那次呼叫了。那就是 mcp 安全必須解決的整個問題：不是「這一個工具 安全嗎」，而是「誰來治理所有工具、在每一次呼叫上、用一份稽核 軌跡」。 OrcaRouter 的答案是一個單一受稽核的咽喉要道。你註冊每個 MCP 伺服器一次；代理連接到一個閘道；每一次 tools/call 在抵達 真正的伺服器之前，都會透過防火牆引擎執行。 本頁是那個表面的地圖——閘道、每次呼叫的裁決、技能治理、egress 以及加密憑證—— 並附上各自的聚焦操作指南連結。
這裡的每一個管理動作都從主控台（或使用你的工作階段／存取權杖 透過 REST API）設定，並受角色控管。只有 /v1/* 轉送呼叫與防火牆閘道路由才攜帶 sk-orca-... 形式的金鑰。

​
1. 為何 mcp 安全需要一個閘道

讓十個代理直接指向五個社群 MCP 伺服器，你會得到 集所有壞處於一身的結果：沒有共享政策、沒有稽核軌跡、憑證被複製 到十個代理設定中，且一個名為 shell.exec 的工具離你的 雲端中繼資料端點只有一次重新導向之遙。閘道會把這些 收攏成一個受治理的連線。

一個連線，所有伺服器

代理連接到單一端點。閘道會在 <server>.<tool> 命名空間下 聚合每個已啟用、可觸及的伺服器的工具。

每次呼叫都有政策

每一次 tools/call 在派發前都會由你的防火牆政策評估。

加密憑證

伺服器驗證密鑰會在靜態時加密、讀取時遮罩，並在派發時 注入——它們永不會抵達模型或客戶端。

Egress 受控

已註冊伺服器的端點預設會對照內網與 雲端中繼資料 IP 範圍驗證。對於每工具的目的地，套用 基準 SSRF egress 拒絕清單，或撰寫你自己的 host／CIDR 規則。
關於這一切背後的基礎，請見 保護 AI 代理與 為何零信任。

​
2. 四個構件

OrcaRouter 上的 MCP 治理是四個協作的部分。挑選與你 想回答的問題相符的那一個。
一個你的代理連接的單一端點，取代直接撥接 伺服器。它會聚合每個已註冊伺服器的工具，以 <server>.<tool> 命名空間化，並逐字重新公開每個工具的輸入 schema。 從連接一個 MCP 伺服器與 驗證開始；完整參考位於 防火牆：MCP 伺服器。
閘道會在 mcp 表面上，於派發之前，將每一次 tools/call 透過防火牆執行並傳回一個裁決——allow、audit、deny、sanitize 或 pending_approval。請見 允許清單 MCP 工具與 淨化工具引數。
代理自我安裝的能力——技能、BYO MCP 伺服器、插件—— 會被掃描、指派一個風險等級，並被賦予一個強制執行模式 （allow / quarantine / block），凌駕於每一個規則 裁決之上。請見防火牆：技能與 Rug-pull 防禦。
每個伺服器的驗證密鑰會在靜態時加密並在讀取時遮罩。 請見驗證與 憑證輪替。

​
3. 一次 tools/call 如何被評估

當一個代理透過閘道呼叫一個工具時，該呼叫不會直接 送到伺服器。它會對照你的工作區政策進行匹配、其所屬技能的 強制執行模式會疊加套用，而只有 allow / audit / sanitize 裁決才會抵達真正的伺服器。
裁決代理看到什麼
allow / audit轉送。audit 也會記錄一個事件。
sanitize帶著被隱去的引數轉送（永不隱去結果）。
deny / pending_approval作為一個工具錯誤回傳，所以代理能適應而不是崩潰。
一個被封鎖的 MCP 呼叫會作為一個工具錯誤（firewall deny: …）回來， 與任何失敗工具回傳的形狀相同——代理可以用不同方式重試、 詢問使用者，或停止。那不是一次傳輸崩潰。
裁決詞彙、表面與規則匹配的完整文件記載於 防火牆與 防火牆規則之下；概念模型在 強制執行模式與 OrcaRouter 如何審查。

​
4. 註冊一個伺服器（一個具體範例）

你註冊每個伺服器一次。一筆伺服器記錄攜帶一個 name（每個工作區 唯一、不可有 .）、一個 endpoint、一個 auth_mode （none / bearer / oauth / basic），以及它的加密憑證。 從主控台做這件事——寫入需要 Developer+。 
# 主控台路由，以你的工作階段／存取權杖（UserAuth）呼叫。
curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer <your-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'
然後探測它以探索其工具並記錄可觸及性 （ok / degraded / down）： 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
現在你可以針對 github.* 撰寫規則，並確切知道 github.create_issue 接受什麼。端到端的逐步說明位於 連接一個 MCP 伺服器。
密鑰永不會以明文儲存。 auth_json 會在靜態時加密 並在讀取時遮罩；在更新時，把遮罩原樣回送以保留 已儲存的值。請見憑證輪替。

​
5. 將一個代理連接到閘道

一旦伺服器已註冊，用一個防火牆閘道範圍的金鑰將任何 MCP 客戶端 指向閘道（一個沒有那個範圍的權杖會得到 403）： 
https://api.orcarouter.ai/api/v1/firewall/mcp
閘道會說 streamable HTTP，並在 <server>.<tool> 命名空間下公告每個 已啟用、可觸及的伺服器的工具。一個自行代理呼叫的 SDK 可以用 同一個閘道權杖從 GET /api/v1/firewall/mcp_servers 讀取執行期註冊表。

​
6. 鎖定工具能觸及什麼

每次呼叫的裁決治理哪一個工具執行；egress 控制治理它可以觸及 何處。兩個層次協作。 首先，當閘道連接到一個已註冊伺服器的端點時，那個 URL 預設會對照內網（RFC1918）、loopback、link-local 與 雲端中繼資料範圍驗證——而且主機會被 DNS 解析，所以一個解析 進被封鎖範圍的名稱也會被拒絕。因此一個指向 169.254.169.254 或某個內網位址的 BYO 伺服器會被拒絕，除非你已 明確將它列入白名單。 其次，對於每工具的目的地，一條 egress 規則攜帶一個 host/CIDR allow/deny 清單，在 egress 表面上對照該呼叫的外向目的地匹配。 基準使用案例範本隨附一條現成的 egress deny 規則，其清單已涵蓋內網、loopback、 link-local 與雲端中繼資料範圍（包括 169.254.169.254 與 metadata.google.internal），所以套用它就給你 SSRF／中繼資料防禦， 而無需手動撰寫 CIDR。
SSRF 與 egress 是「這個工具回傳了資料」與 「這個工具把你的密鑰外洩到攻擊者主機」之間的差別。套用 基準 egress 拒絕清單並加上你自己的 host/CIDR 規則——請見 Egress 限制與 資料外洩。

​
7. 觀察它：事件、執行與異常

每一次受治理的呼叫都會留下軌跡。防火牆事件會記錄裁決、 表面與匹配的規則；執行會把一個工作階段的呼叫分組；異常 動態會對照一個學習而來的基準標示速率與成本尖峰。設定、 政策與探索到的工具的讀取對任何 Member 開放； 事件／執行／彙總讀取需要 Developer+。

​
8. 下一步去哪裡

連接一個 MCP 伺服器

註冊、探測，並透過閘道公開一個伺服器。

允許清單 MCP 工具

預設拒絕一個伺服器，只允許你審查過的工具。

Rug-pull 防禦

治理在你核准之後才變更的伺服器與技能。

防火牆：MCP 伺服器

完整的欄位與路由參考。
初次接觸這個模型？閱讀 防護欄 vs. 防火牆以了解 MCP 治理的定位，然後是 MCP 工具下毒與 過度代理權以了解它 封堵的威脅。