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, search the Hub-style catalog and add rule, LLM-critic, or vendor-mapped cards. Deterministic Rule cards run with zero extra model latency. LLM cards call a critic model. Vendor cards use OpenAI Moderation or Azure Content Safety.

For custom Starlark or a one-off webhook, 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 builder, use Where it applies 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 (passed / modified / blocked) on the Monitor tab.

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