防火墙：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
  }'

同一工作区内的重名会返回 HTTP 409（在不同工作区中使用同一名称是可以的）。

密钥永不以明文存储。 auth_json 用一个工作区密钥静态加密。如果未配置该密钥，写入会被拒绝，而不是以未加密形式持久化一个凭据。读取时，密钥和端点会被屏蔽；在更新时把屏蔽值原样回传即可保留已存储的值。在两个带凭据的鉴权模式之间切换需要全新的 auth_json（密文与其模式形态绑定）。

4. Probe——发现它的工具

在你能针对一个服务器的工具编写规则之前，你需要知道它们的名称。**Probe（探测）**该服务器：

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

网关会针对该端点运行一次 MCP initialize + tools/list（使用解密后的凭据，以 10s 为界），记录可达性 status 和一个时间戳，并返回声明的工具及其输入 schema：

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

现在你可以在确切知道 github.create_issue 接受什么的情况下，编写像 tool_name_glob: github.* 这样的规则。捆绑的（空端点）服务器不可探测，会返回 400。

5. 生命周期与执行

启用 vs. 禁用。 一个被禁用的服务器会从运行时注册表中被剔除——它的工具从网关中消失，它的凭据永不被解密。这是关闭开关。
可达性。 status（ok / degraded / down）反映最近一次探测；当网关构建它的工具集时，一个不可达的服务器会被跳过。
每次调用的判定。 在派发时，引擎为带参数的特定 <server>.<tool> 调用返回一个判定：
- allow / audit → 转发（审计记录，仍然放行）。
- sanitize → 携带被改写的参数转发。
- deny / pending_approval / 任何未知值 → 作为一个工具错误拦截。（通过统一网关，一次被挂起的调用会以一个永久错误浮现，而不是传递审批 id——当你需要审批握手时请使用 evaluate hook。）
删除是一次软删除；名称槽位会立即被释放，因此你可以用同一名称重新注册。

每一次变更都会立即使网关的按工作区工具缓存失效，因此一个新注册、被禁用或重新探测的服务器会在下一次连接时生效，而不是等到一个缓存 TTL 之后。

6. 连接一个客户端

用一个 firewall-gateway-scoped 令牌把任意 MCP 客户端指向网关端点：

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

网关使用 streamable HTTP（POST 消息、GET 用于 SSE 流、DELETE 用于结束一个会话），并将自身标识为 orcarouter-firewall-gateway。它在 <server>.<tool> 命名空间下声明每一个已启用、可达的服务器的工具，逐字重新暴露每个工具的输入 schema。一个没有 firewall-gateway scope 的令牌会得到 403——请为此铸造一个专用的网关令牌。

API reference

控制台（工作区限定，RBAC）

方法与路径	角色	用途
`GET /api/workspace/firewall/mcp_servers`	Member	列出服务器（密钥屏蔽，端点脱敏）。
`GET /api/workspace/firewall/mcp_servers/:id`	Member	单个服务器，已屏蔽。
`POST /api/workspace/firewall/mcp_servers`	Developer+	注册一个服务器（重名时返回 409）。
`PUT /api/workspace/firewall/mcp_servers`	Developer+	更新一个服务器（id 在 body 中）。
`DELETE /api/workspace/firewall/mcp_servers/:id`	Developer+	软删除；释放名称。
`POST /api/workspace/firewall/mcp_servers/:id/probe`	Developer+	探测可达性 + 发现工具。

网关（firewall-gateway-scoped 令牌）

方法与路径	用途
`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. Probe——发现它的工具

​5. 生命周期与执行

​6. 连接一个客户端

​API reference

​控制台（工作区限定，RBAC）

​网关（firewall-gateway-scoped 令牌）

​FAQ

​另请参阅

保护 MCP 服务器（零信任）

MCP 信任清单

1. MCP 治理给你什么

2. 两类服务器

3. 注册一个服务器

4. Probe——发现它的工具

5. 生命周期与执行

6. 连接一个客户端

API reference

控制台（工作区限定，RBAC）

网关（firewall-gateway-scoped 令牌）

FAQ

另请参阅