AI guardrails
AI guardrails are the technical constraints placed around an AI system to limit what it can do and to check what it produces. They typically combine scoped permissions, validation of outputs, a second model reviewing the first, and approval steps for anything irreversible.
Also known as: AI safety controls, Model guardrails, AI controls
Last reviewed
Why guardrails matter
A model will always occasionally produce something wrong, and no amount of prompting removes that. Guardrails accept it and make it survivable: the question moves from "will it ever be wrong" to "what happens when it is".
They are also what makes delegation defensible. Granting a system the ability to act on your behalf is only reasonable if you can say precisely what it is allowed to do, how its output is checked and how an error is reversed. On agent projects the craft is in the guardrails rather than the intelligence, and it is usually what separates a convincing prototype from something an organisation can actually run on.
How guardrails work
They operate at four points, and a serious deployment uses all of them.
- Before — scoped permissions, so the system can only reach the data and actions this task requires. This is the strongest control by a wide margin.
- During — constraints on the request: what context is included, what tools may be called, limits on cost and iterations.
- After — validation of the output against a schema, and a second model checking the first for accuracy, tone or policy breaches.
- Around — approval steps for irreversible actions, a reversible audit trail, and monitoring of errors, cost and behaviour over time.
The OWASP Top 10 for LLM Applications is the standard free reference for the specific risks these address.
Guardrails vs human review
Guardrails are automated; human-in-the-loop review is a person. They are complements, and using one as a substitute for the other is a common mistake.
Guardrails scale and never get bored, so they are right for volume: schema validation, permission checks, blocking an obviously bad output. Human review brings judgement guardrails cannot encode, so it is right for the cases where being wrong is costly. The usual pattern is guardrails on everything, plus human approval on the subset that is sensitive or irreversible.
When you need them
Always, on anything that acts rather than answers — and more of them the less reversible the action. The most important single guardrail is unglamorous: give the system the narrowest permissions that let it do its job.
Guardrails matter most where a model reads text your business did not author, such as a customer email or a supplier document. That text can contain instructions the model cannot distinguish from content, which is the prompt-injection problem, and it has no complete fix at the prompt level. The defences are architectural: tight permissions, validated outputs, approval before anything irreversible, and an audit trail you can roll back.
AI guardrails: common questions
The technical constraints around an AI system that limit what it can do and check what it produces — scoped permissions, output validation against a schema, a second model reviewing the first, and approval steps for irreversible actions. They assume the model will sometimes be wrong and make that survivable.
No. Guardrails scale and catch mechanical problems like invalid output or a forbidden action. Human review brings judgement that cannot be encoded, so it belongs on cases where being wrong is costly. The usual design is guardrails on everything plus human approval on the sensitive subset.
Scoped permissions, and it is not close. Everything else limits damage after the fact, whereas narrow permissions mean the harmful action was never available. Give a system the least access that lets it do its job, especially when it reads text your business did not author.
Want to talk about your project?
Tell us what you’re trying to achieve and we’ll map the fastest credible path.