How guardrails work

Every guarded chat completion runs through two enforcement stages. Either can allow, block, or fail safely.

request → request-side guardrails → model → response-side guardrails → response
                   │                                     │
                   └── block → 403                       └── block → 403

Request-side

Runs before any model call. Decides whether the request should reach the requested model at all. If blocked, the model is never called — 403 Forbidden with type: guardrail_error.

Response-side

Runs after the model has produced a completed response. Decides whether that response can be returned. If blocked, the model call did happen but the completed response is discarded — 403 Forbidden with type: guardrail_error.

Token usage on response-side blocks is still counted — the model did the work.

Fail-closed

If a required guardrail step cannot complete safely on a request, the platform refuses to execute rather than continuing with reduced protection: 503 Service Unavailable with code: guardrail_unavailable. Retry with backoff.

Streaming completions and structured tool-call outputs are subject to request-side checks but not to response-side checks in MLP1 — tokens are returned as they arrive and cannot be retroactively blocked mid-stream.