Guardrails
Guardrails are the runtime policy checks on every chat-completions request. They run on the normal request path — you don't wire them up separately and you can't opt out per request.
Three outcomes
Every guarded request produces one of three outcomes:
| Outcome | HTTP | Model called? | Body |
|---|---|---|---|
| Allow | 200 OK | Yes | Normal chat completion |
| Blocked | 403 Forbidden | Sometimes (see below) | Error, type: guardrail_error |
| Guardrails unavailable | 503 Service Unavailable | No | Error, code: guardrail_unavailable |
Three headers on every guarded response
| Header | Meaning |
|---|---|
x-request-id | This HTTP request |
x-decision-id | The guardrails decision for this request |
x-policy-version | The policy version that produced the decision |
Log all three on every request. When a response looks wrong later, x-decision-id is the fastest support handoff.
What guardrails will not do
- Silently reroute a blocked request to a different model
- Rewrite, redact, or partially release a blocked response
- Continue with reduced protection when a required check is unavailable
In this section
- How guardrails work — request-side vs response-side enforcement
- Decision response headers — the header contract
- Blocked and fail-closed outcomes — response shapes and client behaviour