Skip to main content
The safest posture for an autonomous agent is default-deny: block every tool by default, then explicitly allow only the handful your agent is meant to use. Anything new an agent picks up — a community skill, a misconfigured MCP server, a tool a jailbreak talked the model into — is denied because you never opted it in, not because you remembered to block it. This page is the tool allow-listing for agents pattern on api.orcarouter.ai: a deny default verdict plus one or more allow rules keyed on a tool_name_glob. For the full matching language behind those rules, see Firewall Rules.
Allow-lists are authored in the console under Security → Firewall, or via the /api/workspace/firewall/* management routes (your session / access token — not a relay sk-orca-… key). Only your agent’s /v1/* calls use the relay key. Creating or editing a policy is a Developer+ action.

​
1. Why default-deny for agents

A block-list (“deny shell.exec, deny db.delete, …”) is only ever as complete as the last threat you thought of. An allow-list inverts the burden of proof: the gateway denies everything the policy doesn’t explicitly permit, so an unknown tool is closed by construction.

Default verdict = deny

The floor of the policy. With no rule matching, every tool call is blocked.

Allow rules opt tools back in

Each allow rule names the tools you actually use — by exact name or by glob.
The engine walks a policy’s rules in priority order and the first match wins; if nothing matches it falls to the policy’s default_verdict. So an allow-list is just: high-priority allow rules for your real tools, with a deny floor catching everything else.

​
2. One example: allow-list a research agent’s tools

Say your agent only ever needs to search the web and read from a knowledge base — tools named web.search and kb.read. Everything else (shell, file writes, database mutations, any tool a prompt-injection might conjure) must be denied. Build the policy as default deny + two allow rules:
1

Create the policy with a deny default

Security → Firewall → Policies → New policy. Name it, leave Enabled on, and set the default verdict to deny. This is the closed floor — see Create a policy.
2

Add an allow rule per tool family

In the rule editor add two rules, both verdict = allow:
prioritytool_name_globverdict
10web.searchallow
20kb.*allow
web.search is an exact match; kb.* is a prefix glob that allows kb.read, kb.search, and any future kb.* tool without re-editing the policy.
3

Attach it to your agent's key

Set the key’s firewall_policy_id to this policy (or make it the workspace default). Your agent’s request body is unchanged.
Now web.search and kb.read pass; a call to shell.exec matches no allow rule, hits the deny floor, and comes back as HTTP 400 with code firewall_blocked on the inbound surface — see what a block looks like.
Author allow rules as exact names or narrow prefixes (kb.*), not broad suffixes. A loose *.read would allow kb.read and secrets.read — the opposite of what an allow-list is for. Keep the glob as tight as the tool naming lets you.

​
3. The glob in one screen

tool_name_glob is a small, case-sensitive grammar — no regex, linear time. The shapes that matter for an allow-list:
PatternAllows
web.searchExactly that tool.
kb.*Prefix — kb.read, kb.search (not bare kb).
*.searchSuffix — web.search, kb.search, and bare search.
*.tools.*Infix — byo.tools.fetch and similar.
For the full grammar (infix rules, edge cases, skill-name globs), see Glob syntax and the Firewall Rules reference.
A *.suffix glob also matches the bare, un-namespaced verb — *.search allows a tool literally named search, not just web.search. Providers and non-namespacing MCP servers expose tools under bare verbs, so an allow-listed suffix is wider than it looks. Prefer exact names or prefixes when you want a tight allow-list.

​
4. Roll it out without breaking your agent

Default-deny is the posture most likely to block a tool you forgot you needed. Stage it:
Turn on shadow mode. The policy evaluates and logs exactly as it would live, but downgrades every deny to audit with the reason prefixed [shadow] would …. Run real traffic, then read the events feed.
Discovered tools lists every tool the workspace has seen, flagged covered or gap. The shadow-mode “would-deny” events plus the gaps tell you exactly which allow rules you still need.
The Test sandbox dry-runs the policy against a sample tool call and returns the verdict, the matched rule, and the reason — nothing dispatched, nothing persisted. Confirm web.search allows and shell.exec denies, then flip shadow off.
A denied inbound call costs no model tokens — it’s blocked before the upstream model runs — and is marked skip-retry, so a blocked tool won’t burn a retry budget re-blocking. See Verdicts.

​
5. Where to go next

Block specific tools

The inverse — keep a default-allow floor and deny named tools.

Validate arguments

Allow a tool, but only with safe arguments (db.query but not DROP TABLE).

Rule priority

How first-match-wins orders your allow rules above the deny floor.

Verdicts

allow, audit, deny, sanitize, pending_approval, cap_cost.
For the threat this pattern addresses, see excessive agency and dangerous tool calls. For why default-deny is the agent baseline, see why zero trust.