Guardrails are programmatic checks placed around a large language model to keep its inputs and outputs within safe, valid bounds. Input guardrails…
See why instructions in the prompt can't be the only line of defense.
You can tell a model in its prompt to stay on topic, never reveal secrets, and always return JSON — but it may not comply every time, and an attacker can try to talk it out of the rules. A prompt is a request; it is not enforcement.
Guardrails are the enforcement layer: deterministic code that runs before and after the model to check that inputs and outputs actually meet your rules, and to act when they don't. They turn 'please behave' into 'this is checked'.
Place checks on both sides of the model.
Input guardrails run before the model. They can reject off-topic or disallowed requests, detect and strip personal data before it reaches the model, flag likely prompt-injection attempts, and enforce length or rate limits. The goal is to keep bad or risky input from ever being processed.
Output guardrails run after the model, before the response reaches the user or another system. They validate format (is it the required JSON?), check policy (toxicity, disallowed content), detect leaked secrets or personal data, and can verify the answer is grounded in provided context. Because model output is untrusted, this side is essential — it is the last chance to catch a bad response.
Turn a failed check into a concrete action.
A validator is one specific rule with an action on failure. Common actions: block (reject the response and return a safe fallback), fix (deterministically repair it — for example, strip a leaked email or coerce to valid JSON), or re-ask (send the model feedback and have it try again). Choosing the right action per rule is the craft.
Validators can be simple (regex, schema checks, allow-lists) or model-based (a classifier judging toxicity or relevance). Fast deterministic checks run first; expensive model-based ones only when needed.
if not input_guardrails.ok(request): return safe_refusal() reply = model(request) result = output_guardrails.check(reply) if result.failed: reply = result.fix_or_reask(model) # repair or retry return reply
Input is screened before the model runs; the reply is checked after; on failure the guardrail either repairs the output or re-asks the model. Only a response that passes both sides reaches the user — enforcement, not hope.
Use existing guardrail tools well and avoid the traps.
Several frameworks provide ready guardrails and validators: Guardrails AI (schema and validator library), NVIDIA NeMo Guardrails (rule-based conversational rails), and safety classifiers like Llama Guard for moderating input and output. They give you tested building blocks so you assemble a stack rather than writing every check from scratch.
Modern guardrails are a layered stack across input, output, and tool use — not one filter.
Watch for: guarding only the input and trusting output (or vice versa) — you need both; relying on a single model-based check that can itself be fooled; adding so many checks that latency and false-positives hurt the experience; and never testing guardrails against real attack payloads. Tune thresholds, order cheap checks first, and measure both what you block and what slips through.
Guardrails are the enforcement layer around an LLM: deterministic checks that keep inputs and outputs within safe, valid bounds where prompt instructions only request compliance. Input guardrails screen requests (topic, injection, personal data); output guardrails validate responses (format, policy, leaks, grounding). Validators pair each rule with an action — block, fix, or re-ask. Frameworks like Guardrails AI, NeMo Guardrails, and Llama Guard provide building blocks. Guard both sides, layer controls, and test adversarially.
Design guardrails for a customer-support bot that must stay on topic and never leak account data. List one input and two output validators, choose a block/fix/re-ask action for each, and name one real payload you would test them against.
Why aren't prompt instructions enough to keep an LLM app safe?
Instructions ask for behavior; guardrails enforce it with checks that run before and after the model and act on failure.
What is the difference between input and output guardrails?
Guardrails sit on both sides of the model — screening risky input and validating the response before it leaves the system.
What actions can a validator take when a check fails?
Each validator pairs a rule with an action — block, fix, or re-ask — chosen to suit the specific failure.
What is a common mistake with guardrails?
Both input and output need protection; relying on a single check or one side leaves gaps, so layer controls and test them adversarially.