Key points
- Guardrails are the fence put up in advance to keep AI from crossing a line. They sit outside the model, separate from whatever tendencies it picked up during training.
- They sit in roughly three places: incoming requests, outgoing answers, and the tools and permissions AI is given.
- The model's own refusals aren't enough on their own. A refusal is a tendency that can waver, so an extra outside layer is needed on top of it.
- Set the fence too tight and it blocks ordinary use along with everything else. Deciding how tight to set it is really the core of guardrail design.
- Deliberately trying to get past the fence to check that it actually holds is called red teaming. It is also used to find a model's weaknesses more broadly, not just gaps in the fence.
The analogy
A neighborhood playground has things laid down before any kid shows up: a low fence around the edge, a thick mat spread under the equipment, a handrail next to the slide.
None of it gets in the way of playing. The fence only stops a ball from rolling into the street, and the mat only softens how hard a fall lands. On a day when nothing goes wrong, nobody even notices any of it is there.
What matters is that these went in before an accident, not after one. AI services have this same kind of thing set up in advance, and that's what gets called guardrails.
In detail
Bolted on from outside, not built into the model
Two things work together when AI turns down a risky request. One is a tendency it picked up during training. That one is mixed into the model itself, so it's hard to inspect like a rule or switch on and off. That said, when the model itself can be modified directly, research suggests this tendency can weaken or even disappear. The other is a layer the service bolts on from outside the model. That one is visible as a set of rules, and it can be turned on, off, or changed.
Guardrails refer to the second kind. Being outside the model means they carry over no matter which model gets swapped in underneath, and when something goes wrong, there's a clear place to point to and fix. It's the same reason the fence and the mat stay in the same spot no matter which kid shows up to play.
A tendency and a bolted-on layer can't substitute for each other. A tendency wavers with context; a simple bolted-on layer easily misses the fine grain of what's actually being said, and a sophisticated one gets slower and costlier. That's why services stack both.
Once on the way in, once on the way out
A check on incoming requests looks at whether the request itself falls inside territory the service has decided not to touch. Get flagged here and a canned response goes out without ever reaching the model. It's fast and cheap, but it misses anything where the risk doesn't show up in the wording itself.
A check on outgoing answers looks at whether the finished answer has a problem. This is where an ordinary-looking request that drifted somewhere odd gets caught, or a case where the source material was off. The cost is time, since it only runs after the answer is generated, and there's an awkwardness to pulling back something already streaming onto the screen.
The two checks miss different things. One reads intent, the other reads outcome. That's why some services stack both.
For AI that uses tools, cutting off what a hand can reach is sturdy
A check built on wording always has gaps it can slip through. Change the phrasing and it slides past; make it too tight and ordinary language gets caught too. Something AI simply cannot do, on the other hand, can't be talked into happening by any wording at all.
For a service where AI uses tools to actually do things, the sturdiest fence in practice tends to be around permissions. Hand over only the tools a job needs, withhold write access wherever read access is enough, and put a person's confirmation in front of anything that can't be undone. No phrasing moves a hand that was never given.
The same idea covers roping off a broken piece of equipment: a switch that shuts a single feature off the moment something looks wrong stops the damage while the fix is underway.
Set it too tight and nobody gets to play
Tightening the fence comes with a cost. Safety-related questions, general explanations that happen to touch on medicine or law, fiction that includes violence, ordinary requests like these start getting caught alongside everything else. This is called over-refusal.
Over-refusal looks safe on the surface but can create two problems: the service loses its usefulness, and people may move to some other channel where checks are looser or absent. Where they land, the fence may be weaker or missing entirely.
Which is why a guardrail review always tracks two numbers together: how much of what should be blocked actually got blocked, and how much of what shouldn't be blocked got caught anyway. Look at only one and the other tends to suffer.
Checking that the fence is actually standing
Putting a fence up and having it actually hold are two different things. A rule written in a policy document can be missing from the code, or a check can get skipped while a new feature is being bolted on. That's why a separate process, run by people other than whoever built it, exists to try to get past it on purpose.
That check is red teaming. If guardrails are the side that builds the fence in advance, red teaming is the side that tries to climb over it, and the two run as a pair. Whatever gap gets found on the way over becomes material for the next layer of fence.
More precisely
The word guardrails means slightly different things depending on who's using it. Some use it broadly enough to include the safety training baked into the model itself; others narrow it to just the checks bolted on outside. This article uses the narrow sense: the inside tendency is alignment, the outside layer is guardrails.
There's more than one way to build that outside layer, too: a list of banned phrases, a small dedicated model trained to judge risk, or a large model judging against a policy document, and services often mix all three. A list is fast but misses rephrasing; a judging model is more flexible but costs more time and money. More layers means slower answers, so deciding which check runs on which request is itself part of the design.
The analogy breaks down in one place: danger on a playground is visible and can be measured in height and distance, while danger in language has a boundary that shifts case by case. A mat behaves the same no matter who falls on it, while a language check's accuracy swings a lot depending on the language and phrasing involved. And a playground can simply remove a dangerous piece of equipment outright, while an AI service first has to decide what even counts as a risky feature.
Try it yourself
Common misconceptions
It's easy to think putting up guardrails makes things safe, but actually checks made of words only lower the odds, and narrowing permissions still leaves mistakes within the allowed range. Everything downstream needs to be built assuming some requests get through anyway.
It's easy to think guardrails are just a list of banned words, but actually services layer several things, such as a model that judges risky requests, a second check on answers, and narrowed tools and permissions. For AI that uses tools, narrowing permissions works especially reliably.
It's easy to think a tighter fence is always better, but actually block enough ordinary requests and the service stops being useful, and people may move to a channel with a weaker fence, which can make the overall risk worse, not better. How tightly to set it is judged differently depending on the service and situation.
One-line summary
Guardrails are the several layers bolted on outside a model before anything goes wrong, and deciding how tight to set them is itself the design work.
Spotted an error or have a better analogy? Suggest an edit · Last updated 2026-10-18