guardrails and filters

Guardrails are the safety checks that wrap around a model rather than living inside its weights. Picture a bouncer at the door and a inspector at the exit: an input guard inspects the user's prompt before it reaches the model and can block or rewrite obviously harmful requests, while an output guard inspects the model's reply before it reaches the user and can suppress or redact unsafe content. They run as separate components, often smaller classifiers or rule sets, so they can be updated without retraining the main model.

Layering guards outside the model has real advantages. They give a second, independent line of defense that an attacker must also defeat, they can be tuned per-application without touching the model, and they can enforce things the model is bad at policing itself, like detecting personal data, scanning generated code for known exploits, or checking that tool calls stay within allowed scopes. Many production systems run several in sequence: topic filters, PII detectors, jailbreak classifiers, and output safety models.

Guardrails are not a panacea. Classifiers have their own false positives (blocking benign requests) and false negatives (missing cleverly worded attacks), they add latency and cost, and an over-aggressive filter degrades the product as surely as an under-aggressive one leaves it exposed. The strongest systems combine in-model safety training with external guards so that neither is a single point of failure.