Guardrails inspect requests before they reach a model (pre-call) and responses before they reach your user (post-call). They can block, redact, warn, or simply log — letting you enforce safety and compliance without changing your application code.

Guardrail types

Type	What it does
Presidio PII	Detects and anonymizes personally identifiable information using Microsoft Presidio
Regex	Filters content matching patterns you define
Keyword	Blocks content containing words on a blocklist
Prompt Injection	Detects and blocks attempts to hijack the model's instructions
Custom	Calls your own webhook to make the decision

Modes and actions

Each guardrail runs in a mode — pre-call (before the LLM request) or post-call (on the response) — and takes an action when it triggers:

Action	Effect
Block	Reject the request before it reaches the provider — it costs zero credits and never appears in the provider's logs
Redact	Strip the sensitive content and continue
Warn	Allow the request through, but attach a warning header
Log	Allow through and record the event only

Scope hierarchy

Guardrails apply at three scopes, combined per request — key > team > org:

Organization — a master kill-switch plus org-wide guardrails that apply to every key.
Team — guardrails scoped to a team, applying to every key on that team.
Key — guardrails assigned to specific virtual keys.

Scopes are additive: a key-level rule adds to its team's and org's rules — it never replaces them. A request is checked against the union of all three levels.

Manage org guardrails on the main Guardrails page and per-key assignments under Guardrails → Keys.

Testing before you ship

Expand any guardrail to find a Test tab: paste sample input and see exactly which action fires and how long it took. This lets you tune a rule against realistic content before it touches live traffic.

Versioning and rollback

Every change to a guardrail is snapshotted. The Versions tab lists each update, and you can roll back to any prior version with one click — useful if a tightened rule starts blocking legitimate requests.

Templates

The Templates gallery offers one-click setups for common patterns — PII redaction, jailbreak/prompt-injection detection, and language blocklists — so you can stand up sensible defaults quickly, then customize.

Guardrail logs

The Guardrails → Logs view records every guardrail evaluation:

Column	Meaning
Time	When the guardrail ran
Guardrail	Which rule evaluated the request
Mode	Pre-call or post-call
Action	Blocked, Redacted, Allowed, Logged, or Error
Latency	How long the check took (ms)
Request ID	Correlate with the request in observability logs

Filter by guardrail or action, or search by name/request ID.

Next steps

Observability & Logs — See guardrail outcomes alongside the full request
API Key Management — Assign guardrails to specific keys
Playground — Trigger a guardrail interactively to confirm it fires

FAQ

Do I need to change my application code to use guardrails?

No. Guardrails run in the request path automatically once configured — they inspect requests before they reach a model and responses before they reach your user, with no SDK or code change on your side.

What kinds of content can a guardrail check for?

There are five types: Presidio PII detection/anonymization, Regex pattern filtering, Keyword blocklists, Prompt Injection detection, and Custom — which calls your own webhook to make the decision. You can combine multiple guardrails across the same request.

What's the difference between the Block, Redact, Warn, and Log actions?

Block rejects the request before it reaches the provider, Redact strips the sensitive content and lets the request continue, Warn allows it through but attaches a warning header, and Log allows it through and only records the event. Each guardrail runs in either pre-call (before the model) or post-call (on the response) mode.

If a guardrail blocks a request, am I still charged credits for it?

No. A blocked request is rejected before it reaches the provider, so it costs zero credits and never appears in the provider's logs. Redact, Warn, and Log all let the request proceed, so those calls are billed normally.

How do organization, team, and key guardrails combine on a single request?

Guardrails are additive across three scopes in the order key > team > org — a key-level rule adds to its team's and org's rules, it never replaces them. Every request is checked against the union of all three levels.

Who on my team can create or edit guardrails?

Creating, editing, deleting, and rolling back guardrails requires the owner or admin role. Any org member can view guardrails and their version history, and any member can use the Test tab to try a rule against sample input.

Can I test a guardrail before it affects live traffic?

Yes. Expand any guardrail and open the Test tab, paste sample input, and you'll see exactly which action fires and how long the check took — so you can tune a rule against realistic content before it touches live traffic.

What happens if I tighten a rule and it starts blocking legitimate requests?

Every change to a guardrail is snapshotted. Open the Versions tab, and you can roll back to any prior version with one click to immediately restore the earlier behavior.

Is there a fast way to stand up common guardrails?

Yes. The Templates gallery offers one-click setups for common patterns — PII redaction, jailbreak/prompt-injection detection, and language blocklists — that you can apply as sensible defaults and then customize.

How do I see what my guardrails did, and can I trace it back to a specific request?

The Guardrails → Logs view records every evaluation with its time, which rule ran, the mode, the action taken (Blocked, Redacted, Allowed, Logged, or Error), and the latency in milliseconds. You can filter by guardrail or action, or use the Request ID to correlate an evaluation with the full request in your observability logs.

Guardrails

On this page