跳转到主要内容
一条防火墙规则在一次工具调用生命周期中的某个特定点触发。那个点就是它 的执行面（stage）——四个执行面之一，每个看到该调用的不同切片。把一条 规则钉到错误的执行面，它就会看到错误的数据：一个 egress 白名单放在 inbound 执行面上没有目的地可检查；一个参数子句放在 inbound 上还没有 调用时参数。 本页是关于四个智能体防火墙执行面的聚焦指南：每个执行面观察什么、一条 规则何时应该针对它，以及同一意图在不同执行面上表达的那一种具体方式。 完整的规则词汇表参见 防火墙规则；围绕它的 策略模型参见 防火墙。

​
1. 四个执行面一览

每一次评估都被打上恰好一个执行面的标记。一条没有执行面（""）的规则 适用于所有执行面；一条钉在某一个执行面上的规则只在那里触发。
执行面该执行面看到什么
inbound智能体在请求上声明的工具
response模型在其回复中发出的 tool_calls
mcp通过 MCP 网关派发的一次 tools/call
egress某个工具触及的一个出站 host / IP / CIDR
执行面名称是稳定的枚举值——你在规则编辑器的执行面字段中逐字设置它们， 或在通过 API 编写时作为 stage 属性设置。
执行面治理的是哪些数据在范围内，而非判定有多严格。deny 在任何 执行面上都是 deny；改变的是该规则是否拥有它需要匹配的参数、工具名或 目的地。

​
2. inbound —— 智能体声明的工具

最早的执行面。在模型运行之前，你的智能体会发送一个它愿意让模型调用的 工具定义列表。inbound 执行面看到那个被声明的工具集，并能在模型 甚至还没能选中它之前拦截一个危险工具。 此执行面上没有调用时参数——模型还没决定如何调用任何东西——所以 inbound 规则匹配工具名（以及可选地它所属的技能），而非 args_match_json。
inbound 上的一个 sanitize 判定没有东西可脱敏（此时还不存在参数）， 所以它升级为拦截。把 inbound 规则编写为明确的 allow / deny，并把 sanitize 留给执行阶段。
此处一次被拒绝的调用返回 HTTP 400，带有 firewall_blocked 码，以工具 和原因命名，并被标记为 skip-retry。

​
3. response —— 模型发出的工具调用

一旦模型回复，它可能发出一个或多个 tool_calls——带有真实参数的具体 调用。response 执行面看到那些，所以这里是参数级别规则所属之处： 不是”拦截 shell.exec”，而是”只在命令是 rm -rf 时拦截 shell.exec”。 
{
  "stage": "response",
  "tool_name_glob": "shell.exec",
  "verdict": "deny",
  "args_match_json": "{\"clauses\":[{\"path\":\"$.command\",\"op\":\"regex\",\"value\":\"rm -rf|mkfs|dd if=\"}]}"
}
因为模型选中的参数存在，所以 sanitize 在这里能工作——它从调用的参数 中脱敏匹配的子串并转发清理后的调用。（Sanitize 只脱敏工具调用参数； 它绝不触碰工具返回的内容。）

​
4. mcp —— 通过网关派发的调用

当一个智能体通过 OrcaRouter 的 MCP 网关 触及 一个工具时，每一次 tools/call 都会在它被派发到已注册服务器之前在 mcp 执行面上被评估。这是治理 Model Context Protocol 流量的执行面——与 response 相同的 glob / 参数 / 判定词汇表，应用于 MCP 派发。 此处的一次拦截会作为一个工具错误（firewall deny: <reason>）浮现， 而非一次传输失败，因此模型能看到这次拒绝并作出反应——换一个工具、 询问用户，或者停止。
mcp 执行面与逐服务器治理搭配：每个已注册的 MCP 服务器都有它自己的 健康探针和加密凭据，而通过它加载的技能携带一个风险等级和一个执行模式。 参见 防火墙 MCP 与 防火墙技能。

​
5. egress —— 工具触及的出站目的地

最后一个执行面。当一个工具报告一个出站网络目的地时，egress 执行面对 它进行匹配——即 SSRF 与数据外泄的执行面。Egress 规则不仅靠一个工具名 模式匹配；它们匹配一个 host / IP / CIDR 列表： 
{
  "stage": "egress",
  "verdict": "deny",
  "egress_json": "{\"deny\":[\"169.254.169.254\",\"10.0.0.0/8\"],\"allow\":[\"api.openai.com\"]}"
}
条目以 CIDR、IP 字面量或大小写不敏感的主机名进行匹配。你自己编写 host 和 CIDR 拒绝规则——云元数据端点（169.254.169.254）和 RFC-1918 范围是 要拒绝的标准对象。关于 allow/deny 极性参见 防火墙规则 §6。
没有任何预设附带 CIDR 规则。tight 自治级别 的 SSRF 姿态拒绝的是 fetch 形态的工具名（例如 http_fetch、 web_search、fetch_url）；一个基于目的地的 egress 拒绝是你为你的智能体 绝不能触及的主机和范围编写的东西。

​
6. 选择正确的执行面

同一个安全目标往往有一个最佳执行面。把意图匹配到实际承载你所需数据 的那个执行面：
如果模型甚至永远不应该看到一个工具，就在 inbound 上拒绝它。该 拦截落在模型调用之前，所以它不消耗任何模型 token。
参数子句需要模型选中的参数，而那些只在 response 和 mcp 上存在。 在一个危险参数上拒绝，或者用 sanitize 剥除智能体放进某个参数里的 一个密钥或 PII 值。
通过 MCP 网关路由的调用会在派发前于 mcp 上被评估——每个已注册 服务器工具的咽喉点。
基于目的地的规则——拦截云元数据 IP、拒绝一个 CIDR、把你批准的主机 加入白名单——只在 egress 上才有意义。
一条没有执行面的规则在全部四个上运行。把它用于一条覆盖式的 default_verdict 风格规则，或一个你在它出现的所有地方都拒绝的工具。

​
7. 执行面与影子模式

一条策略的 shadow_mode 标志与执行面无关。把它打开，那么任何执行面上 的每个执行性判定——都被降级为 audit，原因前缀为 [shadow] would …， 这样你就能在一条规则改变实时流量之前先确认它在正确的执行面上触发。参见 影子模式 与 执行模式。

​
8. 执行面在全局图景中的位置

四个执行面是执行的在哪里；模型的其余部分则是做什么和谁来做。

判定

每个执行面在匹配后能做什么——allow、audit、deny、sanitize、挂起等待 审批、封顶成本。

工具白名单

用 inbound 来约束智能体声明的工具集。

验证参数

编写按工具如何被调用来对其设门的 response / mcp 参数子句。

Egress 控制

在 egress 执行面上拦截出站目的地——即外泄边界。
关于这些执行面如何位于检查路径上，参见 OrcaRouter 如何检查 以及 执行路径延迟 说明。关于 每个执行面应对的威胁，参见 危险工具调用、 数据外泄 与 MCP 工具投毒。