防火牆：MCP 伺服器

Model Context Protocol（MCP）讓代理能呼叫由外部伺服器託管的工具。那既強大又危險，兩者程度相當：代理連接的每個 MCP 伺服器，都是一組無人審查過的全新工具、憑證與網路觸及範圍。防火牆的 MCP 閘道在所有這些之前擺放一個單一受稽核的咽喉要道。你註冊每個 MCP 伺服器一次；閘道會在單一連線下將它們的工具公開給你的代理，並在每一次 tools/call 抵達真正的伺服器之前，將其透過防火牆引擎執行。

1. MCP 治理給你什麼

一個閘道，所有伺服器。 你的代理連接到一個端點。閘道會聚合每個可觸及的已註冊伺服器的工具，以 <server>.<tool> 命名空間化，所以 github.create_issue 與 shell.exec 會在單一 MCP 連線下並列顯示。
每次呼叫都有政策。 每一次 tools/call 會先由你的政策評估。一個被封鎖的呼叫會作為一個工具錯誤（firewall deny: …）回到模型，而不是傳輸失敗，所以代理能做出反應而不是崩潰。sanitize 會在轉送前改寫引數；pending_approval 會保留該呼叫。
SSRF 受防護。 遠端端點會對照閘道的 SSRF 政策驗證——內網範圍與雲端中繼資料位址會被封鎖，且解析出的撥接 IP 會被重新檢查以挫敗 DNS 重新綁定，在每一個躍點上（包括重新導向）。
加密憑證。 伺服器驗證密鑰會在靜態時加密並在讀取時遮罩。閘道會在派發時注入它們；它們永不會抵達模型或客戶端。

2. 兩種伺服器

種類	`endpoint`	行為
BYO（自帶）	一個 streamable-HTTP URL	閘道會將 `tools/call` 代理到你的遠端 MCP 伺服器。
Bundled（隨附）	空	OrcaRouter 的行程內 MCP 伺服器。註冊以使其可見且可治理；不可被個別探測。

3. 註冊一個伺服器

一筆伺服器記錄攜帶：

欄位	備註
`name`	業務鍵，每個工作區唯一，≤ 128 字元。不可有 `.`——它是 `<server>.<tool>` 命名空間分隔符。
`endpoint`	MCP 伺服器 URL（≤ 512 字元）。對隨附伺服器為空。
`auth_mode`	`none`（預設）、`bearer`、`oauth` 或 `basic`。
`auth_json`	模式特定的憑證（見下文）。每當 `auth_mode` 不是 `none` 時為必填。
`enabled`	預設為 `true`。一個停用的伺服器會完全從閘道中省略。
`status`	可觸及性——`ok`（預設）、`degraded` 或 `down`。由探測設定。

依模式劃分的憑證形狀：

// bearer
{ "token": "ghp_…" }
// oauth
{ "client_id": "…", "client_secret": "…", "token_url": "…" }
// basic
{ "username": "…", "password": "…" }
// none
""

一個註冊請求看起來像：

curl https://api.orcarouter.ai/api/workspace/firewall/mcp_servers \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "github",
    "endpoint": "https://api.githubcopilot.com/mcp",
    "auth_mode": "bearer",
    "auth_json": "{\"token\":\"ghp_x\"}",
    "enabled": true
  }'

在同一個工作區中重複的 name 會傳回 HTTP 409（在一個不同工作區中的同一個 name 則沒問題）。

密鑰永不會以明文儲存。 auth_json 會以一個工作區密鑰在靜態時加密。如果那個金鑰未設定，則寫入會被拒絕，而不是以未加密形式持久化一個憑證。在讀取時，密鑰與端點會被遮罩；在更新時把遮罩原樣回送以保留已儲存的值。在兩個帶憑證的驗證模式之間切換需要全新的 auth_json（密文與其模式形狀綁定）。

4. 探測——探索其工具

在你能針對一個伺服器的工具撰寫規則之前，你需要知道它們的名稱。探測該伺服器：

curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer sk-orca-..."

閘道會對該端點執行一次 MCP initialize + tools/list （使用解密後的憑證，以 10 秒為界），記錄可觸及性 status 與一個時間戳記，並傳回所公告的工具連同其輸入 schema：

{
  "status": "ok",
  "last_checked_at": 1700000000,
  "tools": [
    { "name": "create_issue", "description": "…", "input_schema": { } }
  ]
}

現在你可以撰寫像 tool_name_glob: github.* 這樣的規則，並確切知道 github.create_issue 接受什麼。隨附的（空端點）伺服器不可被探測，會傳回一個 400。

5. 生命週期與強制執行

已啟用 vs. 已停用。 一個停用的伺服器會從執行期註冊表中被丟棄——它的工具會從閘道中消失，它的憑證也永不會被解密。那就是關閉開關。
可觸及性。 status（ok / degraded / down）反映最近一次探測；一個無法觸及的伺服器在閘道建構其工具集時會被略過。
每次呼叫的裁決。 在派發時，引擎會針對特定的 <server>.<tool> 呼叫連同其引數傳回一個裁決：
- allow / audit → 轉送（audit 會記錄，但仍允許）。
- sanitize → 帶著被改寫的引數轉送。
- deny / pending_approval / 任何未知者 → 封鎖為一個工具錯誤。（透過統一閘道，一個被保留的呼叫會浮現為一個永久錯誤，而不是穿針引線地傳遞審批 id——當你需要審批握手時，請使用 evaluate hook。）
刪除是一個軟刪除；name 槽會立即被釋放，因此你可以用同一個 name 重新註冊。

每一次變更都會立即使閘道的每工作區工具快取失效，所以一個新註冊的、被停用的，或被重新探測的伺服器會在下次連線時生效，而不是在一個快取 TTL 之後。

6. 連接一個客戶端

用一個防火牆閘道範圍的權杖將任何 MCP 客戶端指向閘道端點：

https://api.orcarouter.ai/api/v1/firewall/mcp

閘道使用 streamable HTTP（POST 訊息、GET 用於 SSE 串流、DELETE 用於結束一個工作階段），並將自己識別為 orcarouter-firewall-gateway。它會在 <server>.<tool> 命名空間下公告每個已啟用、可觸及的伺服器的工具，並逐字重新公開每個工具的輸入 schema。一個沒有防火牆閘道範圍的權杖會得到 403——請為此鑄造一個專用的閘道權杖。

API 參考

主控台（工作區限定、RBAC）

方法與路徑	角色	用途
`GET /api/workspace/firewall/mcp_servers`	Member	列出伺服器（密鑰遮罩、端點隱去）。
`GET /api/workspace/firewall/mcp_servers/:id`	Member	單個伺服器，已遮罩。
`POST /api/workspace/firewall/mcp_servers`	Developer+	註冊一個伺服器（name 重複時回傳 409）。
`PUT /api/workspace/firewall/mcp_servers`	Developer+	更新一個伺服器（id 在主體中）。
`DELETE /api/workspace/firewall/mcp_servers/:id`	Developer+	軟刪除；釋放 name。
`POST /api/workspace/firewall/mcp_servers/:id/probe`	Developer+	探測可觸及性 + 探索工具。

閘道（防火牆閘道範圍的權杖）

方法與路徑	用途
`ANY /api/v1/firewall/mcp`	統一的 MCP 閘道派發端點。
`GET /api/v1/firewall/mcp_servers`	執行期註冊表（解密後的驗證，僅限已啟用的伺服器）供一個 SDK 代理使用。
`POST /api/v1/firewall/evaluate`	在你自己派發之前評估單一 `tools/call`。

FAQ

到底為什麼要把 MCP 透過 OrcaRouter 路由？

這樣就有一個地方能看見每一次工具呼叫。沒有閘道，每個代理會直接連接到每個 MCP 伺服器——沒有共享政策、沒有稽核軌跡、沒有 SSRF 防護，且憑證散落在各個代理設定中。閘道會把這一切集中化：一個連線、一個政策、一份受稽核的日誌、在派發時注入的加密密鑰。

當一個被封鎖的 MCP 呼叫回來時會發生什麼？

模型會把它收為一個工具錯誤（firewall deny: <reason>），與它從任何失敗工具會得到的形狀相同。那讓代理能適應——嘗試另一種方法、詢問使用者，或停止——而不是把它當作一次傳輸崩潰來處理。

我可以對每個伺服器以不同方式治理同一個工具嗎？

可以——那正是 <server>.<tool> 命名空間的用途。一條帶有 tool_name_glob: trusted.* 的規則可以 allow，而 community.* 則被 audit 或 pending_approval。把它與一個技能名稱 glob 結合以獲得更細緻的範圍限定。

閘道會防護 SSRF 嗎？

會。端點 URL 與其解析出的撥接 IP 會在註冊時以及在每一個派發躍點上對照 SSRF 政策驗證——內網範圍與雲端中繼資料位址會被拒絕，且解析出的 IP 會被重新檢查以挫敗 DNS 重新綁定。將它與一條 egress 規則搭配以治理工具可以觸及何處。

延伸閱讀

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

保護 MCP 伺服器（零信任）

在零信任姿態下連接、驗證並治理 MCP 伺服器。

MCP 信任檢查清單

在信任第三方 MCP 伺服器之前該驗證的事項。

​1. MCP 治理給你什麼

​2. 兩種伺服器

​3. 註冊一個伺服器

​4. 探測——探索其工具

​5. 生命週期與強制執行

​6. 連接一個客戶端

​API 參考

​主控台（工作區限定、RBAC）

​閘道（防火牆閘道範圍的權杖）

​FAQ

​延伸閱讀

保護 MCP 伺服器（零信任）

MCP 信任檢查清單

1. MCP 治理給你什麼

2. 兩種伺服器

3. 註冊一個伺服器

4. 探測——探索其工具

5. 生命週期與強制執行

6. 連接一個客戶端

API 參考

主控台（工作區限定、RBAC）

閘道（防火牆閘道範圍的權杖）

FAQ

延伸閱讀