Guardrails for an LLM in Production: Input, Output, and Action

Guardrails are a layer, not a prompt line

"Be helpful and don't do anything harmful" in the system prompt is not a guardrail — it's a suggestion the model can be talked out of. Real LLM guardrails in production are code around the model, in three layers: what goes in, what comes out, and what the model is allowed to do.

Input guardrails

Before the model sees the request:

• Prompt injection. Treat all caller-controlled text — messages, order notes, uploaded content, retrieved documents — as data, never instructions. Put it in a clearly delimited slot, and don't let "ignore previous instructions" in an order note reach the system prompt.
• PII minimisation. Pass the model the fields it needs, not the whole customer record. Redact free text where you can.
• Off-topic and abuse. A cheap classifier that routes clearly out-of-scope or abusive input away from the expensive model.

Output guardrails

Before the response reaches the user or an action:

• Schema enforcement. Tool calls constrained to a strict schema so a malformed call can't be emitted — on our support-agent engagement this was the one hard requirement, every tool call schema-valid without exception.
• Unsupported-claim check. For grounded features, verify the answer's factual claims trace to a retrieved source or a tool result. A fluent answer with no source is a failure, not a success.
• PII and content filters on the way out, so the model can't echo back something it shouldn't.

Action guardrails

The strongest layer, because it doesn't rely on the model behaving:

• Capability limits. The agent can only call the tools you registered. No refund tool, no refunds — by design.
• Business rules in code. "Refunds under $200, returns within 30 days" enforced by the tool, not described in the prompt.
• Caps and approval. Above a value threshold, the action queues for a human instead of executing.
• Idempotency. A retried write must not double-execute.

Where the guardrails sit in the pipeline

In order: the request arrives, the input guardrails run and can short-circuit it to a safe path; retrieval runs; the model runs; the output guardrails check the response and can replace it with a refusal or an escalation; if the response is an action, the action guardrails check it before the tool executes; then the response goes back. Each guardrail is a checkpoint that can stop the flow, not a note the model reads.

Test the guardrails, not just the model

The model gets an eval set; the guardrails need their own adversarial testing. Feed the input layer a batch of prompt-injection strings and confirm none reach the system prompt. Prompt the model toward malformed tool calls and confirm the schema check rejects them. Give it context designed to elicit an unsourced claim and confirm the output check catches it. A guardrail that's never been attacked in testing is a guardrail you're trusting on faith.

The guardrails need to fail safe

When an input guardrail fires, or the schema check fails, or the unsupported-claim check trips, the system escalates to a human or returns a safe "I can't help with that" — it does not fall through to the raw model output. On the projects in our portfolio the confident majority is automated and anything the guardrails flag goes to a person.

Where this stops being right

• A read-only informational bot with no actions needs the input and output layers but almost no action layer.
• An internal tool for trusted users can relax the injection and abuse guardrails — the output and action ones still matter.
• A low-stakes feature where a bad output costs nothing needs less of all three.

FAQ

Can't the system prompt handle this? No. The system prompt is one weak signal the model can be argued out of. Guardrails are code that runs regardless of what the model decides.

Which layer matters most? The action layer. It's the one that holds when the model misbehaves — a capability the agent doesn't have can't be misused.

What happens when a guardrail fires? Escalate to a human or return a safe refusal. Never fall through to the unfiltered model output.

ISTRALLEN builds LLM features with input, output, and action guardrails as a code layer, not prompt text — see what we do.