Glossary
Guardrails
Guardrails are rules and checks wrapped around a model to keep what goes in and what comes out within bounds, such as refusing certain requests, staying on subject, or blocking anything containing private details.
In plain terms
A fence rather than a request. Telling a model to avoid something is an instruction it will usually follow and can be talked out of by whoever is typing. A guardrail is separate code that inspects the request before it arrives or the answer before it leaves, and refuses. The difference matters entirely: one is persuadable and the other is not.
Why it matters
Anything that must never happen needs something other than a polite request in a prompt. Long conversations drift, material the model reads can carry instructions of its own, and a determined person will get past trained caution eventually. A check that runs outside the model is unaffected by any of that, which is why the design you want puts your embarrassments in the instructions and your disasters in code.
How it works
Checks run on the way in, on the way out, or both. Incoming checks catch requests you do not want handled at all, and outgoing ones catch answers you do not want sent, such as anything containing an account number or a name that should not have surfaced. Outgoing checks are the more valuable of the two and the ones you are more likely to be missing.
They are ordinary software, which is the point. Pattern matching, lists of things to refuse, a second model asked to judge whether an answer is acceptable, or a rule that simply will not permit an action above a threshold. None of it is clever and none of it can be persuaded by a well-crafted paragraph.
Every guardrail has two failure directions and tuning is a trade between them. Set them tightly and legitimate work gets blocked, which is the failure people complain about loudly. Set them loosely and things get through, which is the failure nobody notices until it matters. Both are real and only one of them reaches you as a complaint.
The most valuable ones are usually not about content at all. Requiring a person before anything irreversible, capping what can be spent, limiting which records an action may touch: those are guardrails in the same sense and they prevent the expensive kind of incident rather than the embarrassing kind.
Asking and checking, which look similar and are not
Seen in the wild
Put an approval step in front of the one action in a flow that cannot be undone, which is a guardrail that has nothing to do with what the model said.
n8nNotice where an assistant declines something entirely harmless, which is trained caution overshooting rather than a check outside the model.
ClaudeAdd a step that inspects an answer before it is sent anywhere and stops it if it contains something it should not.
Make
Common misconceptions
People assume
Telling the model not to do something is a guardrail.
In fact
That is an instruction, and instructions are followed rather than enforced. They work most of the time, drift over long conversations, and can be overridden by text the model reads later. A guardrail is code that checks and refuses, and the two should not be confused when deciding what a system is allowed to do.
People assume
The provider's safety measures are enough.
In fact
Theirs govern what the model will produce and stop at their boundary. What your system may reach, which actions run unsupervised, and what happens to an answer once it leaves your organisation are yours to check. Those are also the parts with contractual consequences.
Telling them apart
Guardrails vs System prompt
Guardrails
Code that checks and refuses. Rigid, harder to build, unaffected by anything the model reads or is told.
Standing instructions asking the model to behave a certain way. Flexible, immediate, and defeated by a sufficiently determined conversation.
Anything embarrassing gets an instruction. Anything that must never happen gets code. Confusing the two is how a rule that mattered turns out to have been a polite request.
Questions
- Where should ours actually sit?
- Outside the model, in your own code, at the two points where things enter and leave. Anything you would have to explain to a regulator, a client or a board belongs there rather than in a prompt, because a check in code behaves identically on the thousandth request and on the one somebody engineered.
- Will they block legitimate work?
- Some of it, and that is the trade rather than a defect. Tighter settings block more real work and let less through; looser ones do the reverse. Decide which direction you would rather fail in for each specific check, because a single global setting is almost never right for every kind of request.
- What is the most valuable one to add first?
- A person in front of anything irreversible. Sending, paying, deleting and publishing are where a mistake stops being recoverable, and an approval step is simple, obvious to everybody involved, and prevents the class of incident that ends up in a meeting rather than a log file.
Key takeaways
- A guardrail checks and refuses; an instruction asks. Only one of them is persuadable.
- Checks can run on the way in and the way out, and the outgoing ones are more often missing.
- Tuning is a trade between blocking real work and letting things through, and only one of those complains.
- The most valuable ones are often not about content: approvals, spending caps and scope limits.
- The provider's measures stop at their boundary; what your system may do is yours.
Last checked July 2026