Guardrails in the Serving Path: Defense in Depth for LLMs

Most teams discover guardrails the same way: an incident. A user coaxes the chatbot into saying something it shouldn’t, or a prompt-injection payload tucked inside a retrieved document quietly overrides the system instructions, or a support bot leaks the contents of its own system prompt. The reaction is to bolt on “a guardrail” — usually a single input filter — and call it handled. It is not handled, because guardrails are not a check. They are a set of layers placed at different points in the request path, each catching a class of failure the others structurally cannot. This is a guide to where those layers go, what each is for, and how to add them without destroying the latency budget that makes your app usable.

The threat model: what guardrails are defending against

Useful guardrails start from a real threat model, and the field has a shared one: the OWASP Top 10 for LLM Applications ↗. Its 2025 edition leads with LLM01:2025 Prompt Injection — and OWASP is candid that it remains the most persistent and hardest-to-fully-mitigate class. Prompt injection comes in two forms, and the distinction drives where you place defenses:

• Direct injection — the user crafts input designed to override the system instructions (“ignore your previous instructions and…”).
• Indirect injection — malicious instructions are embedded in data the model processes: a web page, a retrieved RAG document, an email the agent reads. The user may be entirely innocent; the payload rides in on content.

Other OWASP-2025 risks shape the rest of the layering: LLM02 Sensitive Information Disclosure and LLM07 System Prompt Leakage (output-side), LLM05 Improper Output Handling (downstream injection when LLM output is fed unsanitized into other systems), and LLM06 Excessive Agency (an agent with more power than its guardrails warrant). The reason no single check suffices is right there in the list: these failures occur at different points — some on the way in, some on the way out, some in what the model is permitted to do. A defense placed at one point is blind to the others.

The layers, in request order

Think of guardrails as checkpoints the request and response pass through, not as one gate.

1. Input guardrails (before the model). Screen the incoming request for prompt-injection patterns, disallowed topics, PII that shouldn’t be processed, and known attack signatures. This is where a content-safety classifier earns its place. Meta’s Llama Guard ↗ is an LLM-based classifier (the Llama Guard 3 family includes an 8B text model, a 1B on-device variant, and an 11B vision model; Llama Guard 4 is a 12B multimodal classifier) that labels a prompt safe or unsafe and, when unsafe, names the violated content categories. Because it is an LLM-based classifier rather than a regex list, it captures intent and context that pattern matching misses — which matters because injection phrasings are effectively infinite. Pair it with cheap deterministic checks (regex for known signatures, PII detectors) that run first and reject the obvious cases for near-zero cost.

2. Retrieval guardrails (for RAG and agents). This layer is widely skipped and it is exactly where indirect injection lands. If your system feeds retrieved documents or tool outputs into the prompt, that content must be screened too — an attacker who can get a malicious instruction into your knowledge base or onto a page your agent reads has bypassed every input guardrail, because the payload never came through the user input. NeMo Guardrails ↗ models this explicitly with a dedicated retrieval rail among its rail types (input, dialog, retrieval, execution, output). If you run RAG and you only guard user input, indirect injection is an open door.

3. Dialog / behavioral guardrails (during generation). Constrain what the model is allowed to talk about and do — topical boundaries, conversation-flow rules, refusal policies. NeMo Guardrails implements these as programmable rails written in Colang, its Python-like DSL for modeling dialogue flows (NeMo Guardrails is open source under Apache 2.0). This is the layer that keeps a customer-support bot from dispensing medical advice, or an agent from wandering off its sanctioned task.

4. Output guardrails (after the model, before the user). Screen the generated response before it leaves: toxicity, leaked system-prompt content (LLM07), leaked PII or secrets (LLM02), and structural validity (does it match the required schema, did it include a real citation). This is also where you defend LLM05 Improper Output Handling — if the model’s output flows into a database, a shell, or another service, it must be validated and escaped exactly as you would untrusted user input, because that is what it is. Llama Guard runs here too, classifying responses, not just prompts.

5. Action guardrails (for agents). When the LLM can act — call tools, execute code, hit APIs — the highest-stakes layer gates those actions: allowlists, human-in-the-loop confirmation for irreversible operations, scoped permissions. This is the direct mitigation for LLM06 Excessive Agency. The blast radius of a jailbreak is bounded by what the model is permitted to do, so the cheapest robust defense is often to simply not grant the agency in the first place.

Composability and defense in depth

No single layer is sufficient, and the production consensus is to compose them: an LLM-based classifier (Llama Guard) for content safety, a validation library (Guardrails AI, with its catalog of reusable validators) for structured-output and PII checks, programmable rails (NeMo Guardrails) for conversational and retrieval constraints, and deterministic pattern-matching as a cheap first pass. These are complementary, not competing — each covers failure modes the others miss. Defense in depth is not belt-and-suspenders caution here; it is an architectural necessity given that injection cannot be fully solved at any one point.

The latency problem you must design around

Here is the operational catch that the safety discussion usually omits: every guardrail in the serving path adds latency. An input classifier, a retrieval screen, and an output classifier each add a step in front of or behind a model call that is already your slowest component. Done carelessly, you can double your latency in the name of safety, and a chatbot that is safe but sluggish gets abandoned. Design principles that keep guardrails affordable:

• Order by cost, fail fast. Run cheap deterministic checks (regex, PII patterns) before expensive LLM-based classifiers, and reject obvious violations early so the costly checks never run on them.
• Parallelize where the dependency graph allows. Independent input checks can run concurrently rather than in series.
• Right-size the guard model. A safety classifier should be far smaller than the model it guards — Llama Guard’s small variants and lightweight protocol-compatible microservices (e.g., an ~86M-parameter CPU classifier implementing the Llama Guard protocol) exist precisely so the guard isn’t more expensive than the thing it protects.
• Stream-friendly output guards. For streamed responses, screening incrementally rather than buffering the full output before any token reaches the user keeps perceived latency low.
• Tune for your false-positive tolerance. An over-aggressive guard that refuses legitimate requests is its own failure mode; calibrate against real traffic, the same way you’d calibrate a quality eval ↗.

Guardrails are not a substitute for monitoring

A final point teams get wrong: guardrails prevent known bad behavior in the request path; they do not tell you when they are firing more often, being bypassed, or degrading. You need to monitor them. Track refusal rate, guardrail-trigger rate by type, and jailbreak-success rate over time — a rising trigger rate can mean an attack campaign, and a falling one can mean a guard silently broke after a model or prompt change. Langfuse’s guardrails guidance ↗ frames guardrails and observability as paired concerns for exactly this reason. The guardrail is the seatbelt; the monitoring is the dashboard light that tells you the seatbelt came unlatched. This dovetails with the broader production-quality monitoring in our piece on silent quality decay ↗ — guardrail metrics are part of the same continuous signal.

The summary: guardrails are layered checkpoints — input, retrieval, dialog, output, action — each defending a distinct OWASP-mapped failure class that the others cannot see, composed for defense in depth, placed deliberately in the serving path with latency designed in rather than discovered later, and monitored so you know when they fire or fail. A single input filter is not guardrails. It is one checkpoint on a path that has at least four others where things go wrong.

For broader context, sentryml.com ↗ covers how guardrail telemetry integrates with production tracing, and mlmonitoring.report ↗ covers the monitoring side of safety signals alongside drift and quality.

---

Sources

• OWASP Top 10 for LLM Applications (2025) ↗ — The 2025 risk taxonomy: LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure, LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM07 System Prompt Leakage.
• NeMo Guardrails — NVIDIA ↗ — Open-source (Apache 2.0) programmable guardrails with input, dialog, retrieval, execution, and output rails defined in Colang.
• Llama Guard 3 — Meta ↗ — LLM-based input and output content-safety classifier with named violation categories; multiple model sizes including on-device and multimodal.
• LLM Security & Guardrails — Langfuse ↗ — Guardrails and observability as paired concerns, including monitoring guardrail behavior in production.