6 guardrails run in a fixed order before and after the upstream call. Fail-fast on blocks. Pass-through results on every successful response.

Request flow

┌────────────────────────────────────────────────────────────────┐
│  Request arrives at /v1/chat/completions                       │
└────────────────────────────────────────────────────────────────┘
              │
              ▼
   1. Auth + rate limit       ← 401/402/403/429 fail fast (~1 ms)
              │
              ▼
   2. PRE-CALL GUARDRAILS     ← fail-fast on any block (~30-80 ms)
       ┌────────────────────┐
       │ a. Injection        │  ML-based classifier
       │ b. PII              │  PII detection engine
       │ c. Content          │  Keyword + classifier
       │ d. Policy (tools)   │  policy-engine allow/deny lists
       └────────────────────┘
              │
              ▼ (if all pass)
   3. Cache check             ← response cache hit (opt-in) returns 200
              │
              ▼ (miss)
   4. Routing decision        ← realtime or batch?
              │
              ▼
   5. Upstream LLM call       ← provider latency (~500ms-5s typical)
              │
              ▼
   6. POST-CALL GUARDRAILS    ← (~20-40 ms)
       ┌────────────────────┐
       │ e. Response content │  Filter unsafe completions
       │ f. Response PII     │  Mask leaked PII in output
       └────────────────────┘
              │
              ▼
   7. Token metering + trace  ← event stream + analytics store
              │
              ▼
        Response to client

Every request runs through the pipeline in this fixed order. There is no way to skip it; the master toggle to bypass guardrails (rarely used, audit-logged) is a per-policy-group setting that an admin must explicitly enable.

What each one does

a. Prompt injection

An ML-based prompt-injection classifier scores every user-role message. A score above the policy group's configurable threshold returns 403. Catches jailbreak prompts, system prompt extraction, and tool-call hijacking. Runs in ~40 ms on CPU.

b. PII detection

Our PII detection engine recognizes email, credit card, Singapore NRIC, Indonesian NIK, Malaysian MyKad, and Thai National ID by default, with phone, IP, and URL available as opt-in settings. Behavior depends on the policy group's PII mode: redact (replace with <EMAIL> placeholders), tokenize (replace with reversible tokens and restore in the response), synthetic (replace with realistic fake values), or block (return 403).

c. Content moderation

Keyword denylist (admin-configurable) plus a multilingual classifier covering EN + Bahasa Indonesia. Per-category sensitivity (sexual, hate, self-harm, etc.). Returns 403 on hit.

d. Policy / tool enforcement

When the request includes tools, every tool name is checked against the API key's policy group (allow/deny lists). MCP tool RBAC also applies here for connected MCP servers.

After the upstream returns

e. Response content filter — same classifier as pre-call but applied to the model's output. Catches accidental unsafe completions that the model produced despite a safe prompt.
f. Response PII scanner — masks any PII in the response. Useful when the upstream might echo back something sensitive even though the prompt was clean.

If a post-call guardrail blocks, the response is replaced with a 403 — the customer pays for the tokens (upstream already ran) but doesn't see the unsafe content.

Pass vs block on the wire

On a 200 response, every guardrail's result is surfaced in _anoman.guardrails and as headers prefixed x-anoman-guardrail-*. Useful for logging the false-positive rate without inferring from blocks.

{
  "choices": [...],
  "_anoman": {
    "guardrails": {
      "injection":        { "status": "pass", "score": 0.02 },
      "pii":              { "status": "pass" },
      "content":          { "status": "pass" },
      "policy":           { "status": "pass" },
      "response_content": { "status": "pass" }
    }
  }
}

// User said "my email is [email protected]" — we masked before upstream.
{
  "choices": [{
    "message": {"role": "assistant", "content": "I can help with that..."}
  }],
  "_anoman": {
    "guardrails": {
      "pii": {
        "status": "pass",
        "redacted": 1,
        "entities": [{"type": "EMAIL", "count": 1}]
      }
    }
  }
}

On a block, the response is 403 with type: "guardrail_error" and a specific code identifying which guardrail fired:

// Response body
{
  "error": {
    "type": "guardrail_error",
    "code": "prompt_injection",
    "message": "Request blocked by prompt injection detector (score 0.94 > threshold 0.85)."
  }
}
 
// Headers
x-anoman-guardrail-injection: blocked score=0.94

What does it cost in time?

Pre-call guardrails (target p95):
  Injection (ML model)       ~40 ms
  PII (detection engine)     ~25 ms
  Content (keyword + ML)     ~5 ms
  Policy (allow/deny)        ~10 ms
                            ────────
  Total pre-call             <100 ms

Post-call guardrails (target p95):
  Response content           ~15 ms
  Response PII               ~20 ms
                            ────────
  Total post-call            <40 ms

Anoman total overhead:       <150 ms p95
  (vs typical LLM call latency of 500ms – 5s — negligible)

The pre-call pipeline runs sequentially with fail-fast — when injection blocks, we don't bother running PII / content / policy. On a typical pass, the full pipeline adds <100 ms before the upstream call begins.

Per-key + per-policy-group overrides

Each API key is assigned a policy group with: PII mode, injection threshold, content moderation severity, tool allow/deny list, and a master enable toggle. Per-key overrides can opt out of specific guardrails (audit-logged) — useful for trusted internal services where you don't want PII redaction modifying the prompt.

See the Guardrails settings page in the dashboard, or the /docs/guardrails reference for the full config surface.

See every guardrail firing live.

Live Feed shows the pre/post-call result on every request as it happens.

Guardrails pipeline