Skip to main content
You’ve authored a guardrail and a firewall policy for your workspace. Now you want this one key — the one your finance agent uses — to run a stricter content policy and a tighter tool allow-list than the rest of the workspace. That’s what the two attachment fields on a key do: bind a guardrail and a firewall policy to a single key, and every request that key makes is screened and enforced by exactly those policies — no agent-code change, no redeploy. This page covers the two fields, how they resolve at request time, and the one resolution rule that catches people: a disabled firewall attachment behaves differently from a disabled guardrail attachment.

​
1. The per key security policy: two fields on a key

A guardrail screens the text that flows through a model (PII, secrets, jailbreaks). A firewall policy governs the tool calls an agent issues (which tools, which MCP servers, which hosts). Both are workspace-scoped, named policies — authored once, shared across the workspace — and a key opts into a specific one through two fields:
FieldBindsSets in console
guardrail_idThe guardrail that screens this key’s prompts and responses.Developer+
firewall_policy_idThe firewall policy that evaluates this key’s tool calls.Developer+
Both are set in the key editor at /console/token. Setting either one is a Developer+ action — the policies themselves are also authored Developer+ (see Scope & keys).
These two fields are independent. A key can attach a guardrail and not a firewall policy, the reverse, both, or neither — each plane resolves on its own. Leaving a field unset (0) is not the same as turning enforcement off; see §3.

​
2. One concrete example

Say your workspace default guardrail flags PII but allows it through, and the default firewall policy audits every tool call. That’s fine for most agents — but your finance agent handles customer SSNs and should never call a shell tool. Author a stricter finance-guardrail (blocks PII outright) and a finance-firewall (allow-lists only the three tools it needs), then bind both to that agent’s key: 
# Configure via the CONSOLE (UserAuth — your session), not a relay key.
# This is the key-update call the editor at /console/token makes.
PUT /api/token
{
  "id": 4127,
  "name": "finance-agent",
  "guardrail_id": 12,          // finance-guardrail (PII = block)
  "firewall_policy_id": 8      // finance-firewall (3-tool allow-list)
}
From the next request on, that key’s traffic is screened by guardrail 12 and its tool calls are evaluated by policy 8 — while every other key in the workspace keeps running the workspace defaults. The agent’s own code never changes; it keeps calling https://api.orcarouter.ai/v1/... with its sk-orca-… key exactly as before.
This is the least-agency pattern: one narrowly-scoped key per agent, each bound to the policies its job actually needs. When that agent is compromised, the blast radius is whatever its key was authorized to do — nothing more. See the least-agency checklist.

​
3. Resolution: the rule that catches people

For every request, the gateway resolves the active guardrail and the active firewall policy independently. The order looks the same for both — attachment first, workspace default second — but they diverge on one case.

​
Guardrail resolution

The key’s guardrail_id points to a guardrail that exists and is enabled. That guardrail screens the request.
Disabling the attached guardrail is an off switch. The key gets no content screening — it does not fall back to the workspace default. This is deliberate: attaching a guardrail and disabling it is how you turn screening off for that key.
No guardrail_id on the key. The workspace’s enabled default guardrail applies, if one is set.
No attachment and no workspace default → the request passes without content screening.

​
Firewall resolution

The key’s firewall_policy_id points to a policy that exists and is enabled. That policy evaluates the key’s tool calls.
Here is the difference. A disabled firewall attachment falls back to the workspace default firewall policy — it does not turn enforcement off. Disabling a firewall attachment reverts the key to the workspace default; it does not leave the key unguarded.
No firewall_policy_id on the key → the workspace’s enabled default firewall policy applies.
Disabling an attached policy is not symmetric. A disabled guardrail attachment means no guardrail for that key. A disabled firewall attachment means fall back to the workspace default. If you want a key to genuinely run no firewall enforcement, you can’t get there by disabling its attachment — make sure no workspace default firewall policy is set (or scope the key so it issues no governed tool calls).
At most one guardrail and one firewall policy per workspace can be the default at any time; promoting a new default demotes the old one in the same transaction, so you can never accidentally have two.

​
4. What a block looks like

When a bound policy denies a request, the caller sees a structured error — the agent can react instead of crashing:
PlaneError codeHTTPCost
Guardrailguardrail_blocked400None — an input block fires before metering; an output block refunds. Marked skip-retry.
Firewall (inbound)firewall_blocked400An inbound block fires before the model call, so no model tokens. Skip-retry.
Firewall (held)firewall_approval_pending400Held for human approval; the agent polls and re-submits once approved.
Both error bodies are OpenAI-shaped and name the policy and reason, so your agent can branch on the code. See the deep references for the full event record and how matches are logged.

​
5. Where to go next

Scope & keys

The full three-level model — workspace, policy, key — and every field a key carries.

The token object

Every field on a key: model_limits, allow_ips, credit_limit_usd, expired_time, and the two policy attachments.

Guardrails

Author the content policy you bind via guardrail_id — rules, PII entities, actions, and presets.

Firewall

Author the tool-call policy you bind via firewall_policy_id — verdicts, surfaces, and autonomy levels.
Want to set your whole workspace posture in one move instead of binding keys one at a time? An autonomy level writes both planes — guardrails and firewall — at once. Then attach stricter policies on the few keys that need to go further than the workspace default. See Guardrails vs Firewall.