AI Safety & Guardrails: Defense in Depth for Production Systems

Why One Layer Isn’t Enough

Defense in depth isn’t an AI-specific idea — it’s a long-standing principle in security engineering generally: assume any single control can fail or be bypassed, and design the system so that failure doesn’t mean total failure. A firewall doesn’t replace host-level access control; access control doesn’t replace encryption at rest. Each layer covers a different failure mode, and an attacker has to get past all of them, not just one, for the system to actually be compromised.

LLM systems inherit this exact problem, for an LLM-specific reason: a model reads instructions and untrusted data through the same channel, with no built-in way to tell them apart. That means any single defense — a keyword filter, a well-worded system prompt — has a describable way to fail. Stacking independent layers is the response, not a workaround: even if one layer has a blind spot, the system as a whole doesn’t rely on that one layer alone to catch everything.

Try each layer below to see exactly what it catches — and, just as importantly, what it structurally cannot catch on its own:

Input Validation and Filtering

This is the first checkpoint: examining what a user sends beforeit ever reaches the model. In practice this can mean blocking known-bad patterns, rejecting malformed or oversized input, or routing suspicious requests to stricter handling. It’s cheap to run and catches a real share of unsophisticated attempts — but it only recognizes what it was built to recognize. A rephrased version of a blocked pattern, or an attack the filter simply has never seen, passes straight through. Input filtering is a useful first layer, not a complete one.

Output Filtering: Checking What the Model Actually Said

Output filtering runs on the other end: after the model generates a response, but before that response reaches the user. This catches problems regardless of how the model arrived at them — a harmful instruction the model shouldn’t have followed, or sensitive information (like PII) the model shouldn’t have repeated back, whether it leaked in through the prompt, a retrieved document, or the model’s own training data.

This site already has a concrete, working example of one output-filtering technique: PII masking. The Cloud AI vs Local AI Advanced page walks through real reversible pseudonymization code that detects and masks sensitive data — there it’s framed as protecting outbound data before it reaches a cloud provider, but the same pattern-matching idea applies just as well to a model’s outbound response: scan the text the model is about to send back, and strip or redact anything that matches a sensitive pattern before the user ever sees it.

System-Prompt-Level Guardrails — and Their Real Limitation

The third common layer is baked into the system prompt itself: explicit instructions telling the model what to do and, just as often, what not to do — stay on topic, refuse certain request types, always respond in a certain format. This is the cheapest layer to add (it’s just text) and it works well for shaping ordinary, non-adversarial behavior.

Its limitation is real and worth stating precisely, not glossing over: a system prompt is an instruction the model tries to follow, not a boundary enforced outside the model’s reasoning. Instructions and untrusted input arrive through the same channel, so a crafted input can cause the model to disregard the system prompt entirely. This is the exact mechanism covered in depth in Prompt Engineering Advanced’s prompt injection section — worth reading there for the mechanics, rather than re-explained here. The takeaway for this page: system-prompt guardrails are a real, useful layer, but never the only layer a production system should depend on.

Source: OWASP Gen AI Security Project, “LLM01:2025 Prompt Injection”

Safety vs. Guardrails: Not the Same Thing

These two words get used interchangeably in casual conversation, but they mean genuinely different things, and the difference matters for who is responsible for what. Safetyis about preventing outputs that are harmful in a general sense — content that could cause real-world harm regardless of what product it appears in. This is largely the model provider’s responsibility, built into training and provider-side filtering.

Guardrails, as used in this page and generally in production engineering, are narrower and product-specific: constraining the model’s behavior to the intended scope of a particular application. A customer-support bot that refuses to discuss competitor products isn’t enforcing safety — competitor discussion isn’t inherently harmful — it’s enforcing a guardrail: a business rule about staying inside the product’s intended scope. A single system can need both: safety layers to avoid genuine harm, and guardrails to keep the product doing the specific job it was built for.

Fun Fact

“Defense in depth” as a term predates computing entirely — it’s a military strategy concept, describing a defense that trades space for time by absorbing an attack across successive lines rather than trying to stop it cold at a single front line. Security engineering borrowed the term directly, and LLM guardrail design borrowed it a second time, from security engineering.

Test Yourself

Ready for what a jailbreak actually is, how red-teaming works in practice, and a structured guideline for building all of this into a real system? Continue to the Advanced level →