Guardrails are the checks that sit around a model — validating what goes in, what comes out, and which actions it is allowed to take. They exist because a model will, eventually and confidently, produce something wrong: an invalid JSON payload, a leaked secret, a tool call that shouldn't fire. Guardrails are the deterministic layer that catches it.
Why it matters in production
The gap between an impressive demo and a system you would put in front of a customer is almost entirely guardrails. Input filters stop prompt injection and malformed requests; output validators enforce schema and policy; action gates require confirmation before a tool call does something irreversible. Without them, one bad generation becomes one bad incident.
The common mistake
Trusting the model to guard itself. "I told it in the prompt not to do X" is not a guardrail — it is a suggestion the model can and will ignore under the right input. Real guardrails are code that runs regardless of what the model decided, and they fail closed. The other mistake is guarding only the output while leaving inputs and tool calls wide open.
How we actually use it
We validate output against a schema and reject-or-retry on failure, gate destructive actions behind explicit confirmation, and keep the checks deterministic so they behave the same on every run. Guardrails also produce the signals that feed observability — a guardrail that trips is a failure you can see instead of a silent one. They pair naturally with evals: evals measure quality in aggregate, guardrails enforce policy per request.