Guardrails

PII regex and keyword blocklists scoped to each API key. Guardrails fire before the upstream call — a blocked request never reaches the provider, so you don't pay for it and the prompt isn't leaked.

Scope (today)

Input only. The MVP scans messages[], not the assistant's response.
Per-API-key. Each key can have its own active guardrails.
Two checker types: regex (good for PII) and exact keyword match (good for compliance / brand-safety).

v2 will add output stream scanning, an LLM-based classifier, and a webhook-veto flow. The schema is forward-compatible — existing rows stay valid.

Config shape

Guardrails are stored as a config JSON blob with this structure:

JSON

{
  "rules": [
    { "type": "pii_regex", "pattern": "\\b\\d{3}-\\d{2}-\\d{4}\\b", "category": "ssn" },
    { "type": "keyword", "words": ["confidential", "internal-only"], "case_sensitive": false }
  ]
}

When a rule matches

The gateway returns a 400 with a structured error:

{
  "error": {
    "type": "edgeroute_error",
    "code": "guardrail_blocked",
    "message": "Request blocked by guardrail (pii_regex: ssn). Excerpt: \"123-45-6789\""
  }
}

The match is logged (with redacted excerpt) but the prompt is never persisted in full. Guardrail-blocked requests don't count against your monthly BYOK fee.

Dashboard session bypass

Requests authenticated by the dashboard session (i.e. the playground at /dashboard/chat) skip guardrails. The reasoning: the user is already the one typing the prompt, so blocking themselves makes no sense.