How guardrails work

A guardrail on its own enforces nothing. It must be part of a policy, and the policy must be attached to a scope. The full path is Garden → policy → attachment.

1. Add guardrails

On the Garden tab, add ready-made cards (PII, jailbreak, toxicity, keyword lists). Deterministic cards run with zero extra model latency.

For custom regex/code or vendor scanners, build one on the Guardrails tab.

2. Bundle them into a policy

On Policies, create a policy, open it, and add your guardrails as steps. Steps run in parallel or as an ordered flow. Each step can block the request or just flag it.

3. Attach the policy

Inside the policy editor, use Attachments to bind it to a key, team, organization, access group or model group. Nothing is enforced until you attach it. Attachments inherit org → team → key.

Details: Attachments and inheritance.

4. Test and monitor

Dry-run prompts in the Playground, then watch real decisions (pass / flag / block) on the Monitor tab.

A blocked call returns 403 guardrail_blocked. Decisions are stored on the spend log and appear in Request Logs.