Phase 5: Guardrails & Defensive Controls · 50 min · Python · NeMo Guardrails · Guardrails AI

Guardrail Architecture Patterns

A guardrail that lives in one place is a guardrail that fails in one place.

Hiring signal: Interviewers ask 'walk me through your guardrail architecture' expecting more than 'we call an API.' Candidates who can name the layers, explain what each one stops that the others can't, and justify which layers a given risk profile actually needs are the ones staffed onto security-critical launches — the difference between an engineer who bolted on a content filter and one who designed the defense.

What you will learn

Explain the four-layer guardrail model: pre-model input filtering, retrieval scope filtering, tool-call authorization, and post-model output filtering
Identify which specific attacks each layer stops and why no single layer is sufficient on its own
Design a pluggable guardrail pipeline where stages can be added, removed, or reordered without touching the orchestration logic
Select the right subset of layers for a given application's risk profile instead of over- or under-engineering the defense

The Problem

By the time you've worked through the OWASP LLM Top 10 and RAG/agent security phases of this course, you know how many ways an LLM application can be attacked. Guardrails are the engineering answer — but most teams build them wrong the first time, and the failure mode is always the same: they put a single check in a single place and call it done.

You've already seen what happens without layered defense. A dealership's chatbot agreed, in writing, to sell a car for one dollar because nothing was checking its output against the dealership's actual pricing rules. A courier company's support bot was talked into swearing at a customer and writing a poem trashing its own employer, because the only "guardrail" was the system prompt asking it to be polite — and system prompts are suggestions, not enforcement. An airline's chatbot invented a refund policy that didn't exist, and a tribunal held the airline responsible for what its own bot said, because nothing downstream of the model checked the claim before it reached the customer.

None of these were exotic attacks. They were the predictable result of shipping a model with no independent layer checking what went in, what came out, or what the model was allowed to do. Guardrails exist to make the system's behavior enforceable by something other than the model's own judgment — because the model's judgment is exactly the thing an attacker (or an unlucky prompt) can manipulate.

The fix is not "add a better prompt." It's architecture: put enforcement at every boundary where untrusted input enters or an effect leaves the system, so that no single failure — a missed regex, a jailbroken turn, a bad retrieval — is enough to cause harm on its own.

The Four-Layer Model

Nearly every production guardrail stack — whether it's built from NeMo Guardrails, Guardrails AI, a hosted API like Lakera Guard, or fully custom code — reduces to the same four layers. They differ in where they run and what they catch, which is exactly why you need all of them rather than picking one:

Layer	Runs on	Stops
Pre-model input filtering	The raw user message, before it reaches the model	Direct injection, jailbreak phrasing, off-topic requests — cheap to check, no model call needed
Retrieval scope filtering	Documents/context pulled back by a retriever, before they enter the prompt	Cross-tenant data leakage, poisoned or out-of-scope documents entering context
Tool-call authorization	The tool call the model wants to make, before it executes	Excessive agency, injected instructions that try to turn into real side effects
Post-model output filtering	The model's generated response, before it reaches the user	PII leakage, system prompt disclosure, residual jailbreak language that slipped through

Each layer has a different attacker to catch and a different cost to run. Input filtering is cheap regex you run on every request. Output filtering is your last chance before something reaches a human. Tool-call authorization is the layer that actually prevents damage — everything upstream of it is about reducing how often you reach a dangerous tool call in the first place.

Defense-in-depth means no layer has to be perfect
A regex-based input filter will miss novel injection phrasings. A topic classifier will misclassify edge cases. That's fine — it's expected — as long as the layers are independent and a failure in one doesn't imply a failure in the others. The tool-call authorization layer doesn't care why the model wants to call delete_account; it only cares whether that call is on the allowlist and within the caller's privilege. An attacker who slips past your input filter with a clever injection still has to get through the authorization layer before anything bad actually happens. This is why "our injection detector has 94% recall" is not a security posture — it's one layer of one.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Pre-Model, Retrieval, and Output Filtering in Practice, Tool-Call Authorization and Choosing Layers for Your Risk Profile, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.