跳转到主要内容
一条 防火墙策略 对你的智能体发出的每一次工具调用 决定一件事：一个判定（verdict）。要么一条规则匹配并产生一个判定， 要么没有规则匹配而由策略的默认判定接管。本页涵盖两者——每个防火墙 判定做什么、cap_cost 如何解析，以及为什么 audit 是你从之起步的默认值。 关于判定在规则语法中的位置参见 防火墙规则；关于在创建策略时挑选一个默认 判定参见 创建与绑定。

​
1. 六个规则判定

一条规则恰好产生六个判定之一。在控制台规则编辑器中编写它们；引擎按 优先级顺序遍历规则，首个匹配生效。
该调用原封不动地继续。它仍会作为一个 allow 落入 事件信息流，因此你保留一份审计 追踪而不拦截任何东西。把它用作一条默认拒绝策略中的明确许可。
与 allow 流量结果相同，但该调用被标记为你想要观察的东西。这也是 默认判定开箱即用所落到的值——观察一切，不拦截任何东西，直到你 准备好执行。
该调用永远不会到达工具。在 inbound 执行面上中继返回 HTTP 400， 带有错误码 firewall_blocked，点名工具和原因；在 mcp 执行面上它 作为一个工具错误返回，因此模型能作出反应。参见 拦截的表现形式。
从工具调用参数（智能体放进一个 command 或 body 字段里的一个 密钥或 PII）中脱敏匹配的子串，并转发清理后的调用。它只脱敏参数—— 绝不脱敏工具返回的内容。在 inbound 执行面上还没有调用时参数，所以 sanitize 升级为一次 deny。参见 脱敏响应。
把该调用变成一次带外审查。中继返回 HTTP 400，带有码 firewall_approval_pending 和一个审批 id；该调用不会到达工具。一名 审查者在控制台中或通过 webhook 回调解决它，智能体携带一个一次性的 审批头重新提交。参见 审批。
一个成本断路器——作为一条规则编写，但在评估时解析为 allow 或 deny。参见 §3 与 封顶成本。
影子模式抹平执行。 在 影子模式 下， 每个执行性判定（deny、sanitize、pending_approval，以及一个解析为 deny 的 cap_cost）都被降级为 audit，原因前缀为 [shadow] would …。 以这种方式上线一条执行性策略，并在把它切换到实时之前观察事件信息流。

​
2. 默认判定

默认判定（策略上的 default_verdict）是当没有规则匹配一次工具调用 时策略所做的事。它是你姿态的底线，并且与一个规则判定不同，它只接受 三个值：
default_verdict当没有规则匹配时……
audit (默认)放行该调用，但记录它。安全的起点。
allow放行并记录，无审查记录。
deny拦截任何规则没有明确允许的东西——一种默认拒绝姿态。
一条新策略默认为 audit：它观察每一次工具调用，在你添加执行性规则 之前不拦截任何东西。三个仅限规则的判定——sanitize、pending_approval 和 cap_cost——不能作为默认值；默认判定是一个覆盖式回退，而那些判定 只在限定到一个特定匹配时才有意义。
deny 作为默认判定是默认拒绝：你的规则没有明确 allow 的任何工具 调用都会被拦截。对一个锁定的智能体很强大，但它会拦下你忘记加入白名单的 调用。把它与明确的 allow 规则搭配 （工具白名单），并先在 影子模式 下上线它。

​
3. cap_cost 解析为 allow 或 deny

cap_cost 是唯一一个不会出现在你事件中的判定。你编写一条带有 cap_cost_cents 上限的规则，但在评估时引擎在事件被记录之前把它解析为一个 具体的 allow 或 deny——所以 事件信息流 永远不携带一个字面的 cap_cost 判定，只有智能体实际看到的 allow/deny。 该上限是按智能体运行计的：引擎把该运行累积的花费与你的上限比较。
  • 在上限之下 → 解析为 allow。（在内部这被当作非匹配处理，因此 评估会继续到下一条规则，而不是让 cap_cost 以首个匹配赢得一个许可。）
  • 在上限之上 → 解析为 deny，原因点名该运行的总额相对于上限。这是 终端的、断路器式的结果。
// A rule that caps a run at $5.00 of accumulated spend.
{
  "label": "run cost ceiling",
  "tool_name_glob": "*",
  "verdict": "cap_cost",
  "cap_cost_cents": 500
}
cap_cost 只在派发前的执行面（inbound、mcp）上触发——即拦截一次调用 仍能防止花费的那些点。在派发后的 response 和 egress 执行面上它是惰性的 （已没有东西可阻止），所以引擎在那里跳过它。

​
4. 一个判定是如何被选中的

对于任何一次工具调用，无论哪个判定胜出，解析都是相同的：
网关挑选绑定到发起调用的密钥的策略（firewall_policy_id），或工作区 默认值——参见 解析。
规则以 priority ASC 顺序运行。第一条其执行面、工具 glob、可选参数 子句以及可选 egress 范围全部匹配的规则产生判定。
如果没有规则匹配，则应用策略的 default_verdict——除非你改过它， 否则为 audit。
如果该调用归属于一个受治理的 技能，则一个 block 模式的技能强制 deny，而一个 quarantine 模式的技能把任何 未到 deny 程度的判定升级为 pending_approval。

​
5. 一次 deny 的成本与重试行为

inbound 执行面上的一个防火墙判定在上游模型调用之前触发，所以那里的 一个 deny 不消耗任何模型 token。该错误被标记为 skip-retry——重新 运行同一个被拦截的调用只会再次被拦截，所以网关告诉客户端不要重试它。 这与一次 防护栏 拦截不同， 后者筛查提示词/响应的文本（PII、密钥）而非工具动作，并返回它自己的 guardrail_blocked 错误。一个请求可以穿过两个平面。
每个判定都留下踪迹。 每一次评估——allow、audit、deny、已解析的 cap_cost、被挂起的审批——都被记录为一个防火墙事件，可按判定、执行面、 工具和运行过滤。事件信息流是你确认一条策略正在产生你预期判定的方式。 参见 事件日志 与 分析。

​
接下来去哪里

创建并绑定一条策略

挑选一个默认判定并把一条策略绑定到一个密钥。

封顶成本

编写一个花费上限以及它如何按运行解析。

影子模式

在你衡量影响时把每个执行性判定降级为审计。

规则参考

一个判定背后的完整匹配语言。
关于这些判定意在阻止的威胁，参见 危险工具调用 与 过度代理。