In short
A guardrail is a control that constrains what an AI feature can receive, produce or do, implemented outside the model rather than as an instruction within it. The four useful positions are input validation, output validation, permission limits on tools, and human approval before consequential actions. Instructions in a system prompt are not guardrails, because they can be overridden by content the model reads.
Outside the model, not inside it
The distinction that matters: a guardrail is enforced by code, not requested in a prompt.
"Never discuss competitors" in a system prompt is an instruction. It works most of the time and fails when someone phrases a request cleverly, or when retrieved content contains instructions of its own.
A check that runs on the output and blocks a response mentioning competitors is a guardrail. It does not depend on the model cooperating.
Both have a place. Only one is a control.
The four positions
Input guardrails run before the model sees anything. Reject requests that are too long, detect and strip personal data before it leaves your systems, filter obvious abuse, and enforce rate limits. Cheap, and they prevent cost as well as risk.
Output guardrails run on the response before the user sees it. Validate structure against a schema, check for content that must not appear, verify that cited sources exist, confirm required fields are present.
Permission guardrails limit what the system can do at all. An agent that cannot send email cannot be persuaded to send email. This is the strongest category by a distance, because it constrains capability rather than behaviour.
Approval guardrails put a person in front of consequential actions — anything irreversible or outward-facing. Converts a bad decision into a rejected suggestion.
Most production systems need all four, and most start with only the first two.
Output filtering is weaker than it looks
The common assumption is that a filter on the output catches problems. It catches some.
It cannot detect subtle wrongness. A confidently incorrect fact passes every filter, because it looks exactly like a correct one. This is the failure that matters most and the one filtering does least about.
It cannot judge appropriateness in context. A response that is fine generally may be wrong for this user, this account, or this jurisdiction.
Classifier-based filters have both error types. False positives block legitimate responses, which users experience as the product being broken. False negatives let things through.
So output filtering is a useful layer for a narrow class of problems — structural validity, forbidden content, missing citations — and not a general safety mechanism.
Structural validation is the underused one
The most reliable guardrail is also the least discussed: check that the output has the shape you require.
If a response must be JSON matching a schema, validate it and reject what does not conform. If it must reference an entity, confirm that entity exists and that this user may see it. If it must cite a source, confirm the source was in the retrieved set.
These are deterministic, cheap, and catch real failures — including injected tool calls that reference endpoints outside the schema. They are also the guardrails most likely to be missing.
Handling a triggered guardrail well
When a guardrail fires, the user experience matters more than most teams treat it.
Say what happened, in useful terms. "I can't help with that" tells someone nothing. "I can't process documents containing card numbers — remove them and try again" gives them a route.
Offer an alternative. A path to a human, a different phrasing, a narrower request.
Do not be preachy. A brief factual explanation reads as a system boundary; a paragraph of moralising reads as condescension and generates complaints.
Log it. Triggered guardrails are data about what people are trying to do, and a spike in one is worth investigating — it may be abuse, or it may be a legitimate need you have not accommodated.
Watch false positives. A guardrail blocking legitimate use is a product defect, and users cannot distinguish it from a bug.
What guardrails cannot do
Being honest about this prevents false confidence.
They cannot make output correct. Nothing catches a plausible, well-formed, wrong answer. That requires verification against a source, or a human who knows the domain.
They cannot fully prevent prompt injection. They limit what a successful injection achieves, which is the realistic goal.
They cannot substitute for permission design. A guardrail checking whether an action is appropriate is weaker than not granting the capability in the first place.
They are not a compliance argument on their own. "We have guardrails" is not evidence of anything without specifics about what they check and how they were tested.
Where to start
If you have a model-backed feature with nothing in front of it: validate output structure, cap input size, scope the tool permissions to the task, and require approval for anything irreversible.
That covers most of the realistic risk, and none of it requires a specialised product — it is ordinary engineering applied to a component that happens to be a model.
If you are putting an AI feature in front of customers and want the controls reviewed before launch, book a call.
Common questions
What is an AI guardrail?
A control that constrains what an AI feature can receive, produce or do, enforced by code outside the model rather than requested in a prompt. An instruction in a system prompt is not a guardrail, because it can be overridden by clever phrasing or by content the model reads.
Where can guardrails be applied?
Four positions: input validation before the model sees anything, output validation before the user sees the response, permission limits on what tools the system can use at all, and human approval before consequential actions. Permission limits are the strongest, because they constrain capability rather than behaviour.
Is output filtering enough to make an AI feature safe?
No. Filtering catches structural problems and forbidden content but cannot detect a confidently incorrect answer, which looks identical to a correct one. Classifier-based filters also produce false positives that users experience as the product being broken.
What should happen when a guardrail is triggered?
Explain what happened in useful terms and offer a route forward — 'I can't process documents containing card numbers, remove them and try again' rather than 'I can't help with that'. Keep it brief and factual rather than moralising, and log it, since triggered guardrails reveal what people are trying to do.
What can't guardrails do?
They cannot make output correct, since nothing catches a plausible but wrong answer without verification against a source. They cannot fully prevent prompt injection, only limit what it achieves. And they are not a substitute for not granting a capability in the first place.
