Guardrails

Guardrails screen content in both directions — the prompt on the way in, the model's reply on the way out — and decide per policy whether to allow, flag, redact, or block. They are per-org: a fresh org starts empty, and the apply recommended button plants a sensible starter set of PII and secret rules.

Dashboard: Govern ▸ Guardrails. API: /admin/guardrails/* (see Admin API). Requires MANAGE_GATEWAY to manage. Pattern detectors work on all editions; AI-classifier detectors need Pro AI.

The three building blocks

Category — a named bucket of sensitive content: PII, SECRET, or a custom one like competitor-names. It is a free key you define, not a fixed list. A category can be marked an indicator (an IOC such as an IP, domain, or hash) so its matched value is kept on events for threat intel.
Detector — what finds the content. A REGEX detector runs in-process (a pattern plus an optional validator, like a Luhn check for card numbers). A REMOTE detector calls a local AI classifier sidecar: a document guard (Llama Guard-class: one safe/unsafe verdict) or a span analyzer (Presidio: entity offsets you can redact). Remote detectors require the Pro AI sidecars; no data leaves your infrastructure.
Policy — maps a category to an action for a scope and a direction (request or response): ALLOW, FLAG (record only), REDACT (mask the match), or BLOCK. Each policy also carries a fail-closed posture.

How a screening decision is made

Detectors find spans; the policy for the most specific scope that covers the matched category decides the action. Redaction carries a strategy:

Strategy	Effect	Use when
`MASK`	Replace with a fixed mask (`****`)	You never need the value back
`HASH`	Replace with a stable hash	You want to correlate occurrences without the value
`TOKEN`	Reversible placeholder, restored for the client at the end	The model needs coherent text but the value must not reach the vendor
`PARTIAL`	Keep part (e.g. last 4 digits)	A human needs to recognize it

Where guardrails run

Request screening happens before routing, on every surface (/v1/chat/completions, /v1/responses, /v1/messages, /v1/embeddings). A block returns 403 content_blocked and nothing is sent upstream. A TOKEN redaction is applied to the forwarded request and restored in the response.
Response screening happens after the vendor replies. A response block replaces the body with a content_blocked error (the call still completed upstream and is metered); redact masks the matched values out of the output.
Streams are screened inline. Assistant text is accumulated; complete matches are redacted and re-emitted; only a match that may still be forming at a chunk boundary is held back and glued to the next chunk, so clean text streams without waiting for the whole response. A block emits an error frame and stops the stream.

The three tabs

Policies (category-centric): pick a category, set its request and response actions, mask strategy, and fail-closed posture; see which detectors feed it.
Detectors (the catalogue): enable, edit, or delete detectors.
Test (a dry run): screen a prompt you type, edit the model's hypothetical reply and re-screen it as the response, and watch the reversible-redaction round trip — no model is called. There is an equivalent API: POST /admin/guardrails/screen.

Prevent PII & secret leaks — a worked policy setup with verification.
SIEM, UEBA & SOAR — alerting and auto-containment on guardrail events.