Guardrails
The safety fence set up in advance to keep AI from crossing a line
- 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 before launch, to check that it actually holds, is called red teaming.
Contents
1The 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, and the kids run around exactly as freely as they would without it.
What matters is that these went in before an accident, not after one. Nobody waited for a kid to get hurt first and then decided to lay down a mat. AI services have this same kind of thing set up in advance, and that's what gets called guardrails.
2In 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 lives inside the model, and it can't be opened up or switched on and off. 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 bolted-on layer can't read the fine grain of what's actually being said. 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 it's rare for a service to run only one of them.
Cutting off what a hand can reach is the sturdiest fence
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.
Which is why 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 creates two problems: the service loses its usefulness, and people move to some other channel that has no checks at all. Wherever they land, there's no fence there whatsoever.
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 is guaranteed 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.
3More 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.
4Try it yourself
5Common misconceptions
It's easy to think putting up guardrails makes things safe, but actually they only lower the odds, so 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 narrowing the tools and permissions AI is given works far more reliably.
It's easy to think a tighter fence is always better, but actually block enough ordinary requests and people move to a channel with no fence at all, which makes the overall risk worse, not better.
7One-line summary
In shortGuardrails 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 updated2026-09-02