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.

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

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 Cloud Defense in Depth?”
• “Use Cloud Securely? What Does This Even Mean?!”
• “Survival of the Basics: Which Security Fundamentals Were Secretly Relying on Lazy Attackers?”
• “Where Does Shared Responsibility Model for Security Breaks in the Real World?”
• ““AI Normal Tech” vs “AGI by Tuesday”: Security Advice That Survives Either Future”
• “Defense in Depth” by Phil Venables

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.

By Jeremy Hehl

Agents can triage, enrich and correlate at machine speed. But someone still has to own the risk call. On Episode 18 of EC-Council’s The Cybersecurity Podcast, Foresite Cybersecurity’s Jeremy Hehl tells host Jay Bavisi why the fully autonomous SOC is further off than vendors suggest, and why governance is the next real frontier.

Every security operations center now claims to be “AI-powered.” For MSSPs, saying anything else risks being labeled old school. So what does an agentic AI SOC actually look like in production?

Jay Bavisi, founder of EC-Council and host of The Cybersecurity Podcast, put that question to Jeremy Hehl, Chief Cybersecurity Evangelist at Foresite Cybersecurity, where he leads the company’s Google SecOps partnership. Their 40-minute conversation covered the limits of autonomy, the future of the SIEM, the fate of L1 analysts, ISO 42001, and the post-quantum risk that keeps Hehl awake at night.

Agents compute, humans decide

Hehl sees real promise in autonomous security operations. Investigation, triage, data aggregation, enrichment and correlation can already be handled by agents “pretty seamlessly,” he said. The hurdle is risk determination: deciding whether something actually matters to the business.

“The question I always ask customers who come to us and say that they want a fully autonomous SOC is: who do we fire when something goes wrong? Do we just dismiss the agent?”

Foresite’s approach treats agents as force multipliers rather than replacements. Hehl compared it to handing analysts a tricorder, a tool that scans and characterizes a threat instantly so the human can decide what to do. Bavisi summed up the model as “agents compute, human decides,” and Hehl agreed, adding that the risk call is the deciding factor.

Is the SIEM on borrowed time?

Asked why Foresite’s Google work matters when most premier SIEMs already ship with AI built in, Hehl pointed to a coming paradigm shift in where data lives. Data sovereignty, regulated industries and ever-growing telemetry volumes are straining the traditional model.

Today, a SIEM aggregates logs into a central plane, normalizes them into fields, and runs detection logic over the result. Hehl expects that to change. Logs will increasingly stay where they reside, in a hyperscaler such as Google, Azure or AWS, and agents will synthesize the raw telemetry in place.

“The idea of a SIEM may become something that is deprecated pretty rapidly.”

He likened the economics to cell phones in the 1990s, when minutes and text messages became commoditized. Data storage will become an assumption, and providers will bill for agent activity and “token burn” instead. Keeping telemetry in BigQuery, he noted, is far cheaper than keeping it hot in a separate SIEM. “The technology has to support it, and we’re not quite there yet,” he added.

The platform is also open by design. Foresite builds primarily on Google’s Vertex AI and Gemini, but Hehl said almost any model, including Claude, can be wired in through APIs and credentials. Agents are, in effect, privileged users, though wiring in other models takes real engineering, parsing and upkeep.

Is the SIEM on borrowed time?

Bavisi raised a trend seen worldwide: L1 roles vanishing, then L2, leaving only L3. Is that simply where agentic technology is heading?

Hehl said Foresite’s experience runs the other way. “We haven’t eliminated jobs. We’ve only grown,” he said. Adding agents to triage, threat hunting and analysis has let analysts handle 10 to 15 times the workload. They dismiss false positives quickly and spend the time saved on learning and more meaningful work.

He invoked the Industrial Revolution in England and France, when coal-powered textile machinery drew a Luddite backlash and even riots. Over time, workers using the machines became far more productive, and business owners demanded more output. This is the pattern known as Jevons Paradox, and Hehl sees agentic AI in the SOC following the same path.

Having started his own career red-teaming banks and working in a SOC, Hehl knows the burnout of triaging the same alert queue “over and over and over again.” Agents that correlate alerts into single cases, surface heuristic patterns and flag statistical outliers do that work “really, really well,” he said. The drudgery goes away; the analyst does not.

The few vendors promising fully autonomous SOC operations, he added, are narrow and tightly focused. Agents that reach a decision and enforce an action must be rigorously tested and simulated, and without clean data they hallucinate. Removing human control over security posture “is pretty unlikely in the next decade or so.”

Taming a non-deterministic technology

Bavisi pressed on a core engineering problem. Ask a frontier model the same question five times and you may get five different answers. How do you build a SOC on that without hallucinations and with consistent results?

Hehl’s answer: a measured, staged deployment. Start with narrow, targeted use cases where machines clearly beat humans, such as data manipulation, API access, running queries and writing code. Then build up capability and maturity step by step.

In enterprise engagements, Foresite first gets data normalization to “basically four nines.” Only then do agents go into the automation playbooks. Hehl argued that calling an agent today is not much different from calling a cloud function that once sat as Python inside a SOAR playbook.

“If you set up markdowns and guidelines and files and restrict the identity of the agent to only do very prescriptive things, as opposed to being all-encompassing, those are the outcomes that customers are looking for.”

He also described three types of MSSP customer. Some just want their brand and stakeholders protected. Some want an extension of their blue team bench. Others come to learn the “massive wall of knobs and levers” in Google’s security portfolio. Mid-market and SMB clients mostly treat agentic capability as part of the service. Enterprises usually already run agents elsewhere in the business and need a careful path to using them for security.

Governance: the next frontier for MSSPs

The industry has swung from “fire all humans and buy all the tokens” to “fire all the tokens and hire all the humans,” Bavisi observed, and is now wobbling in the middle. Where does AI governance fit for customers?

Hehl called it “the next real frontier” for managed security providers, with ISO/IEC 42001 emerging as the benchmark in the US. As public sector bodies adopt hyperscale platforms with agentic capabilities built in, they will need observability into what fleets of agents with permissive access are doing and saying to each other. That raises hard questions: where the harness sits, what protocols apply, and how to read intent from prompts and agent behavior.

“There’s a difference between an agent that sits there and does a prescriptive task … and when we start allowing agents to quantify risk and call other tools.”

He cited Wiz, which maps every model and agent in an environment and the lines of communication between them, and partner Safe AI for observability of agent activity. The CISO’s real dilemma, he said, is simple: “I’m being told I have to deploy AI. I am deploying AI. How do I secure this?”

The forgotten middle

Bavisi divided the world into three tiers. The top 5%, such as Google, Salesforce and Microsoft, have ISO 42001, red teams and consultants. At the other end are organizations that think two ChatGPT subscriptions make them an AI company. The vast majority sit in the middle. They know AI is more than chatbots but don’t know how to adopt, defend or govern it, and they cannot afford tier-one observability tools that may cost a million dollars.

How, he asked, should a business in Hokkaido, Jordan or New Zealand handle intent drift, blast radius, agent-to-agent communication and the transfer of governance between agents?

Hehl noted a related trap. Niche AI startups often build a narrow agentic product, only for the next frontier model or hyperscaler update to build that feature in and make the company irrelevant. For the mid-market, he argued, the answer is partnership: managed providers that deliver governance and observability as part of the service, “a Sherpa through the valley.”

Having ISO 42001 vs. living it

Bavisi pointed out that ISO 42001 has more than 190 controls, and as with ISO 27001, holding the certificate and operating by it are two different things. Do organizations show compliance for regulators while running with serious gaps?

“All the time,” Hehl said. Agentic adoption remains limited in US classified environments (IL-4 to IL-6) and in multinational bodies such as the European Space Agency, a Foresite client. In the commercial world, the most governed vertical with the largest gap is healthcare and life sciences, which holds sensitive patient data and research.

His prescription is to move telemetry into the cloud. Once workloads move from physical data centers into a hyperscaler, “the policies are native by default. And when agents are deployed, they’re governed by default.” The next big push, he said, is identity and privileged access management for agents, treating them as users. Bavisi added temporal context as another layer to solve.

Consolidation, and a $250,000 query

Bavisi argued the industry has a duty to bring along the businesses “where the actual civilization exists.” How? Hehl’s one-word answer: consolidation.

By around 2035, he expects hyperscalers such as Google, Microsoft and AWS, along with CrowdStrike, Palo Alto Networks, Cisco and to some extent Oracle, to keep absorbing companies and technologies. That will make enterprise-grade tooling usable by businesses of every size from one platform. Startups will keep flourishing, and Israeli startups will stay disruptive, but Hehl predicts acquisition values will fall as vibe coding lets almost anyone build a product. He also sees Chinese and Indian AI models closing the gap with American ones, with major implications for global security over the next 20 years.

On Anthropic’s Mythos, Hehl was blunt: it is “the greatest sales tool ever created.” It has stirred fears of boogeyman vulnerabilities, but he said it is genuinely capable of discovering zero-days and attack paths that need fixing. That in turn creates business for defensive tools such as Google’s CodeMender. None of it changes the basic discipline: find attack paths, shore them up, test, repeat. “We’re never really more than 99% of the way there.”

The other barrier for the middle market is cost predictability. Token-based pricing is not yet predictable. Hehl admitted Foresite once ran an accidental $250,000 query on Gemini during iterative testing and had to ask Google for forgiveness. Predictable pricing, he said, is what will let more customers lean in.

What really blocks the move to AI-era security

Asked about the biggest obstacle to moving an organization from traditional security to an AI-era culture, Hehl named three:

• Financial opacity. Customers lack transparency on what AI will actually cost.
• Unclear goals. Organizations often lack a clear picture of what they want AI to achieve, which calls for education and enablement.
• Reluctance to hand over control. Teams that have built careers around a security posture over the past decade ask why they should introduce new pain when nothing hurts now.

Winning them over is part of the “trust motion,” he said, and some will never make the shift because of requirements that keep them where they are.

Machine-speed attacks and a post-quantum dam

What keeps Hehl up at night is machine-speed attacks, which he said “are absolutely accelerating,” and frontier models built explicitly to break software and create new attacks. Beyond that is the prospect of cryptography being cracked faster than it can be rotated.

Bavisi shared the concern. He sees cracks already forming in encryption and fears the day “the dam breaks, and we’re not ready for a PQC world.” Hehl pointed to the downstream effects on blockchain, financial systems and energy grids, and the limits of what any single defender can do.

“There’s nothing we could do as an MSSP or a security practitioner to reset global cryptography … to reset the keys that we hold dear in order for us to maintain those chains of custody, privacy, and command over those systems.”

The takeaway from the conversation, Bavisi said in closing, is that the agentic SOC “is not just in the labs. It’s already in production.” The open question is whether governance, cost models and the cryptographic foundations underneath can keep up.

Watch the full episode of The Cybersecurity Podcast by EC-Council, Episode 18, featuring Jeremy Hehl.

Jeremy Hehl, Chief Evangelist at Foresite Cybersecurity

Jeremy Hehl is Chief Evangelist at Foresite Cybersecurity, a Google Cloud Premier Partner and the 2026 Google Cloud Security Partner of the Year.

The post Who Do We Fire When the Agent Gets It Wrong? Inside the Agentic AI SOC appeared first on CISO MAG | Cyber Security Magazine.