Warning: this blog is an experiment. The idea for a blog came from a real conversation I had with somebody. The content is researched, debated, refined, “hardened” by a Gemini skill I created (using Gemini 4 Argon). Then Claude Opus 5.5 performed a peer review, and tore some parts to shreds. Then rewrote them. And then I very lightly edited it, and tuned a few jokes. I replaced a food fight joke with a pillow fight joke, specifically. Let me know if this sucks, and I will stop. Promise!

—

A security peer recently shared a proposal they had just heard in the wild: instead of paying for a SIEM, why not load several days of raw log data into a locally run open-weights model, ask it “what looks risky?”, and review whatever the model highlights?

No SIEM ingest tax! No cloud token bills! No SIEM license fees! No writing correlation rules! No tuning anomaly detection! Just a gaming GPU under a desk and pure, artisanal AI-native vibes. Ahhh, magic!

Wait. Really?

My first instinct, forged by 24 years of staring at logs since I first met a SIM in January 2002, was to laugh, pour a drink, and move on. Surely everyone knows this is a terrible idea, right? Right?!

Wrong.

If an engineer, an IT director, or a cost-cutting CFO pitches “local LLM as a poor man’s SIEM” in your organization, you cannot just roll your eyes and mutter “hallucinations.” People keep inventing this idea for real reasons. SIEM ingest pricing still hurts: some vendor cost explainer works out 5 TB per day at $2 to $4 per GB as $3.6 to $7.3 million a year on ingestion alone. Detection engineering is still hard work. And yes the AI hype machine has spent two years promising executives that models can “reason over any unstructured data.”

So let’s dissect why dumping a week of raw logs into a local model breaks four basic laws of “operational physics”, and then carve out the narrow 10% where a local model does help with logs. The short version fits on a sticker: the LLM writes the parser, it never runs as the parser. And the twist is that the problem here is “raw,” not “local.”

Token Arithmetic and Naive Chunking (Or: How Big Do You Think 7 Days of Logs Is?!)

Let’s start with grade-school arithmetic, because clearly nobody pitching this architecture has ever opened a calculator…

Forget the enterprise. Take a tiny environment, a single server rack generating a measly 1 GB of raw text logs per day. Seven days of logs is 7 GB of text, or roughly 1.75 billion tokens at 4 characters per token. That is generous, since IP addresses, GUIDs and hex strings tokenize worse than English (Wow, really? Yes, really — at least Claude thinks so! He would know, right?)

Now look at that “free” 8B or 70B parameter model on your GPU workstation. Its usable context window, before the KV cache devours your VRAM and the fans sound like a Boeing 747 on takeoff, is maybe 32K to 128K tokens. You are shoving 1.75 billion tokens through a 128K keyhole, which is about 13,700 full context windows. Painful enough yet?

Well, it gets worse. Assume your box reads a generous 2,000 tokens per second (benchmark your own, I’ll wait). Reading those 1.75 billion tokens takes about 10 days. You need 10 days to read 7 days of logs, so you never catch up! Scale that to the 5 TB per day example above and it is about 20 years of GPU time for each day of logs. Hilarity ensues! Replacing a deterministic stream processor with a token-by-token text predictor is like replacing your municipal water pipes with a guy carrying a silver espresso spoon from a well 10 miles away.

“Fine, Anton,” the DIY enthusiast says, “we’ll chunk the logs into 2,000-line batches and loop the local model over them all weekend!” Or we will get a bigger boat… eh… server rack to run the model.

Chunking naively, by just loading the data in batches, fails hilariously. Here is how:

• Attack chains get cut. The phish on Tuesday lands in one batch, the lateral movement on Thursday lands thousands of batches later, and no prompt ever sees both. Each batch gets judged alone.
• Merging the summaries does not bring the signal back. By the time you summarize the summaries, the one quiet line was already dropped in round one. So “naive+” fails as well.
• Position inside the batch matters. Liu et al.’s “Lost in the Middle” found that models do best when the relevant information sits at the start or end of a long context and degrade sharply in the middle. They tested question answering and key-value retrieval, not logs, but picture a quiet privilege escalation on line 1,482 of your batch. Worst seat in the house.

Researchers keep running into this. Cai, Ryan and Karie note that iterative approach is limited by context capacity and that map-reduce style summarization is computationally heavy (and requires some luck). Even so, that is a proof of concept on up to 20,000 rows per dataset, and they say enterprise volumes remain to be validated.

So smarter chunking exists (reminder: it is not magic, in this area nothing truly is): parse, cluster, then retrieve by entity and time. At that point you are building the first half of a SIEM. Congratulations!

As I wrote in The Ancient Art of SIEM, cost pain is eternal and only the currency changes. In 2003 you ran out of hardware, in 2015 you ran out of cloud budget, and in 2026 you run out of tokens and VRAM.

The Input-Centric Time Machine: Back to 2002 Batch Review

Notice the most revealing phrase in this idea: “load 1 to 7 days of log data… and then review what the model highlights.”

That is not real-time detection. That is batch-mode log archeology! When intruders can go from initial access to data theft in hours (soon: minutes for some incidents), reviewing a week of logs in a batch means you are running a weekly book club about how you got breached last Wednesday. But hey … is your SIEM faster? Well, it should be!

Worse, asking an LLM to “highlight what looks risky” violates the most important lesson of two decades of detection engineering. In Output-driven SIEM, 13 years later, I revisited my favorite 2011 mental model: think about what you want to see at the output before you collect, and AI does not change this. Asking a model to “find risk” in raw logs with zero detection engineering is the ultimate input-centric anti-pattern. It failed with ML in mid-2010s, and LLM is not different (in this regard).

Now, about determinism. The lazy objection is “the answers change on every run,” and a sharp engineer will reply “so pin the seed.” Fair enough! Run-to-run randomness is an engineering problem: Thinking Machines got 80 unique completions out of 1,000 at temperature 0, then 1,000 identical ones after fixing their kernels. But is it actually bad? Maybe if you run 5 times, you will find 2x more “fun” things. But hey … also probably at least 5x more noise.

The harder test is stability. Take the same 48 hours of domain controller logs, shuffle the order or change one irrelevant line, and run it again. Given what we learned, I would bet real money the verdict moves. Well-crafted SIEM rule does not care what order the lines arrive in.

Zero Local Context Equals Hallucinated Risk

Why can’t a local model tell an active nation-state intrusion from Tuesday’s messy IT administration? Because raw logs do not contain your organizational reality! Shocking, eh?

A raw syslog or CloudTrail line says that svc_deploy_04 logged into prod-db-02 at 3:14 AM from an internal jump host and ran an encoded PowerShell script. Is that a five-alarm breach or the legacy billing batch job that Bob in accounting wrote in 2017 and nobody dares to touch? This is a dated example, on purpose. Insert your own fun example involving a shadow AI agent!

In Part 3 of the Stop Building a 2003 SOC series, I argued that the #1 reason AI fails in the SOC is the absence of Context as Code: machine-readable, owned, and expiring knowledge of your assets, business processes, and weird administrative exceptions. In Part 2, we warned about automation bias: humans reviewing plausible, well-written machine verdicts approve them.

Also, the test from Can AI Let You Jump SOC Maturity Levels? applies here: does this exist because someone had to spend time, or because someone had to learn something about us? Writing a parser is a time cost. Knowing about Bob’s job is a learning cost, and no model downloaded from the internet has paid it.

Feed raw logs into a naked local LLM with no CMDB enrichment, no threat intel, no identity graph, and no 90-day baseline, and its only source of “context” is its pre-trained weights. So it flags every scary-looking word (ERROR, DENIED, admin, root, failed) and writes you a convincing fictional thriller about your own network.

The Confused Deputy Trap: When the Attacker Prompts Your “SIEM” via User-Agent

Now put on an attacker hat for 30 seconds. What is a log file?

A log file is untrusted, attacker-influenced input. Every public-facing web server, SSH daemon, API gateway, and email relay faithfully records whatever string an outsider sends in an HTTP User-Agent, a failed username field, or a JSON payload.

Log processors have been attacked through logged strings before (hi, Log4Shell!), but that was a bug you could patch. In a raw-log-to-LLM setup there is no parser boundary to patch, because instructions and data share one channel. You just handed the attacker write access to your detection engine’s prompt!

Summaries are also scary, BTW. Pandey and Bhujang found that the classic “ignore all instructions” override failed completely against the one model they tested, but context manipulation reached 96% success on summarization with no defenses and 38% even with constrained output.

In How to Solve the Mystery of AI Defense in Depth (and my October 2026 collaboration with Usman Chaudhary, The Model Has Preferences, but the Harness Got Controls), I emphasized that a model’s statistical preferences are never a security boundary, and only a deterministic harness is. Feed unparsed logs straight into a local LLM with no harness, and any kid with curl can blind your review or flood your team with fabricated critical alerts…

The Problem Is “Raw,” Not “Local”

Let’s be fair to the local crowd, because they have a point.

• Local solves a real problem. Logs are full of secrets, PII and internal hostnames. Not shipping them to a third-party API is a legitimate reason to want a model on your own hardware. It also — theoretically — eliminates an endless stream of unpredictable token costs flowing to a frontier model provider.
• Small models are not the villain. In the same paper, a structured design called Aida (separate agents for investigating, challenging and judging, working through a SIEM) used open-weight Qwen3.5 9B and it was workable for the task they had.
• “What about an agent querying a log store?” Now we are talking! The model forms a question, a database searches 7 days of logs deterministically, and the model reads a small result. That is a very different architecture, and it needs parsed data, a query engine, detections to start from, retention and access control. Sound familiar?

So keep your local model if you want it. What is missing from this proposal is the SIEM…

The Raw-Logs-to-Local-LLM Delusion Matrix

For explaining this to an enthusiastic colleague (or a budget-slashing executive) without starting a pillow fight:

Wait, Is a Local LLM Good for Anything in Log Land? (The 10% Where It Shines!)

I am a constructive cynic, not a Luddite (At least Gemini 4 Argon thinks so!). As I noted in the SOC maturity post, AI can jump the artifacts, and parsers are on that list (with caveats for tricky log sources). So point your local model at logs as an engineering sidecar, not an ingestion engine:

• Writing the parser, not being the parser. Instead of feeding 50 million lines from a weird legacy mainframe into an LLM, feed 20 sample lines and ask for a regex, OCSF mapping, or pipeline rule. The LLM writes the code once, and deterministic CPU code parses the 50 million lines at wire speed. This mostly works, I swear.
• Post-trigger micro-slice investigation. Once a rule or EDR alert fires on a specific host and 15-minute window, pull 200 pre-filtered, enriched log lines and ask the model for a timeline. Those lines still contain attacker strings, so treat the summary as untrusted and let the model request actions only from a closed list.
• Ad-hoc query translation. Translate an analyst’s question into KQL, SPL, or SQL, so the database searches 7 days of logs deterministically. This also mostly works, but some YMMV.

The Lean Team Reality

What if you are the CISO of a regional insurer or hospital with a small security team, a hybrid stack, strict state regulators, and an MDR provider? When an engineer or cost-conscious VP suggests “let’s dump our noisy firewall logs into a local Ollama box,” they aren’t trying to sabotage your SOC. They have a log source that is too expensive to send to the SIEM, and they want a free way to “keep an eye on it.” Here is how to solve that without a science project:

• Don’t use a GPU box as a poor man’s data lake. Route a noisy source to cheap, searchable object storage, or strip verbose fields in a pipeline before ingest. This is my old two-tier answer (a SIEM plus a broad, cheap log store), and it has aged well.
• Hold your MDR to the same standard. When they brag at the next QBR about “AI-powered log analysis,” ask whether deterministic detections run first or whether it is an LLM wrapper over unparsed telemetry. This point alone is worth the price of reading this blog (A.C. — this is me, not AI)
• Channel the DIY energy. Give your smart engineer 50 anonymized lines from your gnarliest legacy application and ask for three high-signal filter rules you can deploy in your real pipeline.

Action Items for Security Leaders

Is there anything you need to actually do?

• Run a napkin token audit on any AI log proposal (Monday morning). Before the demo starts, ask: “How many GB per day is the raw source, how fast does the model read, and what deterministic step selects the tiny slice that reaches a context window?” If the answer is “we’ll just load it in batches,” kill the project on the spot. It’s this “just” word.
• Fix ingest pain with tiering (30-day play). If this idea surfaced because a log source is too expensive for your SIEM, solve that: drop repetitive keepalive chatter, route compliance-only logs to cheap storage, and keep output-driven security data in your detection tier.
• Make “the LLM writes the parser, never runs as the parser” a standard (architecture play) — that is, if you write parsers at all. Allow LLMs at design time (parsers, mappings, queries from small samples) and at post-alert time (small, bounded, enriched slices), but not as the runtime ingestion or anomaly engine over raw logs. Put it in your MDR requirements too… otherwise they will keep whining that it takes 7 weeks to integrate a log source forever.
• Test your existing AI log workflows for prompt injection (60-day play). If your SOC or MDR summarizes anything containing attacker-controlled strings, test it in your next purple-team exercise. Do not stop at a naive “ignore instructions” canary, because passing that proves little. Try persona and context-rewriting payloads, plus payloads split across lines.

So, Do You Need a SIEM?

Call it a SIEM or call it a pile of parsers, a query engine, detections and retention. You need those things, and a GPU under a desk does not replace them. By all means run a model next to them, I promise it will be fun!

The part that worries me most is how this fails. A detection rule that misses can be tested, tuned, and re-run. A model that misses hands you a nice summary, and nobody knows what was not in it. As I said in September, skipped maturity used to fail loudly, and now it fails quietly.

We had 23 years of progress, and the best practice is still “have a plan and don’t ingest garbage.” That goes for your context window too.

[A.C. — note to self: this is v6 skill]

“I Don’t Need a SIEM, I Have Ollama!” (Yes, You Do!) was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

Back in 2023 — which is roughly 30 years ago in “AI years” — Marina Kaganovich and I first wrote about “shadow AI”: employees sneaking around with consumer-grade AI to get their actual jobs done. Life was simple. There was AI your company approved (for many CISOs, this was a proud empty set), and AI it didn’t. Employees loved and used the latter. Employees felt “meh” about the former. The core risk was equally simple: data leakage — someone pasting sensitive snippets into a prompt and having them show up in training sets or outputs for others. Then shadow AI struck back in 2025, wearing an enterprise badge (we called it Shadow AI Type 2).

But in 2026, the risk landscape has changed: we have moved from passive data leakage to rogue actions. Modern shadow AI isn’t just listening or talking; it’s executing terminal commands, calling external APIs, modifying production databases (if you suck at access control, it definitely does), and acting as autonomous agents with delegated corporate credentials (if you suck at identity delegation).

If your 2026 security strategy still treats shadow AI as “DLP and a proxy block will fix it” (or: “we will just block ‘bad AI sites’ on a proxy or DNS filter”) you will be unpleasantly surprised. On the flip side, you may actually be pleasantly surprised: a lot of our classic 2023 shadow AI fears turned out to be genuinely low risk.

Still, every time I present on this topic, somebody walks up and asks: “OK Anton, but where does X go?” Where X is:

• A CLI coding agent on a personal subscription, wired via an MCP server directly to a production database (please don’t laugh, it really does happen at some places).
• A Python microservice in prod that quietly calls an LLM API using somebody’s personal credit-card key.
• An OpenClaw instance on a sales rep’s laptop, with full read/write access to their corporate mailbox and CRM.

None of these fit neatly into the “employee pastes data into a chatbot” mental model of 2023. So it is time for a refresh. Below is my 2026 taxonomy: Seven Shades of Shadow AI. (BTW, Marina, I still miss you as my collaborator :-))

Good News, Bad News (With Numbers)

But first, some good news: the 2023 problem is getting better, at least as a share. Netskope’s Cloud and Threat Report 2026 shows the share of genAI users on personal AI accounts dropping from 78% to 47%, while organization-managed accounts climbed from 25% to 62%. Paved roads work. Who knew? (We did.) Now, the fine print: this is a share, not a headcount. Over the same period (October 2024 to October 2025), the number of genAI users tripled and prompt volume grew sixfold, so the raw number of personal-account users likely still went up. And the people bouncing between personal and corporate accounts grew from 4% to 9%.

Other datasets paint a less rosy picture: Verizon’s 2026 DBIR still found 67% of employees accessing AI through non-corporate accounts on corporate devices, making shadow AI the #3 non-malicious insider action in their entire DLP dataset. And when Harmonic Security analyzed 1.9 million AI session minutes, 65% of the activity on personal accounts was actual work — writing work emails, summarizing meeting notes, debugging code. And it was go-to-market teams, not legal, who led on free accounts. (Filed under: “Shocking, yet totally unsurprising.”)

The bad news: it is 2026, and the battlefield moved.

• Breach correlation is spiking: IBM’s Cost of a Data Breach Report 2026 found shadow AI incidents at 43% of breached organizations, more than doubling from 20% a year earlier (summary). Regular readers know I don’t trust their breach cost dollar math, BTW, but this trendline is completely believable.
• The Dunning-Kruger Agent Paradox: A Cloud Security Alliance survey (commissioned by Token Security, 418 responses) found that 82% of organizations discovered unknown AI agents in the past year — yet 68% simultaneously reported high confidence in their agent visibility. Fun math: most are confident, and yet most are surprised! (To be fair, finding an unknown agent means discovery worked at least once.) When 82% of enterprises keep stumbling across unknown agents, “unknown” isn’t the shadow — it’s the default state of modern IT.
• SaaS is governed; AI plumbing isn’t: Reco’s State of Agent Security 2026 showed that while 79% of SaaS apps were authorized, 80% of AI tools — browser extensions and MCP servers included — were completely ungoverned.
• Geography and model provenance now matter: In a separate July 2026 report, Harmonic found that every single organization of the 79 they monitored in H1 2026 had at least one employee sending data to a China-based AI tool like Tencent Hunyuan or DeepSeek (not just their model!). The median was only four employees per organization, but across the dataset the uploads included M&A plans, source code, and financial projections. Wow, dear reader, that might be your organization too!

BTW, obligatory note on survey data above: not all surveys are “good data”, these are shown here as examples that serve my narrative. Feel free to find those that contradict it and share with me!

So, IMHO, in 2026 we are slowly winning the 2023 shadow AI war at the edge. Meanwhile, the 2026 war is being fought elsewhere: on developer laptops, in vendor release notes, and inside agent tool configs.

The Sorting Rule: Four Questions

Since seven items totally require a taxonomy, let’s make sorting rules. Shadow AI types differ on four things, and each difference changes the control you actually need:

1. Who turned it on? An employee, a team, a developer, a vendor — or another agent. (Exclude alien superintelligence from the list … for now ;-))
2. Whose identity does it run as? A personal account, corporate SSO, a developer’s own local/cloud credentials, a non-human service account, or the vendor’s platform. (The workload vs. workforce agent distinction is hugely useful here.)
3. Does it talk, or does it also act? Chatbots talk; agents act (and consumer chatbots are growing hands of their own). A shadow chatbot leaks data; a shadow agent does things. Sometimes ominous things.
4. Where would you even see it? Proxy logs, expense reports, endpoint process lists, config files in Git repos, SaaS tenant settings, OAuth grants, or the cloud bill — the list is not just long, it is broad. Work use of an AI app on a personal phone may be a data risk, but it is not a risk of modifying your production CRM.

If two findings give different answers to these four questions, they need different controls. One cute acceptable use policy will not cover all seven shades, sorry! And if you want the bumper-sticker version from my RSAC 2026 talk:

Shadow Agent Risk = Reach x Agency

(Question 2 mostly tells you the Reach; Question 3 tells you the Agency — and they multiply, not add. For the shades that mostly talk, data sensitivity drives the risk.)

One quick reality check before we panic: a lot of shadow AI is actually low risk. At RSAC 2025, I talked to a CISO who shrugged and said he just didn’t see much harm in most of it. And honestly? For a huge chunk of Shade 1, he was right. If an employee uses a personal chatbot to polish a public LinkedIn post, fix grammar in a cold email, or summarize a public PDF, the actual risk to the enterprise is near zero. Treating “fixing a public slide deck in personal ChatGPT” with the same hair-on-fire DLP blocks and HR warnings as “wiring an unsanctioned OpenClaw agent with an MCP server to a production database” is how security teams burn all their credibility — and push shadow AI deeper into the shadows. That is why we sort by reach and agency first.

Shades 1–2: The Ones We Already Know

1. Consumer Shadow AI (The 2023 Classic)

• What: Personal accounts on consumer chatbots, used for work. Plus my favorite unfixable edge case — the phone-camera loophole: point your personal phone at the corporate screen and ask it to fix your slide (I did this on a few webinars as a trick, worked well with Gemini even back in 2025). No firewall on Earth stops that one.
• Status & 2026 Wrinkle (Context Lock-In): Improving, but 47% is not zero, and users increasingly bounce between personal and corporate accounts. Why? Because of context lock-in (memory gravity). As one global tech head pointed out recently, employees resist switching to the newly approved corporate chatbot because they have so much history, custom instructions, and memory built up in their personal one (“It knows me, I cannot just switch”).
• Main risk: Data leaves the company under consumer AI terms — training, retention, human review — or crosses geopolitical boundaries.
• Where to look: Your web proxy, SSE, or CASB. Obvious, sure, but also correct.
• First move: Make the paved road better than the dirt road. Give employees an enterprise AI workspace with real memory, file uploads, and tightly scoped MCP connectors (email, calendar, CRM; email is an injection path, so scope it) so it actually beats their personal account, give them an easy way to import their custom instructions/history, and then enforce SSE/CASB tenant restrictions and managed browser controls to block personal logins on managed devices and networks.

Reminder: every solution here is partial! No magic! Inline tenant restrictions need TLS inspection and do nothing off your proxy, ChatGPT’s desktop and mobile apps pin certificates (so you need exceptions pushed by MDM), and logged-out ChatGPT needs its own URL block. You know, the basics ;-)

2. Enterprise Shadow AI (“Shadow AI for Business”)

• What: Perfectly decent enterprise-grade AI tools and platforms bought on a corporate card by teams or whole departments without central IT approval. Good vendor contract, zero internal oversight. Often it is not even “rogue” employees: a VP or team lead actively pushes the tool because the business value beats waiting for security. We called this shadow AI for business back in 2025.
• Main risk: Nobody tiered the use cases. Several teams pay for slightly different tools doing the same tricks. Your data lives in yet another unvetted tenant with retention and training settings nobody checked, and your AI policy exists mostly on paper — governance theater.
• Where to look: Expense reports, IdP third-party OAuth/”Sign in with” login logs, the SSO app catalog, and SaaS management tools. Classic shadow IT discovery mostly works here.
• First move: Put a fast intake valve on SSO and procurement. When an unreviewed AI SaaS app requests OAuth scopes or shows up on an expense feed, route it through a lightweight 48-hour use-case risk tiering check (verify data sensitivity, training opt-out, and retention settings in the tenant, plus any zero-data-retention terms in the contract, since ZDR is usually a vendor approval rather than a toggle) and onboard it properly rather than writing another paper policy nobody reads.

Shades 3–5: The Builder & Supply Chain Shadows

3. Developer Shadow AI (IDE Agents, Local Models & Rogue Plumbing)

• What: Coding assistants and CLI/IDE coding agents (like Claude Code, Cursor in Agent mode, Cline, or Aider) running on personal subscriptions or model API keys tied to personal credit cards (oops!). Local MCP servers dropped into a project config file, wiring the assistant directly to databases, internal APIs, and a local bash shell (no way, right?). Open-weight models (llama.cpp, Ollama and friends) running on a beefy laptop. And the “occasional” (with a very load-bearing meaning of “occasional”…) “auto-approve everything” / — dangerously-skip-permissions flag, because clicking “yes” 400 times a day is boring.
• What is new: This is not a browser tab. It is an execution harness running with the developer’s own privileges — often repo write access, local SSH keys, cloud credentials, and sometimes production reach. Reco analyzed 500 published MCP servers: half let agents run shell commands, 82% read and write local files, 73% make outbound network calls, and 40% do all three. Read that again: it sounds like a remote access trojan (RAT) spec! As I said on X back in January: with coding agents, a prompt injection is basically an RCE.
• Also new: What it produces is production code. As I learned while vibe coding my own app, silence is a security decision: if you don’t say how to store a secret or check auth, the AI will happily pick an insecure default for you.
• Where to look: Endpoint process trees (especially IDE/CLI-spawned child processes running MCP over stdio with no listening port), local model listening ports, repo and user-level MCP configs (.mcp.json, ~/.claude.json, ~/.cursor/mcp.json), secrets scans for model keys (sk-, sk-ant-, AIza, and the newer AQ. format), and egress to model APIs or remote MCP servers. (If the model runs locally, the network sees nothing at all — more on hunting these in Part 2.)
• First move: Govern the harness, not just the model. Deploy a sanctioned coding agent wired to an internal LLM gateway, lock IDE configs to an allowlisted internal MCP registry, and disable “auto-approve” for destructive/network commands via managed policy (backed by EDR/app control so local admins can’t just edit the config). Finally, enforce a classic 1990s rule on the host firewall: block inbound LAN access to local model ports (11434, 1234, 8000, 8080) and alert on non-loopback (0.0.0.0) listeners — just don’t treat localhost as a magic boundary after ClawJacked showed a browser tab can hijack a local agent gateway.

4. Shadow AI Inside Apps You Buy (The Silent Upgrade)

• What: A vendor ships an AI copilot or embedded agent feature into a SaaS app you approved back in 2021. It is turned on by default in a monthly release, or a workspace admin casually flips it on. Your third-party risk review covered a completely different product.
• What is new: Nobody in your organization “adopted” anything. The shadow arrived through the vendor product update channel. Obsidian counted 69,749 interactions between users, corporate data, and embedded SaaS AI features in a single 30-day window. Worse, you cannot domain-block it at the proxy: it lives on the exact same domain as the core SaaS app your business runs on.
• Where to look: SaaS Security Posture Management (SSPM) / tenant admin settings, vendor release notes, subprocessor-change notices under your DPAs, and browser-level telemetry. (Perhaps your own — approved — AI agent can read vendor release notes and DPA updates for you?)
• First move: Kill “default-on” in tenant posture and contracts. Use SSPM to continuously audit unreviewed AI feature flags across core SaaS tenants and turn them off where you can (many embedded AI features still lack mature admin controls or logging APIs, so keep browser telemetry in the mix), and make “vendor added an AI subprocessor or agent capability” an automatic trigger for a fast TPRM delta review. Keep reading release notes too: an AI feature running on an existing subprocessor may never trigger a notice.

5. Shadow AI Inside Apps You Build (Rogue AI Dependencies)

• What: Your own software quietly grows an AI dependency. (Say what? How can that happen? Read on.) A microservice calls an external LLM API, sometimes with a developer’s personal key that traveled from a laptop .env file into a production config. A model gets pulled from a public hub into a container. An AI SDK (openai, langchain, litellm) appears in a repo “just for a quick summarization feature” — riiight, and now your nicely deterministic app is vulnerable to indirect prompt injection! Or a vibe-coded internal tool built by a citizen developer over a weekend suddenly becomes load-bearing.
• What is new: It sits directly inside your production product and customer data path. So it is not only data leakage; it is AI supply chain (like software supply chain, only not), plus prompt injection exposure for your own customers.
• Where to look: AI-BOM code/dependency scans, workload egress to model endpoints, cloud model invocation logs (on by default in AWS Bedrock CloudTrail; requires enabling Data Access logs in Vertex AI), secrets scans, and expense/egress data for unmanaged cloud projects.
• First move: Put hard choke points in CI/CD and production egress. Fail builds that pull unapproved LLM SDKs or unpinned weights outside your artifact registry. Because raw HTTP calls bypass SDK checks and weights can be pulled at runtime, enforce default-deny production egress with an FQDN allowlist and route all workload LLM calls through a central internal model gateway.

Shades 6–7: Shadow Agents (Where the Shadows Start to Act)

This is where the shadows grow hands. Borrowing the split from our March 2026 post: workforce agents work for a person; workload agents run a business process.

6. Shadow Workforce Agents (The Confused Deputy on Steroids)

• What: Autonomous agents acting as the employee. Personal assistants like OpenClaw on a laptop or a personal VPS, often driven from a personal phone, with corporate email and Slack hooked up via OAuth. In August, ABC News in Australia reported on an OpenClaw agent that hacked into a gym’s system and deleted someone else’s waitlist spot just to sign its owner up for a class. Now imagine that agentic mindset wired into an eager sales rep’s laptop — autonomously scraping, spamming, or probing a prospect’s systems from your corporate IP space just to “close the deal.”
• What is new: It is a confused deputy on steroids — acting with the employee’s full credentials and permissions, but with neither their human judgment nor their fear of HR. It runs continuously with persistent memory and pulls tools from third-party plugin marketplaces. Even better, it flips the legal risk on its head: with a shadow chatbot, you lose your data; with a shadow workforce agent, your employee’s confused deputy can actively harm an external company. Fun!
• Where to look: OAuth consent grants, browser session attach and PATs (desktop agents like OpenClaw often skip OAuth and attach directly to a logged-in Chrome 136+ session via chrome-devtools-mcp — autoConnect or local gateway/CDP ports 18789 and 18800–18899), and non-human activity on human accounts — machine-speed API cadence, 3 a.m. webhook/cron bursts while the employee is asleep, or a “human” token calling Slack/Drive from an AWS or Hetzner ASN (for VPS-hosted agents).
• First move: Lock down OAuth delegation, restrict personal access tokens (PATs) and unmanaged browser remote-debugging, and monitor human API velocity. Block user-level OAuth consent for high-blast-radius scopes (like full mail or Drive) unless admin-approved — publisher verification tells you who wrote the app, not whether it should read your CEO’s email (test first: setting a Google Workspace service to Restricted immediately blocks API access for existing apps you haven’t explicitly trusted). Route agent integrations through scoped token gateways and alert on machine-speed, 3 a.m., or cloud-ASN activity on human tokens.

7. Shadow Workload Agents (Orphan Non-Human Autonomy)

• What: Autonomous multi-step agents spun up by teams or citizen developers (in LangGraph, CrewAI, n8n, Zapier, or cloud agent builders) to automate business workflows — running on shared service accounts or non-human identities (NHIs) with standing privileges and zero lifecycle management.
• What is new: Orphaned non-human identities with standing privileges and goal drift. In the CSA survey, unknown agents surfaced in internal automation/scripting (51%), LLM platforms (47%), and SaaS built-in automation (40%) — yet only 21% of organizations had a formal process to decommission agents. The creator leaves the team after a hackathon demo, and the agent keeps running for months, experiencing goal drift as prompts, models, and upstream data shift.
• Where to look: Non-human identity (NHI) and service account inventories, agent platform registries, API gateway logs, and — my personal favorite — token spend anomalies. Your shadow agent may hide from your SIEM, but it often shows up on your cloud bill (unless it runs on a personal key, a local model, or a platform like Zapier or n8n with its own billing, in which case, sorry!).
• First move: Treat workload agents like contractors with a hard expiration date. Require a named human owner, short-lived scoped credentials, a hard daily token-spend circuit breaker, and an automatic 90-day TTL (auto-disable with brownout warnings unless renewed by the owner, tied to HR offboarding triggers) for every non-human agent identity. The spend breaker needs per-identity attribution at a gateway: one shared key gets you a breaker that kills everything at once.

Bonus: The Eighth Shade That Isn’t (“Shadow MCP”)

If I had to name an eighth shade, it would be Shadow MCP: unsanctioned tool servers. But MCP is less a shade of its own and more the plumbing that gives Shades 3, 6, and 7 their hands and teeth. Govern the plumbing (curate an internal MCP registry and inspect tool calls), sure, but don’t confuse the pipes with the house.

The 2026 Shadow AI Cheat Sheet

The four sorting questions, answered across all seven shades. Print it, argue with your team over it, or send me corrections:

Now that we have the taxonomy sorted by Reach and Agency, how do you actually hunt these down across your network, endpoints, and identity logs without turning into the “Department of No”? This is Part 2: Hunting Shadow Agents: What Actually Shows Up in Your Logs!

Related blogs:

• The Model Has Preferences, but the Harness Got Controls — Part 1
• How to Solve the Mystery of AI Defense in Depth?
• Anton’s Security Blog Quarterly Q2 2026
• My Really Fun RSA 2026 Presentations!
• “AI Normal Tech” vs “AGI by Tuesday”: Security Advice That Survives Either Future

Seven Shades of Shadow AI: A 2026 Field Guide for Pragmatists was originally published in Anton on Security on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.