Skip to main content
A firewall policy decides one thing about every tool call your agent makes: a verdict. Either a rule matches and produces a verdict, or no rule matches and the policy’s default verdict takes over. This page covers both — what each firewall verdict does, how cap_cost resolves, and why audit is the default you start from. For where verdicts live in the rule grammar see Firewall Rules; for picking a default verdict while creating a policy see Create & attach.

​
1. The six rule verdicts

A rule produces exactly one of six verdicts. Author them in the console rule editor; the engine walks rules in priority order and the first match wins.
The call proceeds untouched. It still lands in the events feed as an allow, so you keep an audit trail without blocking anything. Use it as an explicit permit in a default-deny policy.
Identical traffic outcome to allow, but the call is flagged as something you wanted to watch. This is also the value the default verdict lands on out of the box — observe everything, block nothing, until you’re ready to enforce.
The call never reaches the tool. On the inbound surface the relay returns HTTP 400 with error code firewall_blocked, naming the tool and the reason; on the mcp surface it comes back as a tool error so the model can react. See what a block looks like.
Redacts matched substrings from the tool-call arguments (a secret or PII the agent put in a command or body field) and forwards the cleaned call. It redacts arguments only — never the content a tool returns. On the inbound surface there are no call-time arguments yet, so sanitize escalates to a deny. See sanitize responses.
Turns the call into an out-of-band review. The relay returns HTTP 400 with code firewall_approval_pending and an approval id; the call does not reach the tool. A reviewer resolves it in the console or via webhook callback, and the agent re-submits with a single-use approval header. See approvals.
A cost circuit-breaker — authored as a rule but resolved to allow or deny at evaluation time. See §3 and cap cost.
Shadow mode flattens enforcement. In shadow mode, every enforcing verdict (deny, sanitize, pending_approval, and a cap_cost that resolved to deny) is downgraded to audit and the reason is prefixed [shadow] would …. Roll an enforcing policy out this way and watch the events feed before you flip it live.

​
2. The default verdict

The default verdict (default_verdict on the policy) is what the policy does when no rule matches a tool call. It is the floor of your posture, and unlike a rule verdict it accepts only three values:
default_verdictWhen no rule matches…
audit (default)Allow the call, but record it. The safe place to start.
allowAllow and log, no review record.
denyBlock anything a rule doesn’t explicitly permit — a default-deny posture.
A new policy defaults to audit: it observes every tool call and blocks nothing until you add enforcing rules. The three rule-only verdicts — sanitize, pending_approval, and cap_cost — cannot be a default; a default verdict is a blanket fallback, and those verdicts only make sense scoped to a specific match.
deny as a default verdict is default-deny: any tool call your rules don’t explicitly allow is blocked. Powerful for a locked-down agent, but it will stop calls you forgot to allow-list. Pair it with explicit allow rules (tool allow-listing) and roll it out under shadow mode first.

​
3. cap_cost resolves to allow or deny

cap_cost is the one verdict that is not what shows up in your events. You author a rule with a cap_cost_cents ceiling, but at evaluation time the engine resolves it to a concrete allow or deny before the event is recorded — so the events feed never carries a literal cap_cost verdict, only the allow/deny the agent actually saw. The ceiling is per agent run: the engine compares the run’s accumulated spend against your cap.
  • Under the cap → resolves to allow. (Internally this is treated as non-matching, so evaluation continues to the next rule rather than letting cap_cost win first-match as a grant.)
  • Over the cap → resolves to deny, with a reason naming the run’s total versus the cap. This is the terminal, circuit-breaker outcome.
// 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 only fires on the pre-dispatch surfaces (inbound, mcp) — the points where blocking a call still prevents the spend. On the post-dispatch response and egress surfaces it is inert (there’s nothing left to stop), so the engine skips it there.

​
4. How a verdict is chosen

For any tool call, the resolution is the same regardless of which verdict wins:
The gateway picks the policy attached to the calling key (firewall_policy_id), or the workspace default — see resolution.
Rules run in priority ASC order. The first rule whose surface, tool glob, optional argument clauses, and optional egress scope all match produces the verdict.
If no rule matches, the policy’s default_verdict applies — audit unless you changed it.
If the call is owned by a governed skill, a block-mode skill forces a deny and a quarantine-mode skill escalates anything short of deny to pending_approval.

​
5. Cost and retry behavior of a deny

A firewall verdict on the inbound surface fires before the upstream model call, so a deny there costs no model tokens. The error is marked skip-retry — re-running the same blocked call would just block again, so the gateway tells the client not to retry it. This is distinct from a guardrail block, which screens prompt/response text (PII, secrets) rather than tool actions, and returns its own guardrail_blocked error. A request can pass through both planes.
Each verdict leaves a trail. Every evaluation — allow, audit, deny, the resolved cap_cost, the held approval — is recorded as a firewall event, filterable by verdict, surface, tool, and run. The events feed is how you confirm a policy is producing the verdicts you expect. See events log and analytics.

​
Where to go next

Create & attach a policy

Pick a default verdict and bind a policy to a key.

Cap cost

Author a spend ceiling and how it resolves per run.

Shadow mode

Downgrade every enforcing verdict to audit while you measure impact.

Rule reference

The full matching language behind a verdict.
For the threats these verdicts are meant to stop, see dangerous tool calls and excessive agency.