Shadow AI Detection: The 2026 Enterprise Playbook

TL;DR

• Shadow AI is in every enterprise. Across the engagements we've run, between 40% and 70% of AI tool usage is unsanctioned, unmonitored, or both. The variance correlates with how mature the security organization's discovery process is, not how strict its policy is.
• The detection problem is a five-layer problem (network, browser, endpoint, code, SaaS). Single-layer solutions miss between half and two-thirds of the actual exposure. Most failed audits fail because the team only ran one layer.
• The most overlooked surface is embedded LLM API calls in production code — invisible to network-based shadow AI tools because the calls use sanctioned credentials and legitimate egress. Static analysis of the codebase finds it; nothing else does.
• Outright bans push usage underground without reducing it. Sanctioned alternatives plus enforcement at the DNS/network layer is the durable posture. Discovery → classification → runtime control is the playbook.
• This post is the field-tested version of that playbook. If you'd rather have a partner walk through your environment, book a Repello demo — we'll surface every AI tool, agent, and MCP server in your fleet within a working day.

The data point that gets enterprise security leaders to engage on shadow AI in 2026 is no longer "employees use ChatGPT." That's table stakes. It's the median enterprise has between 40 and 70 percent of its AI usage outside the sanctioned envelope — and almost none of them know what's in that 40-70%.

This isn't a discipline problem. The current generation of AI tools is genuinely useful, the procurement cycle for any of them takes 6-9 months, and the gap between what employees can buy on a personal credit card and what their employer has signed off on has never been wider. Trying to close that gap with policy alone has never worked for shadow IT, and it works less for shadow AI because the tools are more individually valuable.

The post you're reading is the field-tested detection playbook. It covers what to scan, in what order, with what tooling, and how to convert raw detection into actionable governance. We'll use vendor names where it's clarifying, including ours — but the methodology is portable. If you have a different stack and want a tooling-agnostic walkthrough, book a demo.

What "shadow AI" actually means in 2026#

The term gets thrown around loosely. Three concrete categories that need to be detected differently:

Category 1: Personal-account SaaS AI tool usage#

Employees logging into ChatGPT, Claude, Gemini, Perplexity, Copilot, and ten others using their personal email or a non-corporate identity. The data risk is well-understood — pasted code, customer information, internal strategy docs leaving the network through a browser tab.

This category is what most "shadow AI" vendor pitches are about. It's also the least concerning layer because the failure mode is well-bounded (data exfil through chat) and existing browser-DLP and CASB tools detect it competently.

Category 2: Embedded LLM API calls in production code#

Engineering teams shipping features that call OpenAI, Anthropic, Cohere, Mistral, or self-hosted endpoints from inside application code, without security or architecture review. These calls:

• Use legitimate API keys, often pulled from secret managers
• Egress through normal corporate network paths
• Show up as "API calls to api.openai.com" — which CASB tools either ignore or flag indistinguishably from sanctioned uses
• Often include user data, customer data, or internal documents in the prompts
• Have no logging, no retention policy, no compliance review

In our audits, 30-50% of enterprise codebases have at least one undocumented LLM API call path. The vendor in requirements.txt or package.json is a tell, but the prompts being constructed and the data being included are invisible without static analysis.

This category is the most overlooked and the most consequential.

Category 3: Workstation agents and developer tools#

The 2026 explosion: Hermes Agent (110K stars in 10 weeks), OpenClaw (345K stars), Claude Code, Claude Cowork, Claude Octopus, and the long tail of open-source agent runtimes. Each of these:

• Runs as a userspace binary with broad endpoint access
• Connects to external LLM providers and internal MCP servers
• Maintains persistent memory or experience replay buffers
• Installs skills or plugins from community marketplaces with variable provenance

This is the category where the threat model has shifted hardest. We covered the workstation-agent landscape in the Claude Code security checklist and the OpenClaw-specific dynamics in our OpenClaw deployment guide. The takeaway: standard EDR doesn't see the relevant attack surface.

Category 4: MCP servers spun up without governance#

Probably the most fragmented surface. Engineering teams expose internal databases, filesystems, ticketing systems, observability tools, and APIs to agents via MCP servers. The trust boundary between agent and MCP server is under-specified, and an attacker who controls (or compromises) any one MCP server can influence every agent that connects to it.

In a typical mid-size enterprise we've audited, the security team is aware of 2-3 MCP servers; the actual count is usually 15-40. Our MCP security checklist covers what to verify on each one.

Category 5: AI features in sanctioned SaaS#

The least newsworthy category and one that catches a surprising number of compliance reviews off-guard. Salesforce Einstein, Microsoft 365 Copilot, Notion AI, ClickUp AI, Slack AI — these are AI features inside SaaS tools the organization already uses. Each gets enabled at an admin level, processes corporate data, and operates under data-handling terms most security teams haven't reviewed against the AI use case.

This category isn't "shadow" in the strictest sense — the SaaS is sanctioned — but the AI behavior inside it is rarely audited.

The five-layer detection playbook#

A complete shadow AI audit covers five detection layers. Skip any of them and you miss a category.

Layer 1 — Network telemetry#

Watch traffic to known AI provider endpoints. The set worth monitoring as of mid-2026:

NetFlow logs, DNS query logs, and CASB telemetry all surface this. The output: a list of endpoints, source IPs/users, traffic volume, time of day. Cluster on user identity to find power users.

What this layer misses: traffic that uses sanctioned credentials and looks indistinguishable from approved usage; tools that proxy through enterprise infrastructure; and (increasingly) agents that run locally without internet egress.

Layer 2 — Browser-extension and SaaS-session monitoring#

Browser-DLP tools (Obsidian, Strac, Harmonic, Cyberhaven, native Edge/Chrome enterprise policies) capture what's pasted into AI tool sessions. Specifically:

• Domain visit logs for AI tool URLs
• Session capture for high-risk paste events
• File-upload monitoring for documents dragged into ChatGPT, Claude, or similar interfaces
• Authentication telemetry showing which identities (corporate vs. personal) are signing into which tools

This layer catches Category 1 cleanly. It also catches some Category 5 — AI features inside SaaS — because session monitoring sees the AI-feature DOM elements activate.

What this layer misses: anything that doesn't go through a managed browser. Workstation agents and CLI tools bypass it entirely.

Layer 3 — Endpoint discovery#

Find the binaries, configs, and runtime state of AI tools installed on endpoints. The set as of May 2026:

• Workstation agents: claude-code, hermes-agent, openclaw, claude-octopus, custom forks
• Local LLM runtimes: ollama, lm-studio, vllm, text-generation-webui
• Developer CLIs: openai, anthropic, cohere Python/Node packages installed at the user level
• MCP server binaries: any process binding to a port that responds to MCP protocol probes
• IDE plugins: GitHub Copilot, Cursor extensions, Continue, Tabby — installed as user-level VS Code/JetBrains plugins

Standard endpoint inventory tools find some of this but rarely classify it as AI-relevant. The audit needs to be explicit. In our discovery engagements, we ship a single shell script per platform that produces an inventory CSV; you can build the same in-house.

What this layer misses: anything running on personal endpoints connected to corporate systems via VPN, MCP, or shared drives.

Layer 4 — Code-repository scanning#

This is the layer most enterprises don't run, and it's where the most consequential exposures live. Static analysis of every git repository under corporate control for:

• Imports of LLM provider SDKs (openai, @anthropic-ai/sdk, cohere-ai, etc.)
• Direct HTTP/REST calls to provider endpoints
• Embedded prompts, especially prompts that interpolate user data
• LangChain, LlamaIndex, Haystack, and similar framework usage
• Vector database client usage (Pinecone, Weaviate, Qdrant, pgvector) — every vector DB call implies an embedding model is running somewhere
• Hardcoded API keys (rare but findable; signal that the team didn't even bother with secret management)

The output is a per-repository AI-feature inventory. Each entry needs ownership (which team), purpose (what feature), data sensitivity (what's in the prompts), and review status. Most of those fields are blank on day one.

This layer is where Repello's AI asset inventory tooling earns its keep — manually scanning hundreds of repos doesn't scale.

Layer 5 — SaaS posture management#

For each sanctioned SaaS tool in your environment, audit the AI features:

• Is it enabled, and at what tenant scope?
• What data does it process?
• What are the data-handling terms for AI training, retention, and provider routing?
• Are there enterprise-tier controls (no-train opt-outs, data residency, audit logs) and are they enabled?
• Who has admin access to enable/disable?

This is operationally the lightest layer (the tooling exists, the inventory is bounded by your SaaS list) and produces the highest-leverage policy outputs. It's also where compliance reviews bottleneck if not run proactively.

From detection to governance: the next 30 days after the audit#

A shadow AI audit produces an inventory. The inventory is not the goal; governance is. The 30-day path from "we found everything" to "we have a posture":

Week 1 — Classify by risk#

Each discovered tool/usage gets tagged on three axes: data sensitivity (does it process customer data, source code, financial info, PHI?), capability scope (read-only chat vs. agentic action?), and prevalence (one team using it vs. half the engineering org?). The output is a heat map.

Week 2 — Decide sanction status per item#

For each item: sanction (move to managed equivalent), permit (with logging and policy), or block. The default for unsanctioned items where a managed equivalent exists is migrate to managed, not block. Bans without alternatives push usage underground.

Week 3 — Enforce at the network and DNS layer#

For items marked block: DNS-level blocks for the relevant hostnames, network egress blocks for API endpoints, browser policy blocks for SaaS URLs. For items marked permit-with-policy: add to the allowlist and instrument logging.

Week 4 — Wire the runtime layer#

For items marked sanction or permit: ensure that Repello-style runtime monitoring (or your equivalent) captures prompt-layer activity, retrieved-memory provenance for agents, and tool-call audit trails. This is the layer that catches indirect-prompt-injection attacks, data exfiltration through prompts, and policy violations that look fine at the network layer.

This is what a Repello shadow-AI audit engagement ships. We've packaged the detection toolkit, the classification rubric, and the runtime instrumentation, so the 30 days collapse into a working week with a focused team.

If you'd rather see it on your environment than read it in a post, book a demo — bring the spreadsheet of "AI tools we know about" and we'll show you what's missing inside ten minutes.

Anti-patterns we see in enterprise shadow AI programs#

The recurring failure modes from the 100+ engagements we've run:

Anti-pattern 1: Discovery without classification#

The team runs Layer 1-3, generates a 400-line spreadsheet, and stops. Without classification, the inventory is overwhelming, nobody reads it, and the audit becomes a one-time event. Classification has to ship in the same engagement.

Anti-pattern 2: Classification without enforcement#

The team classifies, decides on sanction status, and writes a policy memo. The policy isn't enforced at any technical layer. Six months later, the classification is stale, the tools have churned, and the policy is documentation theater.

Anti-pattern 3: Banning without alternatives#

The team bans ChatGPT. Engineers move to ChatGPT on personal devices. Discovery effectively goes to zero. The risk is unchanged; the visibility is worse.

Anti-pattern 4: Code-repo scanning skipped#

The team runs Layers 1, 2, 3, and 5 — the easy ones — and skips Layer 4. The biggest exposure (Category 2: embedded LLM APIs in production code) goes undetected. The audit's headline number is misleadingly low.

Anti-pattern 5: One-time audit, no continuous coverage#

AI tools and agents proliferate faster than any enterprise procurement cycle. A snapshot audit goes stale in 90 days. The right cadence is continuous: discovery as a daily background job, classification as a weekly review, enforcement as a continuous policy at the network and runtime layers.

The shift from one-time audit to continuous program is what separates "we did a shadow AI exercise last year" from an actual AI security posture management capability.

How to choose the right tooling#

The vendor landscape as of mid-2026:

• Browser-and-SaaS DLP for AI: Harmonic, Cyberhaven, Strac, Obsidian, Microsoft Purview. Strong on Layer 1-2, variable on Layer 3, light on Layer 4.
• Endpoint and runtime agent security: Repello (us), CrowdStrike Falcon Data Protection, Clawkeeper. Strong on Layer 3 and runtime; you bring SaaS-DLP separately.
• Code-repo and CI/CD scanning: Repello AI asset inventory, Snyk AI, GitGuardian (extending into AI). Strong on Layer 4.
• SaaS posture management: Reco, Obsidian, Microsoft Purview. Strong on Layer 5.

No single vendor covers all five layers equivalently. The procurement decision is which two or three to combine. Repello's positioning is the runtime-and-asset side — Layer 3, Layer 4, plus the runtime control plane that converts the inventory into enforcement.

If your stack is undecided, book a demo — we'll map the layers against your existing tools and give you an honest read on where the gaps are, including where competitors fit better than we do.

What "good" looks like at 6 months#

If a shadow AI program is working, six months in you have:

1. A continuously-updated inventory of every AI tool, agent, and MCP server in your environment, refreshed weekly with delta alerts
2. A classification rubric applied to every entry, with ownership, data class, and capability scope tagged
3. Enforcement at three layers: DNS/network for blocks, runtime for permitted-with-policy items, code-repo gating for new LLM API integrations going to production
4. A regular cadence of red-team exercises that exercise the controls — sanctioned tools tested for prompt-layer exfil, MCP servers tested for trust boundary violations, agents tested against the most recent disclosed CVE classes (cf. our Hermes Agent CVE analysis)
5. Executive readouts every quarter that compare exposure versus 90 days prior — not raw inventory, but trend on classified-risk pages

The hardest part is items 4 and 5. They require sustained organizational commitment. The first three are technical and can be stood up in a quarter. We can help with all of them — book a demo and we'll walk through what the program looks like at your scale.

This playbook is the working version, distilled from Repello's enterprise audits in 2026. Tooling references are as of May 2026 and the AI tool landscape moves fast — we update this post quarterly. If you spot a missing category or a stale recommendation, ping us.