跳转到主要内容
一个说 Model Context Protocol（MCP）的 智能体，其安全性不会超过它所连接的服务器。每一个 MCP 服务器都是 一组全新的工具、一份全新的凭据、一段全新的网络可达性——而智能体 直接拨入其中一个的那一刻，没人在看那次调用。这正是 mcp 安全 必须解决的全部问题：不是”这一个工具安全吗”，而是”谁来治理 所有这些工具，在每一次调用上，用一份审计轨迹。” OrcaRouter 的答案是一个单一的、受审计的咽喉点。你把每个 MCP 服务器注册一次；智能体连接到一个网关；并且每一次 tools/call 都在到达真实服务器之前通过 防火墙引擎 运行。 本页是这个面的地图——网关、每次调用的判定、技能治理、出站， 以及加密凭据——并为每一部分链接到聚焦的操作指南。
这里的每一个管理操作都从控制台（或使用你的会话/访问令牌的 REST API）配置，并且受角色门控。只有 /v1/* 中继调用和防火墙 网关路由才携带 sk-orca-... 样式的密钥。

​
1. 为什么 mcp 安全需要一个网关

把十个智能体直接指向五个社区 MCP 服务器，你会得到各种最坏情况 的总和：没有共享策略、没有审计轨迹、凭据被复制进十份智能体配置， 还有一个名为 shell.exec 的工具距离你的云元数据端点只有一次重定向。 网关把这一切收拢成一个受治理的连接。

一个连接，所有服务器

智能体连接到单一端点。网关在一个 <server>.<tool> 命名空间下 聚合每一个已启用、可达服务器的工具。

每次调用都有策略

每一次 tools/call 都在派发前由你的防火墙策略评估。

加密凭据

服务器鉴权密钥被静态加密、读取时屏蔽，并在派发时注入—— 它们永不到达模型或客户端。

出站受控

一个已注册服务器的端点默认会对照内网与云元数据 IP 范围校验。 对于每工具的目的地，应用基线 SSRF 出站拒绝列表或编写你自己的 主机/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
  }'
然后**探测（probe）**它以发现它的工具并记录可达性 （ok / degraded / down）： 
curl -X POST \
  https://api.orcarouter.ai/api/workspace/firewall/mcp_servers/42/probe \
  -H "Authorization: Bearer <your-access-token>"
现在你可以在确切知道 github.create_issue 接受什么的情况下， 针对 github.* 编写规则。端到端的演练在 连接一个 MCP 服务器。
密钥永不以明文存储。 auth_json 被静态加密并在读取时屏蔽； 在更新时，把屏蔽值原样回传即可保留已存储的值。参见 凭据轮换。

​
5. 把一个智能体连接到网关

服务器注册好之后，用一个 firewall-gateway-scoped 密钥 （一个没有该 scope 的令牌会得到 403）把任意 MCP 客户端指向网关： 
https://api.orcarouter.ai/api/v1/firewall/mcp
网关使用 streamable HTTP，并在 <server>.<tool> 命名空间下声明 每一个已启用、可达服务器的工具。一个自己代理调用的 SDK 可以用 同一个网关令牌从 GET /api/v1/firewall/mcp_servers 读取运行时注册表。

​
6. 封锁工具能触及什么

每次调用的判定治理哪个工具运行；出站控制治理它可以触及哪里。 两个层协作。 首先，当网关连接到一个已注册服务器的端点时，该 URL 默认会 对照内网（RFC1918）、回环、链路本地和云元数据范围校验——并且 主机会被 DNS 解析，因此一个解析进被拦截范围的名字也会被拒绝。 所以一个指向 169.254.169.254 或内网地址的 BYO 服务器会被拒绝， 除非你明确把它列入白名单。 其次，对于每工具的目的地，一条出站规则携带一个主机/CIDR allow/deny 列表，在 egress 面上对照该调用的出站目的地匹配。 基线用例模板自带一条现成的出站 deny 规则，其列表已经覆盖了内网、 回环、链路本地和云元数据范围（包括 169.254.169.254 和 metadata.google.internal），所以应用它就能让你获得 SSRF/元数据 防御，而无需手写 CIDR。
SSRF 和出站是”这个工具返回了数据”与”这个工具把你的密钥外泄到了 攻击者的主机”之间的区别。应用基线出站拒绝列表并添加你自己的 主机/CIDR 规则——参见 出站限制 和 数据外泄。

​
7. 观察它：事件、运行和异常

每一次受治理的调用都留下一条轨迹。防火墙事件记录判定、面和 匹配的规则；运行把一次会话的调用分组；异常信息流对照一个学习到的 基线标记速率和成本激增。设置、策略和已发现工具的读取对任何 Member 开放；事件/运行/聚合的读取需要 Developer+。
  • 审计 MCP 事件 —— 记录了什么以及 如何读取它。
  • 信任清单 —— 在你放任一个智能体 使用一个新服务器之前的预检。

​
8. 下一步去哪里

连接一个 MCP 服务器

通过网关注册、探测并暴露一个服务器。

允许列表 MCP 工具

默认拒绝一个服务器，只放行你已审查过的工具。

Rug-pull 防御

治理在你批准之后发生变化的服务器和技能。

防火墙：MCP 服务器

完整的字段与路由参考。
对这个模型还不熟悉？读 防护栏 vs. 防火墙 看看 MCP 治理落在哪里，然后读 MCP 工具投毒 和 过度代理权 了解它所关闭的威胁。