Dr Anton Chuvakin Blog (Original)

Security writing since the mid-2000s. New posts are mirrored from Anton on Security on Medium.

How to Solve the Mystery of AI Defense in Depth?

By Anton Chuvakin

Back in 2023, I wrote “How to Solve the Mystery of Cloud Defense in Depth?” and ended it with “Where to next?” Well, “next” turned out to be AI. In 3 years. So this post is a belated sequel, of sorts.

Steampunk FTW!

So, before reading further, ask yourself the same two questions, with one word changed:

  1. Do you understand the concept of “defense in depth” (DiD) in security?
  2. Do you understand how DiD applies when AI is (a) the thing you defend, (b) the thing attacking you, and © the thing you defend with?

BTW, my own answers would have been “Yes!” and “Uhm… for (a) mostly, yes, for (b) I thought I did, but now I am very nervous, and for © ‘it depends’.” After the October we just had, I suspect I am not alone.

If your answer to question #1 is anything but a yes, please (re-)read “Defense in Depth” by Phil Venables. I quoted it in the cloud post, and it turns out to be even more useful for AI. Phil’s bottom line is that DiD is “about the linkage and collected effect of controls,” not arbitrary stacking. He also offers principles for placing controls, and three of them become critical with AI:

  • Positive duplication. Duplicate controls should not share one common cause of failure, so use different teams, vendors, or designs on a critical path.
  • Full complementarity. Every preventive control should have a detective control that checks the prevention actually worked.
  • Control pressure. Watch at which layer attacks are actually stopped; rising pressure deeper in the stack means it is time for redesign.

(and, again, no, defense in depth does not mean “just use more than one security control” … or, in 2026, “just use more than one LLM”)

Three schools of thought (again)

With cloud, I found three schools of thought. With AI, I found … three schools of thought. Some patterns are fractal, just like Phil says DiD should be (“Defense in depth should also be fractal”)…

  1. “Bolt-on DiD”: AI DiD is classic DiD plus one new AI layer, firewall sandwich with AI mayo, basically (or: “AI-oli sauce” as somebody wisely quipped)
  2. “DiD is dead”: AI DiD does not exist and does not matter. AI means “everything changes.” “AI can hack everything” camp lives here.
  3. “AI-native DiD”: it exists for sure, you just need to discover it for yourself …

The first view is basically “lift and shift DiD,” AI edition. Take your network, host, app, data, and D&R layers, then add “a prompt firewall” in front of the model. Bam! The layer “M” is handled too. Uhu, yeah, right … This may be “correct” if your AI use is a chatbot answering FAQ questions with no data access and no tools (hi 2022 … bye 2023). It is almost certainly wrong the moment an agent can read your mail, call an API, and push code. The new layer was bolted on, but the old layers were never told that a new kind of principal now walks among them.

The second view comes in two flavors. The defender-pessimist flavor says prompt injection is unsolvable, so securing agents is futile. The attacker-pessimist flavor says AI attackers find and exploit bugs faster than we patch, so layers no longer matter at all (I particularly disdain these ones, if you care to hear it). A vendor-flavored variant says “only AI can fight AI,” so just buy the AI and stop thinking about layers. Intuitively, but also rationally, I know this camp is wrong. “This layer is imperfect” has been true of every layer since the first firewall. Imperfect layers are the entire reason for DiD, not an argument against it!

Finally, the third view is … well, still a bit of a mystery. Let’s try to discover it together, again!

What do we know for sure?

Now for the fun part! Let’s check what we know for sure so far. Two general points first:

  • DiD almost certainly matters more with AI, not less. More autonomy, more speed, and more probabilistic components all mean more chances for any single layer to fail.
  • DiD is still about layers of controls and interlocking controls within each layer, both technical and procedural. Nothing about AI repeals this; it just stress-tests it really well.

At this stage, I hope nobody is throwing a chair at the monitor in frustration. We are good so far, right?

When AI is the thing you defend

First, AI DiD gets married to a new shared responsibility model. In cloud, the provider owned some layers. With AI, the model provider owns some layers too (safety training, abuse monitoring), while you own the context, the tools, the data, and the agent’s permissions. Know where the line is, since that line is where layers silently go missing. Many of the cloud truths and frustrations apply here. Mostly frustrations, natch.

Stacked similar models are less depth than you think. A guard LLM watching your main LLM sounds like two layers. But researchers have argued that guard models often share the same statistical failure modes as the agents they monitor. Yes, “diversity of defense” is an ancient idea — some of us are old enough to remember arguing about dual-vendor AV stacks! What’s new here is why AI layers correlate. The nastiest attacks (clever role-play, indirect prompt injection buried in a Jira ticket) don’t exploit a coding bug; they exploit the exact thing every LLM is trained to do: follow plausible instructions. Swapping Model Vendor A for Model Vendor B doesn’t fix a shared objective. The math is simple: two layers that each stop 95% of attacks give you 99.75% only if they fail independently.

So count correlated LLM layers as partial layers at best. And here is the practical twist: diversity of the question matters more than diversity of the model. A narrow check asking “is this tool call within policy?” is a genuinely different layer from a general model asking “is this prompt malicious?” So, don’t laugh at “guardian LLM”, but also don’t assume that “guardian LLM” is a wall, more of an attack poodle…

The model is probabilistic, so the agent harness must be deterministic — split across time. In the cloud post, I said IAM plays an oversized role, so you need IAM-independent controls. With AI, the context window plays the oversized role, because everything in it can be attacker-influenced (a web page, an email, a doc, a tool result). So you need security invariants outside the model’s context window that hold even when the LLM is 100% socially engineered: scoped credentials, tool allowlists, egress restrictions, sandboxes (as a layer, not as THE solution!), transaction limits, etc.

My favorite idea here: frame modern AI DiD across time: put synchronous, zero-latency deterministic gates strictly under irreversible actions (moving money, dropping tables, sending data externally, changing IAM permissions), and use asynchronous, out-of-band AI supervision for everything else — watching telemetry in parallel and ready to trip a circuit breaker if a session goes off the rails. Put synchronous friction everywhere, and the business will happily route around you with shadow agents … leaving you with exactly zero layers.

Defend the verbs, not the words. The set of possible malicious inputs is effectively infinite; the set of actions an agent can take is not (it can get large for “fat” agents). So depth shifts from filtering prompts to governing actions: what this agent may call, with what identity, on what data, and how reversibly. Phil recently called this going from “shift left” to “shift down”, pushing controls into the platform so agents inherit them. Is “agent identity” a new layer or a sublayer within IAM? Is the tool/MCP layer a new layer? I genuinely don’t know yet, just as I didn’t know whether the cloud org boundary was one.

Every guardrail needs a detective twin, and mistakes count too. Phil’s full complementarity says each preventive control needs a detective control checking that it actually works. For agents: log every tool call and alert on actions that should never happen if the guardrail held. And remember my cloud post’s ending, that DiD must cover configuration mistakes, not just threats. An agent that “helpfully” deletes a production table is a configuration mistake at machine speed. If one confused agent causes a breach, DiD was absolutely missing. Finally, a human approval is only a layer if the approver isn’t clicking “yes” 300 times a day. Fewer, better gates beat many gates.

When AI is attacking you

After unprompted II conference, I can say that things are really fun here in this section.

The time layers buy at the edge is collapsing. This is NOT “DiD is dead”, but this is where it takes a good, heavy slap, yet still survives. Classic DiD quietly assumes that each layer delays the attacker long enough for you to notice and respond. For example, “just patch it” is still a layer, but it’s getting dangerously thin (unless you VulnOps, I guess). Here is the catch, though: AI massively accelerated recon, bug hunting, and exploit weaponization at the edge, more than it accelerates post-compromise lateral movement — as of today! Once inside your environment, an AI attacker still needs credentials, still trips identity detections, and still touches systems that emit logs.

Probabilistic layers get brute-forced. An AI-armed attacker can try a thousand variants cheaply. Any layer that “usually catches it” will eventually be bypassed by someone who can afford to retry. In Phil’s terms, expect control pressure to shift deeper into your stack. The design implication is clear: harden the edge as much as you can, and invest in containment behind it: blast radius, segmentation, fast+good (sorry, do need both) detection, and fast recovery.

Some “boring” layers are back in fashion. If prevention at the edge gets thinner, the layers that limit what happens after compromise matter more: egress control, internal segmentation (I like to call it “mini-segmentation”, not as small as micro, but pretty granular anyway), immutable infrastructure, etc. (Yes, I now work at Cisco, so feel free to discount this point by 20%. But I believed it before I joined!)

When AI is defending you

Your defensive AI is a new layer and a new single point of failure. If the same model (or vendor) sits in your detection, triage, and response layers, every alert passes through one model’s judgment, which is a hidden common cause across all three. Positive duplication applies here too! The fix is not necessarily two vendors; remember “diversity of the question.” This is not “replace Firewall Vendor A + Firewall Vendor B” with “LLM Vendor A + LLM Vendor B”! For example, let one model triage, and let a different, narrow detector sample-audit what it closed. Also, a SOC agent with response permissions is a privileged identity, and its inputs are logs and alerts … some of which the attacker writes. Defensive agents need DiD as much as any other agent! Over-reliance is a thing.

AI moves the cost of depth from tuning to validation. Historically, every new layer cost precious SOC analyst blood and sweat to tune, triage, and maintain — which is why so many enterprises only had “DiD on paper.” AI in your SOC can genuinely cut that tuning toil. Free lunch? Of course not! The cost doesn’t vanish; it migrates. Instead of babysitting brittle detection rules, you now spend cycles auditing the AI’s reasoning, testing its prompts, and catching the moment an autonomous tier-1 agent confidently auto-closes a real breach. Validation never goes to zero for a probabilistic layer, so your SOC’s AI needs its own detective control (full complementarity again).

So, where are we, so far

In one table

DiD skimmable

So, where to next?

So, is “AI-native DiD” still a mystery? Less of one, I think. If I had to compress it into one line: AI makes your layers more correlated and your edge slower than the attacker, so design for correlated failure and for speed. In practice, that means synchronous deterministic gates in the agent harness for irreversible actions, asynchronous out-of-band AI supervision for everything else, diversity of the question rather than just of the model, and more value placed on containment and recovery.

Philosophizing about layers is fun, but what do you actually do on Monday morning? If you want to move from “Bolt-on DiD” to “AI-native DiD,” start with these:

  1. Correlated layers & the agent harness: inventory which of your agents’ actions are irreversible (money, deletion, external sends, permission changes), put a synchronous deterministic gate on each, and move heavy AI supervision out-of-band.
  2. Time at the edge: measure how long it takes you to patch or shield your internet-facing stack after a critical disclosure. Compare that with how fast exploitation started during, ahem, recent weeks. If the gap scares you, fund containment behind the edge.
  3. Ah, and please don’t confuse “deterministic” with, well, non-deterministic controls :-) Is model alignment a layer too? I don’t know, probably “weak yes” from me here.

Phil ended his post by saying it was meant to stimulate others to do more work on DiD. Three years after my cloud post, I am still taking him up on it. This time, though, I suspect the answer will come from practitioners who are already running agents in production, not from people like me thinking out loud on a blog…

Got any thoughts? Reactions?

Related posts:

How to Solve the Mystery of AI Defense in Depth? was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Originally published at Medium.