跳轉到主要內容
一個第三方 MCP 伺服器是一捆未審查的工具、一份即時憑證， 以及全新的網路觸及範圍。代理直接撥接其中一個的那一刻，沒有人 在看那次呼叫——而「該伺服器在你核准後變更它的工具」 是一個真實的攻擊，不是一個假設。在你把一個代理指向一個 別人營運的伺服器之前，你想要一個可重複的飛行前檢查。 本頁就是那個飛行前檢查：一份簡短、有序的檢查清單，用已經存在的 控制——每次呼叫評估、預設拒絕允許清單、egress 限制、加密憑證， 以及技能隔離——在 OrcaRouter 上審查 mcp server 連線。每一步都連結到聚焦的操作指南以求深入。每個新伺服器 執行一次；每當該伺服器變更時，重新執行對漂移敏感的步驟。
這裡的每一個設定步驟都從主控台（或使用你的 工作階段／存取權杖透過 REST API）完成，並受角色控管。只有防火牆 閘道路由與 /v1/* 轉送呼叫才攜帶一個 sk-orca-... 形式的金鑰。

​
1. 審查 mcp server 連線的檢查清單

由上而下進行。前三步對任何你不自己營運的伺服器 都是必須的；其餘的強化它。

1. 在信任之前探測

在撰寫一條規則之前先探索真實的工具清單與 可觸及性。

2. 預設拒絕，然後允許清單

只允許你審查過的工具；其他一切被拒絕。

3. 加密憑證

儲存驗證使它在靜態時加密、讀取時遮罩、永不被 模型看見。

4. 鎖定 egress

約束該伺服器的工具可以在網路上觸及何處。

5. 隔離自我安裝的技能

保留代理自行安裝的任何東西，直到一個人審查它。

6. 先 shadow，再觀察

以僅稽核推出，然後在強制執行前讀取事件與異常。

​
2. 在信任之前探測

你無法審查你從未見過的工具，而一個伺服器的所公告工具 清單是最可能在你底下變更的東西。註冊該伺服器，然後 探測它——閘道會對該端點執行一次 MCP initialize + tools/list 並傳回真實的工具連同它們的輸入 schema，加上一個 ok、degraded 或 down 的可觸及性 status。 
# 主控台路由，以你的工作階段／存取權杖（UserAuth）呼叫。Developer+。
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
讀取每一個工具名稱以及它的引數接受什麼。一個公告一個 你不預期的 shell.exec 或一個 http_fetch 的伺服器是一個發現，不是一個 細節——那就是先探測的全部重點。
每當一個伺服器易手或你懷疑漂移時，重新探測。一個新工具 出現在清單中——「rug pull」——正是你在留意的。 請見 Rug-pull 防禦。
完整的註冊與探測參考位於 防火牆：MCP 伺服器；端到端的逐步說明是 連接一個 MCP 伺服器。

​
3. 預設拒絕，然後允許清單你審查過的工具

一個允許清單是「該伺服器可以做六件事」與 「該伺服器可以做它的營運者明天決定的任何事」之間的差別。把政策的 default_verdict 設為 deny，然後為你審查並信任的每個工具加上一條規則。 因為閘道把每個工具命名空間化為 <server>.<tool>，你可以把 規則限定到一個伺服器而不觸及其他的。 
// mcp 表面上的政策：預設拒絕，只允許你審查過的。
// tool_name_glob 支援一個整段萬用字元："github.*"（前綴）、
// "*.exec"（後綴），或 "*.shell.*"（中綴）。像
// "github.get_*" 這樣的段中 glob 會退回到精確匹配且不會展開。
{
  "default_verdict": "deny",
  "rules": [
    { "tool_name_glob": "github.create_issue", "verdict": "allow" },
    { "tool_name_glob": "github.get_issue",    "verdict": "allow" }
  ]
}
現在 github.create_issue 執行、github.get_issue 執行，而一個 新引入的 github.delete_repo 在你審查並允許它之前被拒絕。 一個被拒絕的 tools/call 會作為一個工具錯誤回到模型 （firewall deny: …）——代理適應而非崩潰。 關於完整的食譜，請見 允許清單 MCP 工具， 而關於匹配 DSL，請見 防火牆規則。

​
4. 加密憑證——絕不手工搓驗證

一個第三方伺服器幾乎總是需要一份憑證，而一份憑證是 你最不想坐在明文中或抵達模型的東西。透過 OrcaRouter 註冊 該伺服器的驗證，使它在靜態時加密、讀取時遮罩，並只在派發時 注入。 auth_mode 是 none、bearer、oauth 或 basic 之一： 
# 主控台路由，UserAuth，Developer+。
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\"}"
  }'
憑證在它被儲存的那一刻就被加密並遮罩——它永不 抵達模型或客戶端，而在讀取時你只會看到遮罩。在一次 更新時，把遮罩原樣回送以保留已儲存的值；只有當你在輪替時才 送出全新的 auth_json。請見 驗證與 憑證輪替。

​
5. 鎖定 egress：它的工具可以觸及何處？

每次呼叫的裁決決定哪一個工具執行；egress 決定它可以 觸及何處。一個「回傳資料」的工具與一個「把你的密鑰外洩到 攻擊者主機」的工具可以是同一個工具帶著不同的引數——egress 控制就是告訴它們的差別的。 閘道已經在每一個躍點對照一個 SSRF 政策驗證每個遠端端點 及其解析出的撥接 IP，拒絕內網範圍與 雲端中繼資料位址並重新檢查該 IP 以挫敗 DNS 重新綁定。在 那之上，為這個伺服器永不該觸及的主機與 CIDR 撰寫你自己的 egress deny 規則： 
// 一條 egress-stage 規則把它的裁決限定到外向目的地。
// egress_json 攜帶 host/CIDR allow + deny 清單。
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"10.0.0.0/8\"]}"
}
沒有預設會為你出貨 CIDR 規則——你自己撰寫 host/CIDR deny 清單，限定到這個伺服器合法需要的。請見 Egress 限制與 資料外洩。

​
6. 隔離代理自行安裝的東西

你註冊的伺服器是一個風險；代理之後自我安裝的 技能、BYO MCP 伺服器與插件是另一個。OrcaRouter 會掃描每一個 可安裝的能力、為它指派一個風險等級，並推導一個強制執行 模式——allow、quarantine 或 block——凌駕於每一個規則 裁決之上。 任何在首次使用時自動偵測的東西都會被隔離直到一個人審查 它：一個沒有人核准的能力不會只因為它掃描良性就得到一個 免費通行證。一個 quarantine 能力會把任何不到 deny 的東西升級 到 pending_approval，所以它的工具只在你看過之後才執行。
不要試圖手動註冊每一個技能。預先核准你信任的那些， 讓其餘的被自動偵測並隔離——然後從真實資料審查。 該模式在重新掃描時更緊，永不更鬆。請見 防火牆：技能與 MCP 工具下毒。

​
7. 先 shadow，再觀察軌跡

不要把一個全新的伺服器直接翻轉為強制執行。把政策放入 shadow 模式——強制執行裁決被降級為 audit 並記錄為 [shadow] would …——所以你能在它實際發生之前看見本應被封鎖的內容。 當稽核軌跡看起來正確時，移除 shadow 模式並強制執行。 在它上線後，這些控制持續監看：
每一次受治理的呼叫會記錄它的裁決、表面與匹配規則。讀取 它們以確認允許清單與 egress 規則如預期運作。請見 稽核 MCP 事件。
對照一個學習而來的基準的速率與成本尖峰，加上重試迴圈與 新穎的工具路徑，會浮現為異常——任何 Member 皆可讀取。
打開 observe 模式以把一個政策尚未涵蓋的呼叫記錄為缺口，所以 你從一個代理實際做什麼來收緊，而非從猜測。

​
8. 快速路徑：挑選一個自主等級

如果你寧願不為一個你不完全信任的伺服器手工建構步驟 3–5， 套用一個自主等級並從那裡編輯。這些等級會寫真實、可編輯的 政策與防護欄列——它們是一個起點，不是一個黑盒：
等級它設定什麼
permissiveObserve 模式開啟——記錄一切、強制執行什麼都不做。
balanced拒絕破壞性 shell 的預設稽核政策，加上 flag-only 模式的 PII Shield 防護欄。
tight拒絕破壞性 shell 與 fetch 形狀工具（http_fetch/web_search/fetch_url/request——SSRF 載體）的預設拒絕政策，加上強制執行的 PII Shield 與 Secrets Blocker 防護欄。引數中的密鑰由請求上的 Secrets Blocker 防護欄抓住，而非由一條工具引數規則。
對一個你還在審查的第三方伺服器，從 tight 開始、探測，然後 把特定工具放鬆進一個允許清單。一鍵還原會恢復 套用前的快照。
設定、政策、探索到的工具、異常、已註冊 MCP 伺服器與技能的讀取對任何 Member 開放；事件、執行與彙總 讀取需要 Developer+，而每一次寫入都需要 Developer+。 揭露一個權杖的明文金鑰也是 Developer+。

​
9. 下一步去哪裡

連接一個 MCP 伺服器

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

允許清單 MCP 工具

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

Rug-pull 防禦

抓住一個在你核准後變更的伺服器或技能。

MCP 安全總覽

MCP 治理表面的完整地圖。
初次接觸這個模型？閱讀 防護欄 vs. 防火牆以了解 MCP 治理的定位，然後是 過度代理權 與 危險的工具呼叫以了解 這份檢查清單封堵的威脅。