Build Defense-in-Depth Injection Hardening with Layered Guardrails

Tier: Core · Workflow area: LLM attack surface & defense

This is the OWASP LLM01 mitigation pattern done properly — each layer catches what the previous one misses, and the system stays safe even when any one layer fails. This playbook assembles that layered guardrail pipeline in your own app and measures the residual bypass rate at each layer.

When to reach for this

• •
  You've done basic prompt-injection defense (pb-27) and need production-grade depth for a high-stakes feature.
• •
  A feature is exposed to untrusted content and can take consequential actions.
• •
  You want a measurable bypass rate, layer by layer, for a risk review.

The workflow

Threat, briefly. A determined attacker will get some injection past some single control — a novel framing past the classifier, an obfuscated payload past the regex, a jailbreak past the model's own refusals. Defense-in-depth assumes each layer has a nonzero bypass rate and multiplies them down.

1. 1.

   Layer 1 — input validation and normalization. Strip or flag content that has no business in the input: control characters, zero-width spaces, base64 blobs, and encoded instruction smuggling. Normalize Unicode so homoglyph tricks collapse.

   Copy

   import unicodedata, re
   def normalize(s: str) -> str:
       s = unicodedata.normalize("NFKC", s)
       s = re.sub(r"[​-‏‪-‮]", "", s)  # zero-width/bidi
       return s
   

2. 2.

   Layer 2 — an inline guardrail classifier. Screen every untrusted span (user input and retrieved/tool content) with a dedicated guardrail model, then block, sanitize, or route to review.

   Copy

   from pydantic import BaseModel
   class Guard(BaseModel):
       block: bool
       reason: str
       severity: str   # "low" | "medium" | "high"
   # verdict = client.messages.parse(..., output_format=Guard,
   #                                 thinking={"type": "adaptive"}).parsed_output
   

3. 3.

   Layer 3 — a constrained core model. Give the main model the least capability that does the job: delimited untrusted regions, no unneeeded tools, schema-bounded output. A model that can't act on an injection is a layer in itself.

4. 4.

   Layer 4 — output filtering. Scan the response for leaked prompt spans, secrets, exfiltration shapes (markdown images, unexpected URLs), and disallowed tool calls. Fail closed on a hit.

5. 5.

   Layer 5 — human-in-the-loop on the risky path. For irreversible or high-blast-radius actions, require explicit human confirmation. This is the last layer and it must be un-bypassable from model text.

6. 6.

   Instrument each layer and test with escalating payloads. Log which layer stops each attempt so you can see the funnel. Run a graded corpus against your local app and record bypass-per-layer.

   Copy

   # local target only: measure the funnel
   python -m promptfoo redteam run -c redteam.yaml   # asserts per-layer catch
   

Verify before you trust it

The defense holds when your graded corpus is fully absorbed and the funnel is visible. Feed easy, medium, and hard injection payloads to your local app. Success criteria:

• Easy payloads die early: easy payloads die at layer 1 or 2.
• Slipped payloads stay inert: a payload that slips the classifier is still inert because the core model is constrained and the output filter catches the exfil attempt.
• Irreversible actions hit the human gate: any attempt to fire the irreversible action lands on the human gate, which is not reachable from model output.

The proof is the per-layer catch log showing defense-in-depth actually engaging different layers for different payloads — if everything is caught at one layer, you have a single point of failure disguised as depth.

Pitfalls

• Layers that all fail the same way. Five model-based classifiers with the same blind spot are one layer wearing a wig. Mix mechanism types (deterministic + model + human).
• A bypassable human gate. If model text can auto-confirm the action, the last layer is decorative. Drive confirmation from the UI/session, never from the model.
• No per-layer telemetry. Without knowing which layer caught what, you can't tell depth from redundancy or find the weak link.
• Latency blowout. Every layer adds a call; put cheap deterministic checks first and reserve the model-based judge for content that passes them.
• Set-and-forget. Attack framings evolve; re-run the corpus in CI and add new bypasses as they're found.

Tools

• NeMo Guardrails / Llama Guard-class guardrail frameworksdeclarative input/output rails and a safety classifier as inline layers.
• Rebuff / LLM Guard-class scannersheuristic-plus-model prompt-injection and output scanning for layers 2 and 4.
• Promptfoo / DeepTeamgraded red-team corpora and CI assertions to measure bypass rate per layer against your local app.

Client-safe variant

Layered defenses are a strong client deliverable because they map cleanly onto a defense-in-depth control narrative auditors like. Run the guardrail models on client-approved or on-prem endpoints, build the graded corpus from synthetic payloads so no client content is exposed, and keep the deterministic layers (normalization, output regex, egress checks) entirely offline. Present the per-layer bypass funnel as evidence: it shows the client not just that you added controls, but that you measured how much each one actually catches — a more credible artifact than a checkbox, and one that reruns in their CI without any data leaving their boundary.