按策略允许列表 MCP 工具

一个已注册的 MCP 服务器声明它想声明的任何工具——而一个智能体会 乐于调用其中的任何一个。安全的姿态是反过来的：决定你实际需要的 那张短工具列表，恰好允许那些，并拒绝其余的。那就是一个 允许列表（allow-list），而在 OrcaRouter 上你用在 mcp 面上 评估的 tool_name_glob 规则来构建它。 每一次穿过 MCP 网关 的 tools/call 都在 到达真实服务器之前通过你的 防火墙策略 运行。所以这个允许列表不是建议性的——一次对你没有允许的工具的 调用永不派发。

​

1. 为什么要为安全的 mcp 工具做默认拒绝的允许列表

一个拒绝列表——“拦截危险的工具”——在一个服务器添加一个新工具、 重命名一个，或你连接第二个服务器的那一刻就失效。危险工具的集合是 开放式的；你打算使用的集合是小而已知的。一个允许列表把默认翻转 过来，因此未知被拒绝，而不是被准入：

• 新工具默认被拒绝。 一个在你连接之后长出一个 delete_repo 工具的服务器，在你把它添加到允许列表之前无法被调用。
• 范围按服务器划分。 <server>.<tool> 命名空间让你能允许 github.create_issue，同时拒绝 github.* 下的其他一切。
• 一个咽喉点。 同一条策略治理网关后面捆绑的服务器和每一个 BYO 服务器，因此有一个地方可以读取允许列表。

​

2. 两个部件

一个允许列表是一个 default_verdict 加一组有序的规则。 glob 对照带命名空间的工具名匹配——github.create_issue、 shell.exec。* 匹配任何工具（少用它；一条带 * 的 allow 规则会 撤销整个允许列表）。一个前导的 <server>. 把 glob 限定到一个服务器。

​

3. 一个具体例子

你连接了一个 github 服务器，而你只想让智能体读取和开启 issue ——绝不删除或管理任何东西。在控制台，打开 Firewall → Policies， 把策略的默认判定设为 deny，并添加两条 allow 规则： 那就是整个允许列表。默认在 deny：

• github.create_issue → 匹配规则 1 → allow，派发。
• github.delete_repo → 什么也不匹配 → 默认 deny。

一次被拒绝的 MCP 调用作为一个工具错误（firewall deny: …）回到 模型——与任何失败工具返回的形态相同——因此智能体能适应而不是崩溃。 （在 inbound 面上，一次 deny 反而是一个带错误码 firewall_blocked 的 HTTP 400。）

​

4. 用参数收紧

一个在允许列表上的工具名仍然可能被用坏参数调用。通过给规则添加 一个 args_match 子句（JSONPath + 一个像 eq、contains、regex、 in 或 cidr_match 的运算符），或者通过在 allow 之上叠加一条针对 特定参数形状的 deny 规则，来进一步收窄——例如，允许 github.create_issue 但在目标 repo 不在一个批准列表上时 deny 它。 完整的运算符集参见 防火墙规则参考。

​

5. 安全地推出它

在生产中翻转一个整服务器的默认拒绝，你就有风险破坏一个悄悄依赖 某个你忘了的工具的智能体。两个设置给它降险： 一旦 shadow 日志干净——没有一次合法的调用本会被拒绝——清除 shadow_mode，允许列表就执行。

​

6. 验证它有效

执行之后，确认被拒绝的工具确实被拒绝：

• **Dry-run（试运行）**一次 tools/call 对照策略（Developer+），以 看到判定以及哪条规则——或默认——产生了它，而不发送真实流量。 传入一个工具名、面和样本参数；引擎评估它们并返回判定轨迹而不 记录一个事件。
• 观察事件。 每一次被拦截的调用记录一个 Developer+ 可以在 控制台读取的防火墙事件； 审计事件 页涵盖该信息流及其字段。

​

相关