What is defense in depth for LLM applications?

Layered controls so no single failure causes compromise — auth, input guardrails, output guardrails, safe rendering, tool permissions, and monitoring each address different attack paths.

Is a strong system prompt enough for LLM security?

No. System prompts are not enforcement boundaries. Untrusted user text, retrieved documents, and tool outputs can attempt to override instructions; guardrails enforce policy in code.

Which OWASP LLM risks do guardrails address?

Guardrails primarily mitigate prompt injection, sensitive information disclosure, insecure output handling, and excessive agency when combined with tool policy — as part of a broader layered program.

Does running many detectors at one stage equal defense in depth?

Not alone. Depth requires different control types at different boundaries — input before inference, output before render, action checks before tools — not duplicate scans at the same hook.

How does Unified Guard fit in a defense-in-depth model?

It parallelizes multiple checks at a single boundary with aggregated decisions. You still need separate hooks before inference, after inference, and before tool execution.

How to Build Defense in Depth for LLM Applications

Defense in depth for LLM applications means no single control is trusted to prevent failure. Authentication, input validation, injection detection, data protection, output moderation, tool permissions, and monitoring each address different attack paths. When one layer misses an event, the next layer still has a chance to stop or contain harm.

This is the same principle as traditional application security — applied to probabilistic models, untrusted retrieval, and agent side effects. For guardrails terminology, see What Are AI Guardrails?. For pipeline wiring, see Add Guardrails to an LLM Application.

Why one layer is not enough

LLM apps fail in ways firewalls and auth alone do not cover:

Prompt injection manipulates instructions in user text or documents — What Is Prompt Injection?
Sensitive data enters prompts and logs accidentally — LLM Data Leakage
Unsafe output reaches browsers as executable markup — Prevent XSS from AI Content
Excessive agency lets models invoke destructive tools — Excessive Agency in LLM Apps

A strong system prompt does not substitute for enforcement at trust boundaries. Provider safety filters do not validate tool calls in your backend.

Defense-in-depth layers

Layer 1: Identity and access control

Before any LLM call:

Authenticate users and service accounts
Enforce tenancy isolation in retrieval and tools
Scope API keys and OAuth tokens per environment

Agents should not inherit broad production credentials. See Least Privilege for AI Agents and AI Agent Permissions.

This layer answers: Who is making this request, and what are they allowed to access?

Layer 2: Input validation and abuse controls

Structural validation on API payloads — max lengths, allowed MIME types, rate limits — reduces noise before semantic checks run.

This layer answers: Is this request well-formed and within quota?

It does not detect injection semantics; it prevents trivial overload and malformed attacks.

Layer 3: Input guardrails (semantic)

Screen assembled prompts for:

Prompt injection — Detect Prompt Injection, Prevent Prompt Injection
PII and secrets — Secrets Detection, Redact PII Before the LLM
Retrieved content — scan RAG chunks; Indirect Prompt Injection in RAG

curl -X POST https://www.identicapi.com/api/v1/guard \
  -H "Authorization: Bearer idapi_test_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Assembled prompt for this turn...",
    "checks": ["prompt_injection", "pii_secrets"],
    "redact": true
  }'

Block or redact before the provider call. Fail closed on secrets when policy requires it.

Layer 4: Model and prompt design

Non-security but complementary:

Clear system instructions (not a security boundary, but reduces ambiguity)
Tool descriptions that discourage misuse
Retrieval limits and citation requirements for RAG

Combine with Layer 3 — never rely on prompt wording alone.

Layer 5: Output guardrails

After inference:

Output safety — What Is AI Output Moderation?
PII echo scan on completions before storage
Verdict routing — Block vs Review

curl -X POST https://www.identicapi.com/api/v1/guard \
  -H "Authorization: Bearer idapi_test_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Model completion...",
    "checks": ["output_safety"]
  }'

Layer 6: Safe rendering and output handling

Moderation is not a HTML parser. Encode, sanitize, and deploy CSP for web UIs — Safe AI-Generated HTML, Improper Output Handling.

This layer answers: Even if moderation misses a vector, can it execute in the browser?

Layer 7: Agent and tool controls

For tool-using systems:

Tool allowlists and scoped credentials — Agent Tool Allowlist vs Blocklist (when published)
Pre-execution validation — Validate AI Tool Calls, Secure AI Agent Tools
Human approval for destructive operations — Human-in-the-Loop Agent Actions

{
  "checks": ["agent_action"],
  "agent_action": {
    "tool_name": "database",
    "action": "delete",
    "arguments": { "table": "users", "id": "123" },
    "context": "Agent proposed deletion after user request."
  }
}

The model proposes; your runtime disallows.

Layer 8: Monitoring and incident response

Log policy decisions with request_id, latency, and finding categories — not raw secrets. Alert on spikes in block verdicts. Maintain runbooks for credential rotation when secrets are detected — PII and Secrets Leakage Checklist.

Layer interaction diagram

                    ┌─────────────────────────────────────┐
                    │ L1 Auth / tenancy                   │
                    └──────────────────┬──────────────────┘
                                       ▼
                    ┌─────────────────────────────────────┐
                    │ L2 Validation / rate limits           │
                    └──────────────────┬──────────────────┘
                                       ▼
┌──────────────┐    ┌─────────────────────────────────────┐
│ RAG ingest   │───▶│ L3 Input guardrails (injection, PII) │
└──────────────┘    └──────────────────┬──────────────────┘
                                       ▼
                    ┌─────────────────────────────────────┐
                    │ L4 LLM inference                    │
                    └──────────────────┬──────────────────┘
                                       ▼
                    ┌─────────────────────────────────────┐
                    │ L5 Output guardrails                │
                    └──────────────────┬──────────────────┘
                                       ▼
                    ┌─────────────────────────────────────┐
                    │ L6 Render / sanitize / CSP          │
                    └──────────────────┬──────────────────┘
                                       ▼
                    ┌─────────────────────────────────────┐
                    │ L7 Tool guards (if agent)           │
                    └──────────────────┬──────────────────┘
                                       ▼
                    ┌─────────────────────────────────────┐
                    │ L8 Monitor / respond                │
                    └─────────────────────────────────────┘

Skip layers that do not apply (e.g., L7 for chat-only), but document the omission in your threat model.

Orchestrating multiple checks

Running many detectors does not automatically mean defense in depth — duplicate checks at the same boundary waste latency without new coverage. Place different control types at different boundaries.

Unified Guard helps at a single boundary by running parallel checks (prompt_injection, pii_secrets, output_safety, agent_action) with aggregated decision. That is breadth at one stage, not a substitute for output-stage and tool-stage layers.

See Combine AI Security Guardrails and Input vs Output Guardrails.

OWASP and framework alignment

OWASP LLM Top 10 risks map cleanly to layers:

Risk theme	Primary layers
Prompt injection	L3 input, RAG ingest
Sensitive information disclosure	L3 PII, L5 echo scan, L8 logging hygiene
Insecure output handling	L5, L6
Excessive agency	L7
Supply chain / training data	Outside runtime guardrails; ingestion governance

Use frameworks as checklists, not as proof of completeness.

Common anti-patterns

Anti-pattern	Why it fails
"We use GPT safety settings"	No tool or RAG visibility
Output moderation only	Injection and secrets already reached the model
Client-side filtering	Bypassable; exposes keys if miswired
One-shot pen test	No continuous measurement of false positives
Logging full prompts in prod	Creates a new leakage path

Building your depth model

Threat model — list assets (data, tools, reputation) and entry points (chat, API, RAG, agents).
Map controls — assign at least one layer per critical risk; note gaps.
Define fail behavior — Fail-Open vs Fail-Closed.
Measure — latency, block rates, review queue depth; Evaluate Guardrails.
Iterate — tune thresholds; do not remove layers without accepting new risk.

Production checklist snapshot

Auth and tenancy on every LLM route
Input guardrails on assembled prompts
RAG chunk scanning if sources are mixed-trust
Output guardrails before user delivery
Sanitization + CSP for web
Tool guards for agents
Structured audit logs without secrets
Incident runbook for unsafe verdicts

Expand into LLM Guardrails Checklist when you formalize release gates.

Summary

Defense in depth for LLMs is layered enforcement at distinct trust boundaries — not a pile of identical classifiers. Combine identity, semantic input checks, output safety, safe rendering, tool policy, and monitoring so a single missed signal does not become a user-visible incident.

Start orchestrating checks with Unified Guard at input and output hooks, then extend to agents and operational maturity as your surface grows.