Prevent PII & secret leaks
1. Seed a starter set
Govern ▸ Guardrails. On a fresh org, click apply recommended to plant PII and secret categories, detectors, and policies through the normal create calls. You now have something to tune instead of a blank page.
2. Tune the request policy (redact PII going out)
Policies tab → category PII → set the Request action to REDACT with the reversible TOKEN strategy. The model receives coherent text with placeholders instead of the real values, and the placeholders are restored in the response the client sees — the real value never reaches the vendor.
3. Tune the response policy (block secrets coming back)
Category SECRET → set the Response action to BLOCK, and switch fail-closed on: if the detector cannot finish scanning, block the call rather than risk a leak.
4. Dry-run it
Test tab — a no-model pipeline:
- Type a prompt containing an email address and watch it get redacted on the way in.
- Edit the hypothetical model reply to include a fake API key and re-screen it as the response — watch it get blocked.
Nothing is sent to any model during a dry run. The same check is available as an API: POST /admin/guardrails/screen.
Verify against a live model
Repeat the same prompts in Operate ▸ Playground with a real key. The Playground is fully governed — the redaction and the block behave exactly as they will for your applications, and both attempts appear as GuardrailTriggered events in Govern ▸ Audit & usage.
Why it works
Detectors find spans; the most-specific-scope policy for the matched category decides the action, per direction. Request screening runs before routing (a block means nothing was sent upstream); response screening runs after the vendor replies, inline on streams.
Next
- Contain a leaked key — alert and auto-quarantine when one key keeps tripping the
SECRETpolicy. - Guardrails — strategies, fail posture, and the AI-classifier detectors.