Why do AI agents need defense in depth?
A model can be talked into things. Prompt injection, hidden instructions in an email, web page or file the agent reads, sits first in the OWASP Top 10 for LLM applications (OWASP GenAI, LLM01, read 12 November 2026). Because no filter catches every injection, you design for the moment one gets through. NIST defines the idea as integrating people, technology and operations to establish variable barriers across multiple layers (NIST glossary, read 12 November 2026).
Which layers protect an AI agent?
| Layer | What it stops | Example |
|---|---|---|
| Identity | Untraceable actions | A separate credential per agent |
| Permissions | Over-reach | Least privilege, read-only by default |
| Input checks | Known attack patterns | Screening retrieved content |
| Output and action checks | Harmful results | Deterministic rules on amounts and recipients |
| Human approval | Irreversible mistakes | Sign-off on payments |
| Monitoring and stop | Slow drift, live incidents | Alerts and a kill switch |
The layers only help if they fail for different reasons. Two LLM filters built on the same model share blind spots; an LLM check plus a hard-coded rule do not.
How do we layer checks on our own AI-written changes?
Much of our code and content is written by agents, so every change passes several independent gates before it ships: unit tests, a full build, content audits that fail on broken rules, a scan for forbidden patterns such as private file paths, and an LLM review against a written rubric that rejects, among other things, a client name we have no clearance to publish. When a model’s output is advisory only, we bar every channel the model controls, such as citations, ids and structured fields, at a deterministic gate that fails closed. A rule the model can write around is a suggestion, not a control. Our deterministic gates run before the LLM review, so a change that fails a check that cannot be argued with never reaches the judge.