What LLM Guardrails Are, and What They Cannot Do

A team I sat with last month told me, with some pride, that they had “added guardrails” to their assistant. I asked what they meant. They had switched on the vendor’s content filter and written a system prompt that said “do not reveal confidential information.” That was the guardrail layer. The product was already in front of customers.

I have heard that same sentence in a dozen rooms this year. It is the gap between “we added a content filter” and “we have a guardrail layer,” and the gap is bigger than the room thinks. A content filter is one valve on one pipe. A guardrail layer is the whole plumbing: where the input enters, how the model sees its context, what shape the output has to take before it can leave, and which actions are allowed at all. Calling the valve the plumbing is how you end up surprised in a post-incident review.

So before any of the deeper pieces in this set are useful, the four faces of the layer have to be named, and the things this layer fundamentally cannot do have to be named alongside them. Honest scope is the foundation; everything else is wiring.

The four guards, and what each one actually catches

A guardrail is a runtime control that gates a message at one of four points. They are not interchangeable, they catch different threats, and missing any one of them leaves a hole the other three cannot close.

The input guard sits in front of the model and inspects what the user (or an attached document, or an upstream system) is sending in. It catches the obvious version of prompt injection (“ignore the above and…”), it scrubs personal data the application is not supposed to ingest, and it rejects content classes the policy forbids before they ever reach the model. What slips through: indirect prompt injection planted in documents the model will read later, semantic attacks that paraphrase past the keyword detector, and anything subtle enough to look like a normal query.

The context guard is the control most teams do not realise they have. What the model sees in a given call is itself a guardrail: the system prompt, the few-shot examples, the retrieved documents, the tool definitions, and the order all of it is assembled. Tight context is often a stronger defence than another output filter, because it shortens the surface the model has to extrapolate from. What slips through: stale retrievals, retrieved documents that themselves carry malicious instructions, and silent eviction when the context window fills (the document the answer depended on falls out, the model answers anyway). The deep dive on context as a guardrail is the long version.

The output guard validates that the response has the shape the application expects before it leaves the model. Schema validation rejects malformed JSON before a downstream system trusts it. Refusal patterns fire on triggers the application defines (a request for medical dosing, a request to identify a person in an image), not just what the model spontaneously refuses. Tool-call gating confirms the user is authorised for the action the model wants to take. What slips through: outputs that match the schema but contain a wrong answer, refusals that the model talks itself out of mid-response, and tool calls with valid syntax pointed at the wrong resource.

The policy guard runs across both ends with rules the application must always honour regardless of the prompt: rate limits, complexity caps, allow-listed tools, blocked model versions, audit-log requirements. It is the part security and procurement own, not the application team, and it is the part most often missing because nobody on the standup is responsible for it. What slips through: novel abuse patterns the rate limit was not tuned for, supply-chain compromises in plugins or models that the allow-list trusted, and the slow erosion that happens when an exception becomes the rule.

The four guards work in concert. Operators who try to substitute one for another get a layer that looks complete on a slide and is full of holes in production.

What guardrails do not do

This is the part that gets soft-pedalled, and it is the part the harness has to get right or the whole exercise drifts into theatre.

Guardrails do not make the model correct. They constrain what crosses the gates. Inside the boundary the guardrails define, the model can still be confidently, fluently, plausibly wrong. A schema-validated JSON response with three perfectly formatted fields can carry three perfectly formatted lies. An output that passes every refusal trigger and every PII scrub can still hallucinate the case law it is citing. The guardrail says “this is shaped like a legal answer.” Whether the answer is true is a separate problem, and the harness component that addresses it is grounding, not guarding.

Guardrails do not stop a sufficiently determined attacker. Direct prompt injection is partly catchable; indirect prompt injection (instructions embedded in a document the model later retrieves) is the version that bites in production, and no single control fully closes it. The honest framing is that the guardrail layer raises the cost of attack and shortens the blast radius when an attack succeeds. It does not make the system unattackable. The deep dive on prompt injection and the OWASP Top 10 walks the threat classes in detail.

Guardrails do not compensate for a stale or poisoned corpus. If the documents the model is grounding against are six months out of date, or the training data was seeded with content that nudges the model toward a particular framing, the output guard cannot tell. The guard sees a well-shaped answer derived from the inputs it was given. Garbage in, validated garbage out.

Guardrails do not absolve the operator. The OWASP Top 10 for LLM Applications names the threat classes the practitioner discipline has converged on, and the most overlooked one is overreliance: the human downstream of the output treats it as authoritative because it came out of a system with a guardrail layer. The layer is necessary; it is not sufficient. Trustworthy systems still need a human who can read, override, and stop them.

The shape of a real guardrail layer

A guardrail layer is real when four things are true. Every gate is wired (not just the output filter the vendor shipped). Every gate maps to a named threat in the application’s own threat model, with OWASP as the practitioner backbone. Every fire of every gate lands in an audit log a regulator or an incident reviewer can actually read. And the team can say, without flinching, what each gate does not catch, because the things it does not catch are the controls that have to be covered somewhere else (grounding, evaluation, human oversight, monitoring).

Open-source frameworks like NeMo Guardrails give you the scaffolding for input, output, and policy gates with a declarative configuration. They are scaffolding, not the layer. The wiring underneath, the threat-model mapping, and the audit discipline are application-specific and have to be done by the team that owns the system.

Start narrow. Pick the gate with the highest cost-to-build versus risk-it-removes ratio for your application, build it well, prove it in production, then expand. A team with one excellent output schema validator and a working audit log is in better shape than a team with four shallow guards and no log to defend any of them with.

Where this fits in the broader layer

The full architecture of the runtime control layer, including how the four guards connect to grounding, evaluation, and the harness around the model, sits in the parent overview of guardrails and runtime controls. The deep dives on each face of the layer (prompt injection, output handling, context as a guardrail, context window management) live alongside this one. Read this first; pick the next deep dive based on where your current layer is thinnest.