Defence in depth
Stacking independent controls so one failing (and each will sometimes) doesn't mean compromise. For LLM agents, no single layer is reliable alone.
Defence in depth means using several independent safety layers instead of trusting one. For an AI agent: filter suspicious input, limit what tools can do, check outputs, block unexpected network traffic, require a human to approve risky actions, and monitor everything. Any one of these can fail; an attack has to get through all of them. It matters especially for AI because the model itself can be talked out of following rules.
A castle with a moat, a wall, locked gates and guards. Crossing the moat doesn't get you the treasure.
Stacking several LLM-based checks and calling it depth. They share failure modes, so an input that fools one often fools all of them.
The layers only add up if they are independent: two classifiers from the same model family fail on the same inputs, and an LLM judging another LLM's output can be injected by the same text. Prefer layers of different kinds: probabilistic (injection and content classifiers, output scanners), structural (tool scopes, Least privilege credentials, plan-then-execute or dual-LLM separation, CaMeL-style data-flow capabilities), network (egress allowlists, image proxies), human (approval gates on irreversible actions), and detective (audit logs, anomaly alerts, red-team suites). Put the strongest, deterministic controls closest to the damage: the email tool's recipient allowlist beats any upstream classifier. Every layer has a failure mode to decide up front: security layers Fail closed. Measure each layer separately with a red-team suite so you know which ones actually catch things, and avoid layers that only exist on the architecture diagram. OWASP's LLM Top 10 (2025) is a useful checklist of where layers are missing.
Layer inventory per agent mapped to OWASP LLM Top 10; deterministic limits inside every side-effecting tool (amount caps, recipient allowlists, row caps); least-privilege credentials; egress allowlist; approvals for irreversible actions; classifier layer for detection; red-team suite (≥200 attacks) run per release with per-layer catch rates.
An e-commerce support agent can look up orders and issue refunds up to $50. Layers: (1) input classifier flags likely injections (logged, not blocking), (2) the agent only sees the authenticated customer's orders (tenant + user-scoped token), (3) refund tool enforces ≤$50 and one refund per order in code, (4) refunds >$20 need agent-supervisor approval in the console, (5) no outbound URL fetches, (6) daily anomaly report on refunds per customer. A red-team suite of 300 attacks: classifier catches 71%, but zero attacks produce an unauthorised refund because layers 2–4 are deterministic.
I'd list layers by kind (probabilistic, structural, network, human, detective), insist they're independent, put deterministic controls next to the damaging action, and measure each layer with a red-team suite. Follow-up: 'which layer would you build first?' Least-privilege tools and hard limits in the tool itself, because they hold even when the model is fully compromised.
Numbers worth knowing
- Red-team suite size
- ≥200 attackscovering direct, indirect, multi-turn and tool-output injection
- Classifier catch rate
- measure; treat as <100%probabilistic layers always leak under adaptive attack
- Unauthorised side effects in red-team
- target 0achievable only via deterministic layers
How to decide
| When | Do this |
|---|---|
| Action is irreversible or moves money | Deterministic limit in the tool + human approval. |
| Adding another check | Make it a different kind from existing layers, not another LLM judge. |
| Layer catch rate is unknown | Measure it with the red-team suite before counting it. |
| A layer can't fail closed | Don't rely on it for security; use it for detection only. |
Cost maths
Classifier layer: a small model at ~$0.10–0.25/M input (illustrative Oct 2026) on 2k tokens per request ≈ $0.0005 per request. Approval layer: supervisor time, e.g. 30 s × refunds >$20 (5% of 4k/day = 200) ≈ 1.7 hours/day. Red-team suite: 300 attacks × $0.02 = $6 per run. Each is cheap next to one fraudulent refund campaign.
Operating it
- Agent gets a new side-effecting tool
- Red-team pass rate regresses after a model upgrade
- Layers exist that have never caught anything in red-team or production
- Per-layer catch rate in the red-team suite: alert on drops >5 points
- Deterministic-limit rejections in production (amount caps, allowlists): review weekly; spikes suggest active attacks
- Approval-gate volume and rejection rate: alert on spikes
When it goes wrong
An assistant leaked another customer's order details despite three 'security layers'.
Bug-bounty report with a working injection.
All three layers were LLM-based (input classifier, system-prompt rules, output judge) built on similar models; one crafted message passed all three, and the order-lookup tool accepted any order id.
Order lookup bound to the authenticated customer's id in code, the judge kept only for detection, and a red-team suite with per-layer reporting.
Where it shows up
Sources
- OWASP Top 10 for LLM Applications 2025 — OWASP, 2025spec
- Design Patterns for Securing LLM Agents against Prompt Injections — Beurer-Kellner et al., 2025paper
- Defeating Prompt Injections by Design (CaMeL) — Debenedetti et al., 2025paper
Check yourself
Three questions. Every option is explained once you answer.