Seven Shades of Shadow AI: A 2026 Field Guide for Pragmatists

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.

---

Originally published at Medium.

This blog focuses on SIEM, log management, PCI DSS compliance and other information security issues. Check out more articles like this here: http://chuvakin.blogspot.com/

Source: http://chuvakin.blogspot.com/2026/11/seven-shades-of-shadow-ai-2026-field.html