Guardrails 2.0: blocking bad output without blocking your users

The objection we heard most about inline guardrails was never about accuracy. It was about latency. Nobody wants to add two hundred milliseconds to every response to catch a problem that happens once in a thousand runs.

What changed

Guardrails 2.0 moves classification off the critical path for everything except the checks that must block. PII detection, injection detection and policy matching now run as compiled rules against the token stream, so the common case never leaves the process.

The result is a p95 of under six milliseconds for the full default suite, measured across our production fleet rather than a benchmark rig.

Choosing what blocks

Every check has three modes: observe, warn and block. We recommend starting everything in observe for a week, looking at what would have fired, and only then promoting the rules you trust. Blocking a real customer response is a product decision, not a security default.