How to Discover Shadow AI in Your Organisation

TL;DR

• Shadow AI is any AI tool, model, agent or embedded AI feature used inside your organisation without approval, review or oversight.
• It spreads across five layers: identity, SaaS, endpoints, code and cloud. No single tool sees all of them.
• Most discovery works from data you already have: DNS and egress logs, OAuth grants, SSO logs, secrets in code, and expense records.
• The fastest-growing blind spot is local agentic AI: unauthenticated MCP servers on developer laptops that can read SSH keys and stream them to a remote model.
• Discovery gives you an inventory. Testing whether those AI systems are actually exploitable is a separate step, and it needs human validation.

Ask most organisations which AI tools are running inside their walls, and the honest answer is "we don't know." That gap is one of the largest unmanaged risks in security today. When teams deploy proper discovery, they consistently find far more AI running than leadership expected. This guide explains what shadow AI is, how to find it across the five layers where it hides, and where a structured AI systems penetration test fits once you know what you have. It also draws a clear line between what a one-time discovery audit can see and what it cannot, because that honesty is the difference between real visibility and a false sense of control.

What Shadow AI Actually Is

Shadow AI is a subset of shadow IT, but it carries a different risk profile. A classic unsanctioned SaaS app stores data. An AI tool processes it, and often retains it, sometimes to train a model you have no contract with. It also hides better, because AI features increasingly arrive switched on inside tools you already approved: your CRM, your productivity suite, your meeting notes. Nobody installed a new app. Someone clicked a button.

The scale is not theoretical. Gartner research found that 69% of organisations suspect or confirm that employees use unauthorised AI tools, and discovery audits routinely surface dozens of AI tools in active use, most without approval, security review or a data processing agreement. Free-tier accounts are common, which means company data flows to services that may use it for training.

The Five Layers Where Shadow AI Hides

Shadow AI no longer means an employee opening a chatbot in a browser tab. It spreads through five parallel channels, each with its own telemetry.

Identity

Employees sign into AI services with corporate credentials through SSO and OAuth. Every grant leaves a record in your identity provider's consent logs. OAuth is now the most common transport: an AI app gets read or write access to Drive, mail or Slack, often permanently, without ever touching your network perimeter.

SaaS

AI features activate by default inside licensed tools. Notion AI, Slack AI, Salesforce Einstein, Zoom AI Companion. These do not look like new tools, so conventional discovery misses them.

Endpoint

Desktop AI apps and browser extensions read what the user reads. Coding assistants send code snippets to external APIs. In 2026, endpoint vendors extended runtime detection to desktop AI apps precisely because they look almost identical to legitimate user behaviour.

Code

API keys for AI providers get embedded directly in repositories and CI/CD pipelines. A key provisioned outside formal review is shadow AI with production reach.

Cloud

Internal applications call model endpoints under the hood. An engineer stands up a LangChain service on a public endpoint that processes internal data, and no one signed off on it.

The New Blind Spot: Local Agentic AI and MCP

The most dangerous 2026 development is agentic AI running locally. Engineers stand up Model Context Protocol servers on their laptops to connect assistants to files, databases and internal tools. Many run with no authentication, on localhost, reachable by any process on the machine. A laptop with several running MCP servers is effectively an undocumented broker that can read SSH keys, .env files and credential stores, and stream that context to a remote model on every prompt. There is no SaaS audit log that records those tool calls, and traditional shadow IT discovery does not see it at all. We covered how attackers abuse this protocol directly in MCP Security.

How to Discover Shadow AI With Data You Already Have

Effective discovery is a governance and visibility exercise, and you can get far without buying anything. Start with DNS and egress traffic analysis, looking for first-seen connections to known model providers and AI domains. Add identity and secrets audits: review OAuth grants in Microsoft 365 and Google Workspace, and scan code repositories for embedded AI API keys. Pull SSO and audit logs and filter them against a maintained catalogue of AI tools. Review expense and card data for AI subscriptions bought outside procurement. Finally, run external attack surface scanning to catch customer-facing applications that shipped an LLM integration without review.

Fuse at least three of these signals. Network logs alone miss most of it, because so much AI usage is browser-based and SaaS-embedded. Then classify each finding by risk. A browser extension that summarises public web pages is not the same threat as an agent with write access to a production database. Separate what a tool can read from what it can change, and prioritise accordingly.

Where Tools Stop and Human Validation Begins

Commercial discovery platforms are real and useful, but honest vendors admit the coverage is incomplete by category, not by product failure. No engine sees a developer running a local model offline, an analyst pasting data into a personal AI account off the network, or a tool signed up for with a private email. A discovery audit gives you a point-in-time inventory. It does not tell you whether the AI systems you found are actually exploitable.

That second question is where testing comes in. Finding an AI integration is discovery. Establishing whether it can be turned against you through prompt injection, tool poisoning or excessive agency is AI systems penetration testing, and every finding there is validated by hand. Discovery tells you what you have. Testing tells you what an attacker can do with it.

Frequently Asked Questions

What is the difference between shadow AI and shadow IT?

Shadow IT is any technology used without IT approval. Shadow AI is the subset involving AI tools, models, agents and embedded AI features. It carries its own risk because AI actively processes and often retains your data, and because AI features increasingly hide inside already approved software, which makes them harder to detect with conventional discovery.

Can I discover shadow AI with tools I already have?

Largely, yes. DNS logs, proxy logs, SSO and OAuth consent logs, code repository scans and expense data cover most of the surface. The key is to combine several signals rather than rely on one, because network telemetry alone misses browser-based and SaaS-embedded AI usage.

Why can't my existing DLP or CASB catch all of it?

Those tools were built before the current wave of AI adoption. They give a partial foundation but were not designed for prompt-level inspection or for discovering AI features embedded inside sanctioned SaaS. They miss OAuth-based integrations and local agentic AI entirely.

Is discovery the same as testing my AI for security flaws?

No. Discovery produces an inventory of what AI is running. Testing establishes whether those systems can be exploited. A structured AI penetration test covers prompt injection, model manipulation, data extraction and the security of any tools the model can invoke, with human validation on every finding.

Should I block every unapproved AI tool once I find it?

Blocking everything tends to push usage further underground. A more effective pattern is to classify by risk, restrict only the high-risk tools that touch sensitive data, and offer approved alternatives for the rest so people have a safe path.

Related services and resources

If you have started mapping where AI runs in your environment and want to know whether those systems hold up under attack, our AI systems penetration test covers prompt injection, model manipulation and the security of connected tools and APIs, with every finding validated by a human tester. For the wider picture of how AI security testing differs from conventional application testing, read our guide on AI systems penetration testing. And if AI is only one part of a broader compliance question, our overview of penetration testing across EU frameworks explains how a well-scoped programme can satisfy several obligations at once.