An LLM deployed with only its base training as protection will, sooner or later, do exactly what a user asks it to do, even when what they asked for is a system prompt dump, a fabricated refund, or a shell command it was never supposed to execute. RLHF and constitutional training make a model reluctant to produce certain content when it recognizes the request as harmful, but recognition is probabilistic, not architectural, and it happens inside the same weights an attacker is trying to manipulate. A production system that relies on the model to police itself has exactly one line of defense, and that line was never designed to survive a hostile, motivated adversary crafting inputs specifically to defeat it.
Guardrails are the layer that sits around the model rather than inside it: code that validates what goes in, code that validates what comes out, and infrastructure that limits what the model's decisions are allowed to do regardless of how convincingly it argues for doing them. A guardrail does not need the model to agree that a request is dangerous — it can reject, rewrite, or block based on rules the model has no say over. That separation of concerns, model reasons and system enforces, is what turns "the model usually refuses" into "the system cannot be talked into it."
Teams that skip this layer discover the gap the expensive way: a support bot that argues itself into approving a refund it was never authorized to grant, an internal assistant that pastes a customer's SSN into a Slack channel because a cleverly worded prompt convinced it that redaction rules did not apply this time. None of those failures required breaking the model's alignment. They required only that no system-level check existed to catch what the model, in isolation, was willing to do.