Skip to main content
You can attach a guardrail to a single API key, but most teams want a floor: a content policy that applies to every key in the workspace unless a key opts into something else. That floor is the workspace default — one guardrail, marked is_default, that the gateway falls back to whenever a key has no explicit attachment. This page covers the default ai guardrail: how to set it, how resolution works, and the one invariant worth memorizing — one default per workspace. For the full engine reference, see the Guardrails reference.
Everything here is a console action on the hosted gateway (api.orcarouter.ai), run under your own session. Only the final /v1/* call uses an sk-orca-... relay key. Promoting or demoting a default guardrail requires Developer+ in the workspace.

​
1. Why set a default ai guardrail

Per-key attachment is precise but easy to forget — issue a new key, skip the dropdown, and that key ships with zero screening. A workspace default closes that gap:

No-attachment keys inherit it

Any key whose guardrail_id is unset (0/null) is screened by the default automatically — including keys created after you set it.

Edit once, shift the whole workspace

The default lives in the gateway, not on each key. Edit it and every inheriting key shifts on the next call — no redeploy, no SDK change.
A common pattern: make a conservative PII Shield the workspace default so nothing leaks by accident, then let specific keys attach a stricter or looser policy when they need one.

​
2. Promote a guardrail to the default

In the console, open Guardrails, edit the guardrail you want as the floor, and toggle Set as workspace default. Save.
1

Create or pick a guardrail

Author a policy as usual — e.g. the PII Shield preset, a single pii rule that masks at the both stage.
2

Mark it default and save

Turn on Set as workspace default and save. The guardrail’s is_default flag flips on.
3

Leave keys unattached

Any key with no explicit guardrail now inherits this one. Keys that already point at a different guardrail keep their attachment.
The default must also be enabled to take effect. A guardrail marked is_default but disabled resolves to no enforcement — the toggle and the enabled state are independent switches.

​
3. One default per workspace — promotion is atomic

This is the invariant: at most one guardrail per workspace carries is_default. You never have to manually un-set the old one. When you promote a new guardrail to default, the gateway demotes the previous default in the same transaction — the promote and the demote either both land or neither does. There is never a window where two guardrails are both the default, and never a window where none is. 
Before:   billing-pii   ← is_default ✓
          legal-redact

Promote "legal-redact" to default
          (single transaction)
          ┌─────────────────────────────────────────┐
          │  legal-redact  → is_default = true       │
          │  billing-pii   → is_default = false       │
          └─────────────────────────────────────────┘

After:    billing-pii
          legal-redact  ← is_default ✓
You don’t have to demote first. Just promote the new one — the old default is cleared for you, atomically. The demoted guardrail still exists and stays enabled; it simply no longer acts as the fallback. Keys explicitly attached to it are unaffected.
The same atomic swap applies whether you promote on create (mark a brand-new guardrail as default) or on edit (flip the flag on an existing one).

​
4. How resolution uses the default

For any request, the gateway resolves exactly one guardrail (or none) in this fixed order:
OrderWhat applies
1The key’s explicit guardrail_id — if it exists and is enabled.
2The workspace’s enabled is_default guardrail (key had no attachment).
3None — the request is byte-identical to a workspace with no policy.
An explicit key attachment never silently falls back to the default. If a key points at a guardrail and that guardrail is disabled, the key resolves to no enforcement — not the workspace default. Disabling an attached guardrail is the off switch for that key. (Firewall policies behave differently here — a disabled attached firewall policy does fall back to the workspace default. See Guardrails vs. firewall.)
So the default is the fallback for unattached keys only. It never overrides a key that made an explicit choice.
Fail-open by design. If default resolution hits a transient error, the gateway degrades to no enforcement rather than failing the request. Safety degrades; availability is preserved.

​
5. Worked example

Say your workspace has two guardrails and three keys:
  • pii-shield — marked workspace default, enabled.
  • strict-block — blocks credit cards, not default.
  • Key A — no attachment. Key B — attached to strict-block. Key C — attached to a guardrail you later disabled.
A request that mentions an email resolves like this:
guardrail_id is unset, so resolution falls through to the enabled is_default guardrail pii-shield. The email is masked to [EMAIL] before the model sees it.
The explicit attachment wins. strict-block applies; the default is never consulted.
The attachment exists but its guardrail is disabled, so resolution returns none — it does not drop through to pii-shield. The request is unscreened.
Now promote strict-block to default and save. In one transaction strict-block.is_default becomes true and pii-shield.is_default becomes false. Key A immediately inherits strict-block on its next call — without any change to the key itself.

​
6. Confirming the request hits the default

Send a request with an unattached key and check the Matches feed — a match recorded under your default guardrail confirms the fallback fired: 
curl https://api.orcarouter.ai/v1/chat/completions \
  -H "Authorization: Bearer sk-orca-..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {"role": "user", "content": "Reply to jane@acme.com please"}
    ]
  }'
If the default is a masking PII policy, the gateway rewrites the email to [EMAIL] before forwarding. If it blocks, the call returns HTTP 400 guardrail_blocked — which costs no quota and is marked skip-retry. See the guardrail_blocked error for the full response shape.
Want to prove the default’s behavior before any key relies on it? Open the Test tab in the guardrail editor and run a sample at the input stage — no upstream call, no quota. See Testing & eval.

​
7. Where to go next

Attach to a single key

When one key needs a different policy than the workspace floor.

Create your first guardrail

The end-to-end loop — create, test, attach, send.

Resolution & scope

How keys, policies, and workspaces compose.

Versioning

Every promotion writes a history row — diff and revert.
Promoting or demoting the default is itself a versioned change — open History on the guardrail to see when is_default flipped and who did it. For the complete engine, read the Guardrails reference.