OrcaRouter 如何检查每一个请求

网关坐落在你的智能体与它调用的每个模型之间。这使它 成为唯一一个能看到所有调用的点，无论提供商是谁——每一条 提示词、每一个响应、每一次工具调用，以及你的智能体通过它 路由的每一个出站请求——无论哪个 SDK 发出了调用。这个咽喉点 就是检查和执行所属之处。（它看不到的——一个完全在你的进程 内运行、从不穿越网关的工具——在§4中 有所介绍。） 本页精确解释网关能看到什么和不能看到什么，检测如何工作， 以及如何填补空白。

​

1. 为什么网关是正确的检查点

大多数安全控制存在于应用中：库包装器、智能体框架 hook、 每个提供商的 SDK。这些控制有一个致命的结构性缺陷——一旦 你添加第二个提供商、切换框架，或让智能体自安装一个新技能， 它们就会失效。 网关没有这些接缝。你的智能体发出的每一次调用，无论模型、 提供商或工具能力如何到达，都在到达上游之前经过一个单一 点。这是唯一可以做出保证的层：如果发生了，网关看到了。 OrcaRouter 利用这个位置进行两次不同的执行检查：

• 防护栏筛查文本——你的智能体发送的提示词和模型返回的 响应。防护栏拦截返回 HTTP 400 guardrail_blocked， 不消耗任何配额。
• 防火墙判断动作——智能体调用的工具、它访问的 MCP 服务器， 以及它报告的网络目的地。防火墙拒绝在 inbound 执行面上返回 HTTP 400 firewall_blocked，或在 MCP 执行面上返回工具 错误，因此模型能看到拒绝并可以对此进行推理。

两个层都在你的工作区中配置一次，并附加到 API 密钥。无需 重新部署。无需修改 SDK。你的智能体像以前一样继续调用 https://api.orcarouter.ai/v1。

​

2. 四个执行面

防火墙对照恰好一个执行面评估每一次工具调用——即网关在调用 生命周期中看到它的那个点。 防护栏在上述执行面之上增加了两个文本阶段：input（请求提示词 和消息）和 output（模型的响应文本）。一个请求可以通过所有这些。

​

3. 首次使用检测

这意味着新工具一出现在请求上，就会出现在 Discovered tools 视图中， 即使没有规则命名它。开启观察模式可以将没有匹配规则的每一次 工具调用记录为覆盖缺口——该视图从真实流量驱动策略编写。

​

4. 网关无法看到什么

检查保证涵盖穿越网关的调用。它不延伸到你的智能体完全在 其自己进程内运行的工具——读取本地文件、调用库函数或在 不向网关发送任何消息的情况下执行子进程的工具。 这是一个诚实的边界，不是设计缺陷。设计目标是使网关成为 重要调用的受审计路径——具有真实世界后果的那些： 如果你今天有在进程内运行且具有真实世界后果的工具，覆盖的路径是： 将它们注册为防火墙 MCP 网关后的 MCP 服务器， 或者在派发之前从你的智能体循环中调用 evaluate hook。

​

5. 检查数据的角色门控

访问检查执行面在你的工作区内受角色限定：

​

6. 下一步去哪里

网关是穿越它的每一次调用的单一检查点——配置你的策略一次， 每个提供商、每个智能体和每次工具调用都受到覆盖。