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.

In describing SIEM features, vendors almost invariably focus on numbers: how many correlation rules come out of the box, how many were added over the past year, and how many MITRE ATT&CK techniques they cover. Admittedly, these numbers matter. They do help gauge how effective a system is, and we share them from time to time too. But correlation rules aren’t a magic amulet, and having more of them doesn’t make a SIEM more effective. In fact, the total number of available rules says more about the variety of use cases the system supports. The question a hands-on SIEM analyst cares about first of all is different: which of these rules will actually work and be useful at my company? The answer is far from always obvious, and the reason isn’t even rule quality.

How correlation rules work

A rule first and foremost describes the logic: what to match against what, in what order, and within what time window. It also specifies particular event types from particular sources. For example, a rule for Active Directory group creation waits for events from the Windows Security log; a rule for suspicious network activity — DNS queries; a rule for process manipulation — triggers on events from endpoint telemetry. In other words, whether a rule works depends on whether the SIEM receives the right data in the first place.

The Active Directory rule above would be completely pointless at a company that avoids Windows on principle. It would load without errors, show up in the interface, and technically “exist” — but it would never fire. The reason is simple: the events it was built for never reach the system.

That dictates the only correct order of steps when setting up an SIEM. Don’t start out from the list of rules and then work your way toward your infrastructure. Go the other way around: first pin down which event sources are actually connected and feeding data into the SIEM, and only then see which rules will work on that data. Doing it the other way around leads to one of two outcomes: unmet expectations (hundreds of rules, almost no detections), or a laborious rule-by-rule manual slog, where the analyst opens every rule’s description, checks its event requirements, and decides whether the rule is worth using.

What the MITRE ATT&CK coverage percentage means

MITRE ATT&CK coverage is much the same story: it’s often used without a second thought as a yardstick for product effectiveness. The catch is that these are numbers in a vacuum, with no real-world conditions behind them. Coverage only makes sense for a specific set of working rules. And as we saw above, that set of rules depends on the set of event sources. That’s why the same SIEM will show different MITRE ATT&CK coverage at two different companies. Where Windows logs, endpoint telemetry, an email gateway, and network equipment are all connected, coverage will be noticeably broader than at a company with fewer sources.

Here’s the right way to read this metric: it’s not a score for the SIEM content, but a map of what your SIEM can see with its current telemetry. A tactic with low coverage is a signal that detecting it requires data you don’t have yet. Framed this way, it becomes a clear argument for a management conversation. Not “we need one more event source”, but “this part of the matrix is currently invisible to us, and here’s what it takes to close the gap”.

What’s worth checking in your SIEM

To get the most out of a SIEM, it’s worth asking yourself a few questions — not just when deploying the system, but regularly:

• Is every connected event source being handled by rules? Infrastructure changes constantly: new systems appear and new integrations get connected. Every change like this is a reason to check again whether there are now rules you should enable.
• Do I know exactly which events are required for which rules? Sometimes a rule doesn’t fire not because a whole event source is missing, but because a single event type isn’t being collected: the audit policy simply isn’t set up to capture it. Fix that oversight as soon as possible.
• Do I understand my coverage in terms of MITRE ATT&CK? The point isn’t to produce good-looking reports. It’s to prioritize which event sources to add next: which ones will give the biggest gain in visibility?

But how can you answer these questions without spending ages digging into every rule description? We have a solution.

How we can help

To help analysts find their way around the detection logic of our solution more easily, we’ve added a knowledge base section with the complete set of Kaspersky SIEM rules. In essence, it’s a tool that holds data from the official documentation for the SOC Package rule set, and makes it easy to work with that data. It has three sections:

Library. A table of all correlation rules that you can sort and filter per any column: category, MITRE tactic and technique, event source, and event type. Search works across all fields, including descriptions. Double-clicking a rule opens a card with detailed information about it.

Builder. A tool for assembling a rule set that suits the event sources you already have. The analyst just checks the boxes for the sources the company has, and gets a list of matching rules, brief statistics, and the event types that need to be set up for collection. The tool also generates a regular expression that you can paste into the search bar of the Kaspersky SIEM web interface to link all the matching rules to the correlator in a single step, with no manual picking.

MITRE. A view of the ATT&CK matrix where tactics expand into techniques and sub-techniques. Each matrix item has a card with the description from the MITRE website, and SOC Package coverage details. Covered and uncovered items are color-coded, and charts show coverage per tactic.

One more point worth stressing: the content in our SIEM is updated constantly, so it makes sense to check your setup against it not only at deployment, but after every notable change in your infrastructure. To follow the development of the Kaspersky Unified Monitoring and Analysis Platform, visit the official product page.

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.

Google said today it worked with industry partners to dismantle a botnet made up of more than 1.3 million Android TV set-top boxes that ship with malicious software which secretly rents the user’s Internet connection out to strangers and conducts advertising fraud. Experts involved in the takedown say the action is likely to sever the botnet’s access to more than 10 million additional compromised systems, including other Internet of Things (IoT) products such as Android-based healthcare devices and karaoke machines.

A report from the Google Threat Intelligence Group (GTIG) said Google has severed ties with Videostrong Technology Co., a TV box manufacturer in China that GTIG and other industry experts concluded was responsible for including malware that enrolled more than 1.3 million set-top boxes in a botnet dubbed “XCPE” (named after one of the malware’s core code components).

The global distribution of XCPE botnet infections. Image: Google Threat Intelligence Group.

The report said the XCPE botnet loaded the user’s device with software that makes their Internet address available for resale by multiple “residential proxy” services, which allow customers to rent Internet addresses as a way to anonymize their web traffic or spoof their true location. As detailed in several stories here over the past year, residential proxy services are a major source of unwanted and often malicious traffic, including account takeover activity, advertising fraud, and mass content scraping for AI projects.

“Videostrong monetized the backdoor by selling access to criminal affiliates and loading those affiliates’ malware modules onto infected devices,” the GTIG post reads, noting that Google took legal action to take down the domains and servers Videostrong used to control the botnet and install additional malware. “A device manufacturer intentionally infecting their users with malware is an unacceptable breach of trust, and represents a serious risk to those users. Without users’ knowledge or consent, infected devices were offered as a distribution mechanism for a wide array of criminal actors.”

The report notes that while TV boxes made up the the majority of the botnet, the same XCPE malware was found in other Android-based IoT products, including telehealth devices, karaoke machines, and even digital signage systems.

Google said it requires all Android device makers to pass compatibility and security tests to ensure their products don’t harm users, but that Videostrong nevertheless found a way to load their malicious software immediately after a user boots up one of these devices for the first time (Google says it has since addressed that weakness).

The GTIG report calls out a number of residential proxy providers whose software development kits were routinely downloaded by devices infected by the XCPE botnet. Those include AppSalt, also known as Honeygain, which is owned by the Vilnius, Lithuania-based Oxylabs. In October 2026, Oxylabs was relaunched under a new brand called Source, after receiving $130 million in funding from private equity firm Warburg Pincus that reportedly valued the business at $3.6 billion. Oxylabs did not respond to a request for comment.

Another provider linked to the botnet was NetNut, a once sprawling residential proxy company operated by the publicly-traded Israeli company Alarum Technologies. In July 2026, the FBI worked with industry partners to seize hundreds of domains associated with NetNut, saying the company was responsible for operating a separate botnet called Popa that enslaved TV boxes as residential proxies. Other proxy providers named in the GTIG report include EarnFM, Traffmonetizer, Jaguar, LINKFOG, BMW/IPWeb and GaGaNode.

Google’s announcement credits a number of industry partners, including Synthient, a startup that tracks proxy providers. In January 2026, Synthient published research into the rapid spread of the Kimwolf botnet, which at the time was hammering networks worldwide with record-smashing DDoS attacks. Synthient documented how Kimwolf infected millions of Android set-top boxes virtually overnight, using a widespread vulnerability in these residential proxy services to compromise other Android-based devices inside the local networks of unsuspecting TV box users.

Synthient’s research caused dozens of residential proxy providers to patch their networks, which helped to fragment the Kimwolf botnet into much smaller pieces that made its incessant and disruptive DDoS attacks far easier for network operators to manage. It also attracted the attention of the Motion Picture Association (MPA), a trade group representing the major Hollywood studios, which partnered with Synthient to purchase and tear apart a number of popular Android TV set-top boxes — including some that were being infected by Kimwolf and other IoT botnets.

In a report published today, Synthient examined a popular, pre-infected TV box sold under the brand MECOOL by a publicly traded company in China called Skyworth Technology, concluding that MECOOL also bundled the malware from Videostrong Technology Co. and likewise installed AppSalt/Honeygain and other proxy components.

The MECOOL storefront and marketing. Image: Synthient.com.

Synthient founder Ben Brundage told KrebsOnSecurity that Videostrong’s malware also distributed software for the proxy service Grass. In our November 2025 story, “Is Your Android TV Streaming Box Part of a Botnet?” we quoted a researcher from Censys who found the popular Superbox TV streaming device bundled Grass’s residential proxy software. We also quoted the Grass founder, who denied any affiliation with the TV box maker.

That November 2025 story noted that Superbox and similar Android TV set-top boxes gain new customers primarily by engaging influencers on Tiktok and other social networks who praise the product’s ability to offer hundreds of (pirated) pay TV streaming services for a one-time fee.

Likewise, Synthient’s report observes that the MECOOL set-top boxes exploded in popularity after the product was mentioned in 2023 by the Youtube channel Linus Tech Tips, which has an audience of nearly 17 million subscribers [Linus Tech Tips said in a statement shared with Synthient that it has since updated the video to explicitly frame the product as a scam and have removed all associated affiliate links].

The popular Youtube channel Linus Tech Tips discussing MECOOL TV streaming boxes.

The GTIG report estimates the XCPE botnet takedown should sever access to at least 10 million additional compromised devices, noting that the various proxy and ad fraud affiliates of Videostrong “each have diversified distribution channels for their modules beyond XCPE.”

Synthient’s Brundage echoed that conclusion, calling the 1.3 million number “highly conservative.”

“The scale of affected devices is likely way higher,” he said. “This is probably the largest operation against backdoored TV boxes that we’ve seen.”

Further reading:
Plume Security Labs white paper on the XCPE botnet (PDF)
Black Lotus Labs writeup on LinkedIn
TrendAI’s analysis
Synthient’s list of affected devices, broken down by model number

If you operate a website, you’re already aware that a single unpatched vulnerability can render your site inaccessible, compromise your reputation, or necessitate extensive remediation following an attack. Most security breaches we observe originate from automated attacks that exploit known software vulnerabilities, often the same ones that have been previously reported and disclosed.

To assist in maintaining your security posture, we have compiled this month’s summary of essential security updates and vulnerability patches pertinent to the WordPress ecosystem.

Continue reading Vulnerability & Patch Roundup — October 2026 at Sucuri Blog.