The control layer

AI guardrails: enforcing safe, valid LLM and agent behaviour

What AI guardrails are

A guardrail is a check that runs outside the model, on the model's input or output, and can pass, block, rewrite, or escalate. The model itself is non-deterministic and persuadable; a guardrail is the deterministic-or-classifier boundary you put around it so its behaviour stays inside a defined envelope. Two properties define one: where it runs (before the model sees input, or after it produces output) and how it decides (a fixed rule like a regex or schema check, or a model-based classifier that scores the content).

Guardrails are not the same as the model's own alignment or a system prompt. A system prompt is an instruction the model may ignore or be talked out of; a guardrail is code that runs regardless of what the model decided. That separation is the point — controls you can audit and test, sitting between the model and the user.

Input vs output guardrails

Guardrails come in two positions, and most production systems run both:

• Input guardrails run on the request before it reaches the model: detecting prompt-injection and jailbreak attempts, stripping or flagging PII, blocking off-topic or disallowed requests, and enforcing length or rate limits. They are the cheapest place to stop a bad interaction — the model never runs.
• Output guardrails run on the model's response before it reaches the user or a downstream tool: filtering unsafe content, checking the answer is grounded in the retrieved source, validating that structured output matches a schema, and inspecting tool calls before they execute. They are the last line — what catches a model that was successfully manipulated despite the input check.

The asymmetry matters: input guardrails protect the system from the user; output guardrails protect the user (and your downstream systems) from the model. Skipping either leaves a gap — input-only misses a hijacked generation, output-only wastes a model call on a request you could have refused up front.

Types of guardrail

Across frameworks the same families recur. Knowing them by what they enforce — not by a vendor's product name — is what lets you compose the right set.

These compose: a single request might pass through a PII redactor and an injection classifier on the way in, then a safety filter, a schema validator, and a tool-call check on the way out. Each is independent, so you add or remove one without rewriting the others.

Where guardrails sit (and the trade-offs)

Architecturally, guardrails are part of the operational plane — the layer that wraps the model and its tools. They are not free, and the trade-offs are the real design work:

• Latency. A model-based guardrail is itself an inference call. Run two on input and three on output and you have added five round-trips around every turn. Deterministic checks (regex, schema) are cheap; classifier-based checks are not — reserve them for risks a rule can't catch.
• False positives. Too strict and the guardrail blocks legitimate requests, degrading the product; too loose and it misses real ones. This threshold is a tuning problem with no universal setting — it depends on your risk tolerance and is something you pin with evals, not vibes.
• Determinism vs coverage. A rule is fast, auditable, and predictable but only catches what you enumerated; a classifier generalises to novel inputs but is itself a model that can be wrong or evaded. Most systems layer both — rules for the known, a classifier for the rest.
• Defence in depth, not a wall. No single guardrail is complete. They reduce the probability and blast radius of a bad outcome; they do not eliminate it. Treat them as one layer of the threat model in agent security, paired with least-privilege tools and bounded loops.

The main guardrail frameworks

Several open-source toolkits and platform services implement these controls. They overlap heavily; the choice is mostly about where your stack already lives and whether you want a library you host or a managed service. Verify exact capabilities against each vendor's live docs before building — this space moves quickly.

The pattern across all five is identical to the types table above: input checks, output checks, deterministic rules, and model-based classifiers. Pick by integration cost, not by feature lists that mostly converge. This site's own coach runs the same idea in miniature — a bounded loop with input and tool-call checks, built across Anthropic, AWS, and Cloudflare.

Frequently asked questions

What are AI guardrails?

AI guardrails are programmatic controls that run around a model, on its inputs and outputs, to keep its behaviour safe, on-topic, and valid. They pass, block, rewrite, or escalate content using deterministic rules (regex, schema checks) or model-based classifiers — independently of what the model itself decided, which is why they hold even when a system prompt is ignored or subverted.

What is the difference between input and output guardrails?

Input guardrails run on the request before the model sees it — detecting injection, stripping PII, blocking off-topic asks. Output guardrails run on the response before it reaches the user or a tool — filtering unsafe content, checking grounding, validating schema, and inspecting tool calls. Input guardrails protect the system from the user; output guardrails protect the user and downstream systems from the model. Production systems generally run both.

What are LLM guardrails?

LLM guardrails are the same controls applied specifically to large language model applications: the input and output checks — content, topic, format, PII, grounding, and tool validation — that wrap a single model call or an agent's loop. The term is used interchangeably with AI guardrails; LLM guardrails just names the model class they are most often built for.

Do guardrails stop prompt injection?

They reduce it, but do not eliminate it. An input guardrail can classify and block many injection and jailbreak attempts, and an output guardrail can catch a response that was successfully manipulated. But injection is an open problem — a determined attacker can craft inputs that slip past a classifier. Guardrails are one layer of defence in depth, paired with least-privilege tools; see prompt injection for the attack and why no single control fully closes it.

What are the best guardrail frameworks?

There is no single best — they converge on the same controls. Open-source options include Guardrails AI (Python validators), NVIDIA NeMo Guardrails (programmable rails in Colang), and Meta's Llama Guard (a classifier model). Managed services include Amazon Bedrock Guardrails and Azure AI Content Safety. Choose by where your stack already lives and whether you want a self-hosted library or a managed service, not by feature lists that mostly overlap.

What are the downsides of guardrails?

Three main ones: latency (model-based guardrails are extra inference calls on every turn), false positives (too strict and they block legitimate requests; too loose and they miss real ones — a threshold you must tune with evals), and a false sense of completeness (no guardrail is a wall — they lower probability and blast radius, not to zero). They are a layer of risk reduction, not a guarantee.