Concept

Policy groups

One reusable bundle of guardrail config, attached to your API keys — with per-key overrides and a master bypass for fully-trusted workloads.

The concept

One bundle of guardrail config

A policy group is a named bundle of guardrail settings. Each API key is assigned a policy group, and a Default group is auto-created for every account. Instead of configuring guardrails per key, you configure a group once and point many keys at it. A policy group holds:

the injection threshold (the mandatory input-injection check's sensitivity);
the PII mode and content-moderation config;
the output DLP mode and the jailbreak / indirect-injection modes;
and MCP tool allow/deny rules.

Attach many keys to one group. Give a prod key a strict group and a dev key a looser one, without duplicating config — change the group and every key on it updates at once.

Per-key overrides

Override the group for one key

An API key can carry a guardrail_overrides JSONB blob that selectively overrides its group for that one key. Only two guardrails are key-overridable: piiEnabled and contentModerationEnabled. Fields you omit fall through to the policy group.

Injection is NOT overridable. Prompt-injection detection is mandatory (Security Rule 5) and can never be disabled per key. An injectionEnabled: false in the overrides is ignored. If you need a full bypass for a trusted workload, use the master toggle below.

// guardrail_overrides (JSONB on the API key)
// Only PII + content moderation are key-overridable.
// Fields you omit fall back to the policy group.
{
  "piiEnabled": false,
  "contentModerationEnabled": true
  // "injectionEnabled": false  <-- IGNORED. Injection is mandatory.
}

Priority order

Which setting wins

When the same guardrail is configured in more than one place, the highest-priority source wins:

1
System-forced (ops) — platform-level emergency controls (e.g. an emergency blocklist) that always take precedence, everywhere.
2
Per-key overrides — the key's guardrail_overrides (PII / content only) beat its policy group.
3
Policy group — the group's configured modes and thresholds.
4
System defaults — the platform baseline used when nothing else is set.

Read top to bottom: a higher rule overrides everything below it. This is why an ops emergency block can't be undone by a customer override, and a per-key override can relax its own group but not the mandatory injection check.

Master toggle

guardrails_enabled — the Path B bypass

Each policy group has a master switch, guardrails_enabled, which defaults to TRUE. It is the "Path B" full bypass: when you turn it OFF, the entire pre-call guardrail pipeline is skipped for keys on that group — including the mandatory injection check.

Use with care. With the master toggle off, injection protection, PII, content moderation, and every other pre-call guardrail are all disabled. Responses then carry X-Anoman-Guardrail-Master: disabled so you can tell a bypassed request apart. Only use this for a fully-trusted, isolated workload.

In the dashboard the master toggle ships with a warning and a confirmation dialog, precisely because it disables the mandatory injection guardrail that's otherwise impossible to switch off.

Configure

Where to manage groups

Manage group config and the master toggle in the dashboard at /dashboard/guardrails. Assign keys to groups and set per-key overrides on the API key toggles at /dashboard/keys.

Configure your policy groups

Set guardrail config once, attach it to every key, and override where you need to.

Open guardrails Guardrails overview