Key insight

Guardrails are two checkpoints around a model. The input gate asks “is this safe to send in?” and screens out injections, abuse, and junk before the model sees them. The output gate asks “is this safe to let out?” and catches harmful content, leaked secrets, bad formats, and dangerous actions before anyone acts on them. A guardrail decides with rules, a classifier, or a second model as judge — and every one has gaps. So stack them, make them fail closed, and never mistake any single filter for a force field.

The series has repeated one cure: do not rely on the model to police itself; put controls around it. This page is where those controls become concrete — the practical layer where most of the earlier defenses actually get enforced. The model stays in the middle; the guardrails decide what reaches it and what leaves.

1 · Guardrails: checkpoints around the model

Guardrails are checkpoints you build around the model — two of them. One sits in front, inspecting everything on its way into the model. One sits behind, inspecting everything on its way out. The model itself stays in the middle, doing what it does, while the guardrails decide what is allowed to reach it and what is allowed to leave. Picture airport security with a checkpoint at the entrance and another at the exit. The model can be brilliant and still be fooled; the guardrails are how you make sure that being fooled does not automatically become a bad thing reaching the world.

The model sits between an input gate and an output gate A user's request passes through an input gate, into the model, and out through an output gate. Nothing passes unchecked. request input gate the model output gate Nothing passes unchecked, in or out
Figure 1. Two checkpoints, front and back — so that being fooled at one does not become harm reaching the world.

2 · Two gates, two jobs

You want both gates because each catches things the other cannot. The input gate asks: is this request safe and appropriate to hand the model? It is your first chance to stop an attack before it ever touches the model — screening out injections, abuse, and nonsense at the door. The output gate asks a separate question: regardless of what came in, is what the model produced safe to release? It is your last line of defense, catching harmful, leaky, or malformed answers before they reach a user or a downstream system. Crucially, the output gate protects you even when the input gate is fooled — because no filter catches everything, and something bad will eventually slip past the front door.

3 · The input gate: what to catch

The input gate looks for several things. Injection and jailbreak attempts — messages carrying the tell-tale “ignore your instructions” patterns or known attack shapes. Off-topic or abusive requests — a support bot does not need to answer questions about building weapons, so it can refuse them at the door. Personal or sensitive data the user should not be pasting in — detect and strip it before it is sent to a third-party model. And plain junk — requests that are absurdly long, malformed, or designed to overload the system. None of this checking is perfect — a determined attacker will disguise their request — but the input gate cheaply removes the easy, obvious, and high-volume attacks, so the model only ever sees traffic that already passed a first sniff test.

4 · The output gate: what to catch

The output gate inspects what the model produced before it is allowed to leave, and it catches a different set of problems. Harmful content — the answer crossed a line, no matter how it was coaxed. Leaked secrets or personal data — scan for things that look like keys, passwords, or private information and block or redact them (the backstop to the disclosure topic). Wrong format — if you expected clean structured data and got something else, reject it before it breaks the next system. And dangerous actions — if the model is proposing to call a tool, the output gate is exactly where you check whether that action is allowed before it runs. This last one ties directly to insecure output handling and excessive agency: the output gate is where “the model said to do X” gets vetted before X actually happens.

5 · How a guardrail decides

How does a guardrail make its yes-or-no decision? On a spectrum from simple to sophisticated. At the cheap end, plain rules and patterns: keyword lists, size limits — fast, predictable, easy to fool, but great for catching the obvious. In the middle, a trained classifier: a small dedicated model built to recognise categories like “this is a jailbreak attempt” or “this is toxic,” better at catching disguised attacks than fixed rules. At the sophisticated end, using a second model as a judge — asking another AI to read the request or answer and rule on whether it is safe, which is flexible but slower, costlier, and, being a model itself, potentially foolable too. Real systems layer these: quick rules screen the flood, and heavier checks judge what is left. Match the cost of the check to the stakes of the decision.

Guardrails decide with rules, a classifier, or a model judge Three approaches from cheap to sophisticated: simple rules, a trained classifier, and a second model as judge. simple rules & patterns a trained classifier a second model as judge From cheap keyword checks to an AI grading another AI’s work
Figure 2. Layer the approaches: cheap rules handle the flood, heavier judges handle the tricky remainder.

6 · Guardrails are not a force field

A vital warning, echoing the jailbreak topic: guardrails are not a force field, and treating them like one is dangerous. Every guardrail has gaps. Rules miss novel phrasings. Classifiers make mistakes. Even a model-judge can be jailbroken, because it is a model. If you build a single guardrail and declare the system safe, you have just created one wall for attackers to focus all their effort on beating — and eventually they will. The right mental model is defense in depth: several imperfect layers stacked so that an attack has to defeat all of them at once. An input rule, plus a classifier, plus an output check, plus a human review for the biggest actions. Each layer is fallible; together they are resilient. Never bet everything on one clever filter holding.

7 · Best practices for guardrails

A handful of practices make guardrails genuinely effective. Use both gates and layer them, never relying on a single check. Fail closed: when a guardrail is unsure or errors out, the safe default is to block, not wave through — an uncertain answer should get more scrutiny, not less. Log everything they catch: the blocked attempts are a goldmine, showing exactly how your system is being attacked and where the gaps are. And keep updating them: attackers invent new phrasings constantly, so guardrails are a living defense you tune over time, not a wall you build once and forget. Do these four and your guardrails keep pace with the threat instead of slowly falling behind it.

8 · A simple test you can run this week

Inspect your gates

1. Does one AI feature check its input before the model sees it?
2. Does it check the output before anyone acts on it?
3. When a guardrail is unsure, does it block or allow? Make it block.
4. Are blocked attempts logged so you can see the attacks?

The lesson: put two gates around the model, stack them, make them fail closed — and never mistake one filter for a force field.

9 · Glossary — every term, spelled out

Guardrail
A checkpoint around a model that inspects what goes in or comes out and decides whether to allow it.
Input gate
The check on requests before they reach the model — screening injections, abuse, sensitive data, and junk.
Output gate
The check on the model’s output before release — catching harmful content, leaks, bad formats, and dangerous actions.
Classifier
A small model trained to recognise categories (jailbreak, toxic) — better than fixed rules at catching disguised attacks.
Model-as-judge
Using a second AI to rule on whether a request or answer is safe — flexible but slower and itself foolable.
Fail closed
Defaulting to block when a check is uncertain or errors — the safe default for a guardrail.
Key takeaways

Guardrails are two checkpoints: an input gate screening what goes in, an output gate screening what comes out.
The output gate protects you even when the input gate is fooled — it is where dangerous actions get vetted before they run.
Guardrails decide with rules, classifiers, or a model judge — each has gaps, so layer them.
Best practice: two gates, fail closed, log what they catch, and keep tuning — never one force field.

References

  1. OWASP, Top 10 for Large Language Model Applications — input and output handling risks. owasp.org
  2. NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0). nist.gov
  3. This guide’s Jailbreaking & Guardrail Bypass, Explained From Zero — why one guardrail is never enough.
  4. This guide’s Insecure Output Handling, Explained From Zero — what the output gate is guarding against.