Skip to main content
You have a key your agent uses on api.orcarouter.ai, and you want every tool call that key makes to be governed — blocked, audited, sanitized, or held for approval — without touching your agent code. That’s a two-step agent firewall setup: create a firewall policy once, then point the key at it. From the next call on, every tool the key issues is checked against the policy at the gateway. This page is the create-and-attach path. For the full policy model (surfaces, verdicts, resolution) see the Firewall overview; for the rule grammar see Firewall Rules.
All policy and key configuration happens in the console (or the /api/workspace/firewall/* management routes, which use your session / access token — not a relay sk-orca-… key). Only your agent’s /v1/* calls use the relay key. Creating and attaching a policy is a Developer+ action.

​
1. Agent firewall setup at a glance

A firewall policy is a named, workspace-scoped object: an ordered list of rules plus a default verdict for everything no rule matches. A key opts in to a policy through its firewall_policy_id field. Nothing else in your stack changes.

Create the policy

Name it, pick a default verdict, add rules — or seed from an autonomy level / preset and edit.

Attach a key

Set the key’s firewall_policy_id to the policy, or mark the policy as the workspace default so every unattached key inherits it.

​
2. Create a policy in the console

  1. Open Security → Firewall → Policies and choose New policy.
  2. Name it (workspace-unique) and leave Enabled on.
  3. Pick a default verdict — see §3.
  4. Add rules in the rule editor, or start empty and let Discovered tools drive authoring from real traffic later.
  5. Save. The policy exists but governs nothing until a key points at it or you make it the workspace default.
Don’t want to hand-author rules first? Apply an autonomy level (balanced is the recommended start) — it materializes real, editable policy and guardrail rows you can then tune. Or start a rule from a built-in preset and edit it. Either way you end up at the same place: a named policy you attach to a key.

​
3. Pick the default verdict

The default verdict is what the policy does when no rule matches a tool call. It is the floor of your posture. It accepts exactly three values:
default_verdictWhen no rule matches…
audit (default)Allow the call, but record it. Observe everything, block nothing — the safe place to start.
allowAllow and log, no review record.
denyBlock anything a rule doesn’t explicitly permit — a default-deny posture you pair with allow rules.
deny is default-deny: any tool call your rules don’t explicitly allow is blocked. Powerful, but it will stop calls you forgot to allow-list. Roll a default-deny policy out under shadow mode first and watch the events feed before you enforce it.
Verdicts a rule can produce (allow, audit, deny, sanitize, pending_approval, cap_cost) are covered in Verdicts — the default verdict is limited to the three above.

​
4. Attach the policy to a key

A key opts into a policy through its firewall_policy_id. In the console:
  1. Open Keys, edit the key your agent uses.
  2. Set Firewall policy to the policy you created (this writes firewall_policy_id).
  3. Save. The next call that key makes is governed.
The binding lives on the key, in the gateway — your agent keeps sending the same Authorization: Bearer sk-orca-… and the same request body. There is no change to your agent’s tool-calling code. 
# Your agent's relay call is unchanged. The attached policy is enforced
# at the gateway before any tool call in the response is dispatched.
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "delete the staging table"}],
    "tools": [{"type": "function", "function": {"name": "db.query"}}]
  }'
If a rule denies a tool call on the inbound surface, that call comes back as HTTP 400 with code firewall_blocked, naming the tool and reason — see what a block looks like.

​
5. Resolution: attached → workspace default

For any tool call, the gateway resolves which policy applies in this order:
If the calling key’s firewall_policy_id points at a policy that exists and is enabled, that policy applies.
Otherwise, the workspace’s enabled is_default policy applies (if one is set). At most one policy per workspace can be the default; promoting a new default demotes the old one in the same transaction.
No attachment and no default means no policy. With observe mode on the call is allowed and logged as a coverage gap; with it off the call is allowed silently.
A disabled attached policy falls back to the workspace default — it does not turn enforcement off. (This differs from guardrails, where a disabled attachment resolves to none.) To take a key out of firewall scope, detach it (set firewall_policy_id to 0), don’t just disable its policy.
To make a policy the default for every unattached key, edit it and set it as the workspace default rather than attaching keys one by one — see Manage policies.

​
6. Verify it took effect

Before relying on it, confirm the policy fires the way you expect:
  • Test it — the sandbox Test tab dry-runs the policy against a sample tool call and returns the verdict, the matched rule, and the reason. Nothing is dispatched or persisted. See Test rules.
  • Watch the events feed — once the key takes live traffic, Events shows each evaluation, filterable by verdict, surface, tool, and run.
Roll any enforcing policy out behind shadow mode first: it evaluates and logs exactly as it would in production, but downgrades every enforcing verdict to audit and prefixes the reason [shadow] would …. Flip shadow off once the events feed shows it firing on what you expect and nothing you don’t.

​
Where to go next

Authoring rules

The full matching language — tool globs, argument clauses, egress lists, sanitizers.

Tool allow-listing

Pair a deny default verdict with explicit allow rules.

Manage policies

Defaults, enable/disable, versioning, and revert.

Why zero trust

Why governing actions — not just text — matters for agents.
For the threats a policy is meant to stop, see dangerous tool calls and excessive agency.