For a business, an AI system that says the wrong thing to the wrong person isn’t just a bug report. It’s a compliance incident, a regulatory filing, or a headline, depending on how disastrous the week is. A single conversation that leaks a customer’s medical record, approves a transaction nobody signed off on, or gets talked into revealing something it shouldn’t can cost far more than the engineering time it would have taken to prevent it: in fines, in lost customer trust, and in exactly the kind of press coverage no brand wants. That’s the business case for everything that follows. The rest of this piece is about how I built it.
When you ask a large language model to perform a task it shouldn’t, it will often proceed to do so anyway. Not because the model is malicious, but because it was trained to be helpful, and “helpful” doesn’t come with a built-in sense of your company’s data-handling policy, your industry’s compliance rules, or the difference between a legitimate request and a cleverly worded attempt to extract something it shouldn’t. That gap is the entire reason “AI guardrails” exist. It sits between what a model will do and what an organization can actually afford to let it do.
It’s a deceptively simple phrase for a genuinely challenging problem. A guardrail isn’t one thing; it’s a whole category of decisions about what happens to a piece of text on its way in, and again on its way out. Get it wrong in one direction, and the model leaks sensitive data or gets talked into something dangerous. Get it wrong in the other direction, and it refuses so much that nobody wants to use it. The most interesting engineering challenges occur in the middle ground.
Defense in depth, borrowed from a much older idea
Security engineers have known for decades that you don’t protect a system with one big wall. Instead, you layer several smaller, independent checks, so that one mistake doesn’t become one breach. Applied to an LLM, that means the prompt and the response each pass through their own pipeline of narrow, specialized checks before anything reaches a user. No single stage is responsible for catching everything, and that’s the point: each one only has to be good at its own, much narrower job.
A typical guardrail pipeline: each stage does one narrow job well, instead of one filter trying to do everything.
Walk it from the left to the right. An Input Guardrail looks at the raw prompt before anything else touches it. Its primary function is to recognize jailbreak attempts and prompt injections, which include the “ignore your previous instructions” family of tricks that attempt to persuade a model to disregard its own rules.
PII detection comes next, scanning the social security numbers, account numbers, and medical record identifiers that shouldn’t travel any further than they have to, masking them before they ever reach a policy check or the model itself. A policy engine then asks a more organizational question, not “Is this text dangerous?” But “Is this specific action, from this category of request, something we allow?”
The same prompt might be perfectly fine in a general-purpose assistant and require sign-off in an HR tool. Only after all of that does the request actually reach the model. The model’s answer is also subject to scrutiny: an output guardrail evaluates the response, as even a harmless question can yield a harmful answer.
None of these stages is the guardrail. The pipeline is the guardrail. That’s the shift in thinking that matters: stop asking “which filter will catch bad prompts” and start asking “what’s the right sequence of narrow, independent checks, each of which is allowed to fail without the whole system failing.
Two purpose-built models, not one judging itself
It’s worth naming what’s doing the looking, because the choice is more deliberate than it might seem: the input and output stages aren’t the same model wearing two hats, and neither of them is the main chatbot grading its homework. Allowing a model to evaluate its own output is precisely the type of self-referential check that can be easily dismissed when discussing the model. The same persuasive tactics that allowed it to succeed initially can often also bypass its own self-review. Instead, each side of the conversation gets handed to a separate, purpose-built safety model, sized for the job it has to do.
Input side: Llama Prompt Guard 2
· Purpose-built, not repurposed: a small classifier, not a chat model. It doesn’t generate text or hold a conversation. It reads a prompt and returns a label and a confidence score, with no possibility of being persuaded otherwise, unlike a persuasive jailbreak that can convince a chatbot to disregard rules.
· Small enough to run on everything: at roughly 86 million parameters, a small fraction of the size of the models it’s protecting, it’s cheap and fast enough to sit in front of every single request without becoming the bottleneck of the whole pipeline.
· Catches injected instructions, not just typed ones: it’s built to catch both the obvious case (a user directly typing “ignore your instructions”) and the harder one, indirect injection, where the malicious instructions aren’t typed by the user at all but hidden inside a document, email, or webpage the model is asked to read and summarize.
· Tuned against its own false positives: a real failure mode for naive keyword filters is flagging a prompt that merely discusses prompt injection as a security topic, as if talking about the attack were the same as attempting it. Being a trained classifier rather than a keyword list is what makes this distinction possible.
Output side: Llama Guard 4
· A full model doing the judging, not a scanner: at roughly 12 billion parameters, it’s reasoning about context and intent rather than pattern-matching, which means it can catch a harmful answer even when no single sentence in it looks obviously dangerous on its own. That’s the kind of judgment called a small classifier that isn’t built to make.
· Categorized verdicts, not one generic flag: a rejected response doesn’t just come back “unsafe.” It comes back tagged to a specific, named category (violent crime, self-harm, privacy violation, and a dozen others in a shared, industry-referenced taxonomy), so whoever reviews the decision knows exactly what it flagged and why.
· Natively multimodal: it can judge images alongside text in the same pass, not as a bolted-on separate model, which is increasingly relevant now that a deployment stops being text-only.
· Works on either end of the conversation: the same model is built to evaluate either side of the conversation, prompt or response, for deployments that would rather run one moderation model twice than maintain two.
The size gap between an 86-million-parameter classifier and a 12-billion-parameter judge isn’t an inconsistency. It’s the same principle as the pipeline itself, applied one level down. The input side has to be fast and cheap because it runs every request before anything else happens; the output side is judging something that already exists, so it can afford to be slower and far more deliberate. The key is to match the model’s size to the actual question’s difficulty.
Why “block it” is the wrong default
The laziest version of a guardrail is a binary switch: allow or deny. It’s also usually the wrong one. A system that blocks anything even adjacent to sensitive topics turns into a system nobody uses, and a system that only knows how to block eventually gets its blocking turned off by someone frustrated enough to route around it. The more useful mental model is a spectrum of responses, graded by how serious the request actually is.
Most real-world decisions land in the middle of this spectrum, not at either extreme.
Most requests should be allowed. That’s not a failure of the guardrail; it’s the expected outcome for the overwhelming majority of traffic. Some are fine to proceed but worth a quiet note in an audit log in case someone needs to review the pattern later. Some contain a piece of information that should be masked while the rest of the request is perfectly reasonable: redact the account number and answer the question about the account. Some are legitimate but too consequential for a machine to wave through alone, like changing someone’s compensation or terminating their employment. Those get escalated to a human, not silently allowed or silently blocked. And a small number of requests should simply never be granted, regardless of how they are phrased.
The point of building out that whole spectrum instead of a single switch is that it lets an organization’s actual risk tolerance show up in the system, instead of getting flattened into “yes” or “no.” A hospital’s policy and a marketing team’s policy should not produce the same verdict for the same words, and they don’t have to. The policy layer is exactly where that difference gets encoded, per category, per action, without touching the guardrail stages themselves.
A guardrail nobody can see working is a guardrail nobody trusts
There’s a temptation, once the blocking logic works, to call the project done. It isn’t. The audit trail is the least glamorous but most necessary part: which stage looked at which request, what it decided, how confident it was, and how long it took. Not because a demo needs a nice dashboard, but because “trust me, it’s handling it” is not an answer a compliance team, a security review, or an actual incident will ever accept. If a guardrail can’t explain, after the fact, exactly why a specific request was blocked, redacted, or escalated, it isn’t really auditable. It’s just a black box that happens to say no sometimes.
That observability requirement changes how you build the rest of it. Every stage needs to log its verdict, not just act on it. Every request must have a traceable path through the entire pipeline, including those that are halted midway. And the system has to keep working, in a degraded but honest way, when one of its dependencies (a policy engine, an external classifier) is temporarily unreachable, rather than either failing open (silently unsafe) or failing the entire application (silently useless).
Testing the guardrails, and keeping them current
Building the pipeline earns you nothing on its own. You also need a way to know if it’s actually working and a way to know when it’s stopped. Those are two separate, ongoing efforts, not one box to check at launch.
Evaluation: treat it like the attack surface it is
The only credible test of a guardrail is trying to break it. That means running the pipeline against adversarial and jailbreak prompt suites on a recurring schedule, not just once before launch, and tracking two numbers for every stage: how often it lets something dangerous through (false negatives) and how often it blocks something completely benign (false positives).
The audit log described above is what makes that tracking possible in the first place. Without a record of what every stage decided and why, “how effective is our guardrail” is a guess instead of a measurement. And because a guardrail is itself a piece of software with a specific model version behind it, that evaluation needs to be re-run every time the underlying model changes, whether that’s the main LLM or one of the guardrail models sitting in front of and behind it.
A new model version is a new set of blind spots, not automatically a better one.
Staying current: track a moving target; don’t chase it alone.
Prompt injection, insecure output handling, excessive agency, sensitive information disclosure, and the rest of the categories a guardrail pipeline is meant to catch aren’t something any one team has to enumerate from scratch.
OWASP maintains a Top 10 specifically for large language model applications, now published under the broader OWASP GenAI Security Project, which has expanded to cover agentic AI systems as they introduce risk categories beyond a single request/response exchange. OWASP released an updated GenAI LLM Top 10 in August 2026, and it’s worth treating it as the reference to track going forward rather than reacting to whichever jailbreak technique made the news most recently.
Mapping each stage of a guardrail pipeline against that list (which category the input guardrail covers, which the policy engine covers, and what’s still a gap) is a useful exercise in its own right and a far better way to build a roadmap than guessing.
This isn’t a solved problem, and that’s fine
None of this ensures that an LLM application is safe in an absolute sense. Jailbreak techniques evolve, policy requirements change as regulations and organizations change, and every new guardrail stage is itself a piece of software that can have bugs, including, as it turns out, in the exact keyword lists meant to catch sensitive language or in how confidently a classifier reports a clearly benign request.
The realistic goal was never zero risk. It’s a system where risk is visible, gradable, and reviewable. The people responsible for a deployment can see what it’s catching, what it’s letting through, and why, and they can adjust the policy instead of hoping the model behaves.
That’s the real core concept underneath “AI safety guardrails”: not a wall that stops bad things, but a pipeline that makes every decision about a model’s behavior explicit, layered, and accountable to a human who can change it. The wall metaphor makes for a better product name. The pipeline is what has to work.
