What Are LLM Guardrails? Definition, Types, and the Minimum a Shipped App Needs

LLM guardrails are checks that sit around a language model call, inspecting what goes in, what comes out and what the model is allowed to do, then allowing, blocking, rewriting or routing the result before a user or a tool sees it. They run in your code, at request time, and you decide what they check.

That last sentence is the part the definitions skip. The safety training a model ships with belongs to the vendor. A guardrail belongs to you, and it is the only layer between your users and the model that you can change on a Tuesday afternoon without waiting for anyone. This page pins the term down, sorts the four kinds a shipped app actually needs, prices the tools people reach for, and then does the thing the vendor explainers will not: it tells you when to leave them out.

Guardrails vs alignment vs a system prompt

Three things get called "safety" and they live in different places.

Model alignment is why a hosted model refuses some requests out of the box. It is real, it is useful, and it is not yours: it changes when the vendor ships a new version, and it knows nothing about what your app is for. A system prompt is closer to home, but it is a request, and jailbreaking is the study of how requests get talked out of. A guardrail is different in kind. It is a function that runs whether the model agrees or not.

That is also the answer to the question people ask first: no, a guardrail is not a second model that is smarter than the first. Some guardrails are models. Most of the useful ones are dumber than the thing they check, and that is the point.

The four kinds a shipped app needs

The academic taxonomies list five or six categories. For a builder the split that matters is what each one protects.

Input guardrails

These run on the prompt before the model sees it. The usual jobs are stripping or redacting personal data so it never leaves your environment, detecting prompt injection in text you did not write (a pasted email, a scraped page, a file upload), and keeping a narrow bot on its topic. Pattern checks and blocklists are the cheap version. A small classifier model is the expensive one.

Output guardrails

These run on the response before the user sees it. Toxicity and unsafe-content filters are the obvious case. The two that earn their keep in real apps are less obvious: checking that a response is grounded in the documents you gave the model, which is the runtime answer to hallucination, and checking that a response has the shape your code expects, which is what structured output validation is. A model that returns prose where your parser wanted JSON is a guardrail failure, not a model failure.

Tool and action guardrails

Once a model can call things, the question stops being "what did it say" and becomes "what did it do". This is the layer the chatbot-era guides barely mention and the one that matters most for anything built around an AI agent. An allowlist of tools the agent may call. Argument validation on each call. A human-in-the-loop gate on the irreversible ones, which in practice means anything that sends, deletes, pays or deploys. A wrong tool call does something rather than merely says something, so this layer is where a failure stops being embarrassing and starts being expensive.

Spend guardrails

The one nobody lists and everybody eventually adds. A per-session token budget, a per-user daily cap, and a hard stop on agent loops that have not converged. An agent re-sends context on every iteration, so cost scales with steps, and a loop that wanders for an hour on a Sunday is a guardrail problem exactly as much as a leaked phone number is.

What your builder gives you, and what it does not

Here is the shape of nearly every app that comes out of a prompt-to-app builder or a coding agent. There is a function that takes user text, adds a system prompt, calls a model, and returns the answer. The model's own alignment travels with that call. Nothing else does.

That means the default guardrail count on a freshly generated app is zero. Not because the builders are careless, but because a guardrail encodes what your app is for, and the generator does not know that. A support bot for a bakery and a support bot for a clinic need different input filters, different grounding checks and different action gates, and no template can ship both.

The good news is that the first three guardrails are small. A regex that strips card numbers and email addresses before the call. A schema check on the response. A list of the three tools the agent may use, with the "send" one behind a confirmation. That is an afternoon, and it is the afternoon most vibe-coded apps skip. If you already run the checks in the AI code security guide, this is the runtime half of the same job: that piece covers what the generated code does, this one covers what the model does once the code is live.

The minimum checklist for a vibe-coded app

Before real users can type into it, an app with a model in it needs:

1. PII stripped on the way in. Card numbers, emails, phone numbers, anything the model has no reason to see. Pattern-based, free, near-zero latency.
2. A shape check on the way out. If your code parses the response, validate it against a schema and retry or fail closed on a miss.
3. A tool allowlist. If the model can act, enumerate what it may call. Everything not on the list is a refusal.
4. A confirmation gate on irreversible actions. Send, delete, pay, deploy. A human clicks.
5. A spend cap per session and per user. With a hard stop, not a warning.
6. A grounding check if you retrieve documents. A response that cites nothing you gave it should not go out as fact.
7. A log of what was blocked. A guardrail you cannot see firing is a guardrail you cannot tune, and over-refusal is the failure users actually notice.

Items one through five are rule-based and cost nothing to run. Item six is where a classifier or a managed check earns its price. Item seven is what turns the rest from a launch task into an operating practice.

The tools, and what they cost

Four names come up in nearly every comparison. Read on 6 September 2026, from each project's own repository or pricing page.

Guardrails AI is the open-source library that ranks first for the term at the time of research, and it fits the validator-composition style: you declare what a valid input and output look like and stack checks. NeMo is the pick when the thing you are controlling is a conversation rather than a single call, and the cost of that is learning Colang. Llama Guard is a classifier, so it slots into either as the model-based check for the cases patterns miss.

Bedrock is the managed route, and its price list is the clearest public statement of what each check is worth to a vendor. At the time of writing, word filters and regular-expression PII filters are free. Content filters and denied topics cost $0.15 per 1,000 text units. Sensitive-information filters and contextual grounding checks cost $0.10 per 1,000 text units. Automated Reasoning checks cost $0.17 per 1,000 text units per policy. Read that list as a ranking of difficulty: the checks a regex can do are free everywhere, and the price rises with how much judgement the check needs.

Latency follows the same line. Vendors describe rule-based checks as near-free and classifier checks as adding measurable latency, which is why the checklist above is mostly rules. Put the classifier where the rules cannot reach, not everywhere.

When guardrails are overkill

The vendor pages will not say this, so it goes here. Guardrails are overkill when nobody untrusted can reach the model and the model cannot act.

A prototype only you use does not need input filtering. An internal tool where the only input is your own team's text does not need injection detection. A feature that produces text a human reads and then decides about, with no tool calls and no automatic downstream action, needs a shape check at most. Adding a classifier in front of a demo makes the demo slower and teaches you nothing.

The three triggers that end the exemption are simple. Strangers can type into it. The model can call something. A session can run up a bill. The first trigger turns on the input and output layers, the second turns on the tool layer, and the third turns on spend caps. Most apps hit all three the week they get their first real user, which is why the checklist is written for that week and not for the demo.

FAQ

What are LLM guardrails in simple terms? Checks around the model call, not inside the model. They inspect the prompt, the response and the actions, and they allow, block, rewrite or route before anyone sees the result.

How are they different from alignment? Alignment is trained in and belongs to the vendor. A guardrail runs at request time and belongs to you.

What are the main types? Input, output, tool or action, and spend. Dialogue rails are a subtype of the first two.

Do they stop prompt injection? They reduce it. The tool and spend layers exist because a filter will eventually miss one, and the job then is to limit what the miss can do.

Are Bedrock Guardrails free? Partly. Word and regex filters are free; content filters and denied topics are $0.15 per 1,000 text units, grounding and sensitive-information checks $0.10, Automated Reasoning $0.17 per policy, at the time of writing.

When are they overkill? When nobody untrusted can reach the model and the model cannot act. A private prototype, an internal tool, a text-only feature a human reviews.

The short version: a guardrail is the one safety layer you own, it comes in four kinds, and the first five items on the checklist are rules that cost nothing. Start there the week you get a real user, add a classifier only where the rules cannot see, and keep a log so you can tell a guardrail that is working from one that is just refusing. If you are still choosing the tools around the model, the coding agents hub is the place to judge them by their gates.