Key takeaways
- Shadow AI detection means checking six surfaces: network, browser, endpoint, identity, SaaS, and code.
- IBM’s 2025 report tied shadow AI to 20% of breaches, and heavy shadow AI use added $670,000 to breach cost.
- Most programs check only network traffic, missing local models, OAuth-only tools, and AI inside approved SaaS.
- Identity is the highest-severity surface: OAuth grants and service accounts create AI access with nothing installed.
- DNS and proxy logs give the fastest first pass, using data you already collect.
Ask a security team how much AI is running inside their company and you’ll usually get a number. Ask how they arrived at it and you’ll usually get a proxy log query against four or five well-known domains. That query is not wrong. It’s just looking at one of six places.
The gap matters more than it used to. IBM’s 2025 Cost of a Data Breach report tied shadow AI to 20% of the breaches it studied, and found that a high level of shadow AI added $670,000 to the average breach cost. IBM’s own summary is blunt about the gap: “a staggering 97% of breached organizations that experienced an AI-related security incident say they lacked proper AI access controls.”
So detection is not a scanning problem. It’s a coverage problem.
Quick answer: how to detect shadow AI
Detecting shadow AI means checking six surfaces, because no single tool sees all of them:
- Network traffic and DNS for calls to AI provider endpoints
- Browsers for web chatbots and AI extensions
- Endpoints for locally run models and AI coding tools
- Identity systems for OAuth grants and non-human identities
- SaaS platforms for AI features switched on inside approved apps
- Code and artifacts for hardcoded keys and downloaded models
What counts as shadow AI, and how it differs from shadow IT
Shadow AI is any AI tool, model, API, agent, or embedded feature being used inside your organization without going through security, IT, or procurement review. That includes a marketer pasting customer data into a chatbot, a developer running a model on a laptop, and an automation with an API key that nobody owns.
The comparison to shadow IT gets made often, and it understates the problem. An unapproved file-sharing app stores your data somewhere you didn’t sanction. An unapproved AI tool reads that data, transmits it to infrastructure you don’t control, and may retain it in ways you can’t audit or reverse.
Scale is the other difference. Microsoft and LinkedIn’s 2024 Work Trend Index found that 78% of people using AI at work were bringing their own tools to do it. That is not a fringe behavior you can police case by case. It’s the default.
Why is shadow AI so hard to detect?
Four properties make it slippery, and each one defeats a different control you probably already own.
It looks like normal web traffic. A request to a major AI provider is TLS-encrypted HTTPS to a reputable, high-reputation domain. Without inspection, it’s indistinguishable from any other SaaS call. Your firewall has no reason to care.
It often installs nothing. A user grants an AI tool OAuth access to their mailbox or drive, and the tool now reads corporate data from the provider’s servers. No agent, no binary, no endpoint event. Your EDR sees nothing because nothing happened on the endpoint.
It arrives inside software you already approved. Vendors ship AI features into existing products and enable them by default. The app passed review two years ago. The AI feature did not.
It authenticates as a machine. When an AI agent acts on your systems, it uses a service account or a token. Its activity shows up as routine API traffic rather than an interactive user session, so controls built around human access never fire.
That last one is where the risk is heading. The chatbot-copy-paste problem is real and mostly understood. Agents with standing credentials and no defined lifecycle are newer, and far fewer teams are looking for them.
Where shadow AI hides: the six detection surfaces
Each surface has its own signal and its own tooling. Work all six and you discover a real inventory. Work one and you get a number that feels reassuring and isn’t.
The table below is the short version: what to look for on each surface, and what will identify it.
| Surface | What hides there | Primary detection signal | Tool category |
|---|---|---|---|
| Network | Direct API calls, web AI apps | DNS and proxy logs to AI provider domains | Secure web gateway, DNS filtering |
| Browser | Web chatbots, AI extensions | Extension inventory, paste and upload events | Browser security, DLP |
| Endpoint | Local models, CLI tools, IDE assistants | Process, package, and model-file inventory | EDR, device management |
| Identity | OAuth grants, service accounts, agents | New third-party app authorizations | Identity provider log review |
| SaaS | AI features inside approved apps | Admin-console feature flags, connector lists | CASB, SSPM |
| Code and artifacts | Hardcoded keys, downloaded models | Secret scans, model file signatures | SAST, artifact scanning |
Surface 1: Network traffic and DNS resolution
Start here, because it needs no new tooling and produces results in an afternoon.
Query your DNS and proxy logs for resolutions to AI provider endpoints. api.openai.com, api.anthropic.com, and generativelanguage.googleapis.com cover the obvious ones, but the interesting hits come from the long tail: inference aggregators, smaller hosted providers, and consumer AI apps nobody put on a list.
Two patterns are worth flagging beyond the domain match itself. Bursty outbound traffic to an inference endpoint on a regular schedule usually means an automation, not a person. And large POST bodies to an AI domain from a single host suggest bulk data going somewhere it shouldn’t.
What network telemetry won’t catch: anything running locally, anything reached through a personal device, and anything already inside an approved SaaS tool.
Surface 2: Browsers and extensions
Most shadow AI use is a browser tab. It requires no install, leaves no artifact on disk, and touches no network control that distinguishes it from ordinary web browsing. AI agents running in the browser push this further, since they act on pages the user is already authenticated to.
Pull your browser extension inventory through device management and sort by permission scope rather than by name. An extension requesting read access to all site data can read whatever the user reads, including your internal apps, and ship it to a model. That’s a bigger exposure than the chatbot the user visits on purpose.
If you run a secure web gateway with TLS inspection, upload and paste telemetry to AI domains is the highest-value signal available on this surface. It tells you not just who is using AI, but what data left with them.
Surface 3: Endpoints and developer workstations
Developer machines are their own category: the tooling is local, fast-moving, and frequently invisible to network controls.
Look for model files by extension across user directories: .pkl, .pt, .safetensors, .onnx, .gguf. Look for local inference runtimes in your process and package inventories. Look at IDE extension lists, where AI coding assistants live, and at shell histories and dotfiles, where agent configurations increasingly live, including unregistered MCP servers.
A locally run model never touches an external API, so no amount of network monitoring will surface it. That’s the whole point of checking here.
Surface 4: Identity, OAuth, and non-human identities
This surface produces the least noise and the highest-severity findings.
Pull the third-party application grants from your identity provider and review what was authorized, by whom, and with what scopes. An AI note-taker with calendar and mail access is a data pipeline out of your organization, established by one user in one click, with no ticket and no review.
Then look at the non-human side. New service accounts created outside normal provisioning, tokens without a named owner, automation identities calling directory or security APIs, and permission sets that grew by inheritance rather than by request. When an AI agent is embedded into a workflow, it usually reuses an existing service account precisely because that’s the fast path. The agent then holds every permission that account accumulated.
The question to ask about any of these identities is not what model sits behind it. It’s what the credential can read and what it can change. That’s an access control question rather than a model question.
Surface 5: SaaS platforms and embedded AI features
Your approved apps are shipping AI you didn’t evaluate, and it accounts for a large share of the AI sprawl inside a typical company.
Work through the admin console of each major platform and inventory the AI features available, which are enabled, and what data they process. Check the connector and integration lists in the same pass, since that’s where cross-app AI access gets established. A CASB or SSPM automates this at scale, but for a first inventory the admin consoles of your top ten SaaS applications will tell you most of what you need.
Governance is harder than detection here. The vendor is contracted, the data processing agreement exists, and the feature is on, so whether that clears your bar is a policy call rather than a security finding.
Surface 6: Code, artifacts, and the model supply chain
Everything above finds AI that people use. This surface finds AI that your software depends on, which makes it a supply chain problem as much as a governance one. It’s also the one most detection programs skip entirely.
Scan source repositories for hardcoded credentials and for calls to model provider SDKs and endpoints. Scan binary repositories and container images for model files, model-serving dependencies, and datasets. Both matter: code scanning alone misses the poisoned model sitting in a container image, and artifact scanning alone misses the API key leaking data from a script.
A model pulled from a public hub can carry a malicious payload, and the mechanism is well documented. Hugging Face’s own security documentation warns of “dangerous arbitrary code execution attacks” when a pickle file is loaded, and lists the safetensors format among its mitigations. Models also carry licenses, and a model tagged for non-commercial use inside a commercial product is a legal exposure that no amount of network monitoring will find. The OWASP Top 10 for LLM Applications tracks this whole category as supply chain risk.
How to triage what you find
Your first full pass will return more than you can act on, and not every finding is an AI security risk worth chasing. Rank it:
- Malicious or known-vulnerable first. Anything flagged as containing malware or carrying an unresolved critical vulnerability jumps the queue regardless of how rarely it’s used.
- Then by what the identity can reach. An integration with read access to a customer database outranks a summarization tool working on public marketing copy.
- Then by whether it can act, not just read. Read-only access is a confidentiality problem. Write access to production systems is an operational one.
- Then by how widely it’s used. A tool appearing across forty builds has a bigger blast radius than one in a single experiment, and blocking it without warning will break more.
One caveat on all four: this ranks what you found, not what exists. A surface you skipped contributes nothing to the sort, which is why the triage is worth less than the coverage.
Governance status is the fifth sort, and the one people miss. Some assets will come back approved in one project and ungoverned in another. Blocking those breaks the team that did the right thing. Extend the approval to cover the additional usage instead, then decide.
How to eliminate shadow AI once you’ve found it
Detection without a follow-through just produces a spreadsheet that ages badly. Finding the tools is the cheap half; eliminating the ones that shouldn’t be there is where programs stall.
Block what’s genuinely dangerous: known-malicious models, unresolved critical vulnerabilities, licenses your legal team has ruled out. Govern what’s already load-bearing rather than ripping it out, because an immediate block on a tool forty people depend on creates an incident of your own making.
Then close the gap that created the problem. If you block a tool without providing a sanctioned alternative, people find a different unsanctioned tool, and your next scan finds it. A catalog of approved models and services, credentials managed centrally so developers never handle raw API keys, and an intake path that resolves in days rather than weeks will do more to shrink shadow AI than any control on this list. Most AI governance frameworks assume that layer already exists.
Last, make it repeat. A one-time scan describes the day you ran it. Schedule the DNS query, the OAuth grant review, and the artifact scan on a cadence, and route new findings into the same triage. The NIST AI Risk Management Framework states it directly under GOVERN 1.6: “Mechanisms are in place to inventory AI systems.” The EU AI Act assigns obligations by risk classification, and you can’t classify a system you haven’t found. If you’re building the policy layer, our plain-English breakdowns of the NIST framework and the EU AI Act cover what each one actually asks for.
Shadow AI detection FAQ
Why is shadow AI important to address?
Because the exposure is measurable. IBM’s 2025 research tied shadow AI to 20% of studied breaches, and customer personal data was compromised in 65% of those, against a 53% global average. Breaches with a high level of shadow AI cost $670,000 more than average. Of the 600 organizations surveyed, 63% had no AI governance policy at all. The tools are already in use; the controls mostly aren’t.
Why is shadow AI hard to detect?
Because it defeats four controls at once. AI traffic looks like ordinary encrypted HTTPS to reputable domains. OAuth-based tools install nothing on the endpoint. AI features arrive already enabled inside SaaS you approved years ago. And AI agents authenticate as service accounts, so controls designed around human sessions never trigger.
Is using ChatGPT considered shadow AI?
Only if it hasn’t been through review. Shadow AI is defined by governance status, not by the tool. A licensed enterprise deployment with a data processing agreement and configured retention settings is sanctioned AI. The same product accessed through a personal account on a work machine is shadow AI, even though it’s the identical model.
What is the fastest way to detect shadow AI?
Query your DNS or proxy logs for resolutions to AI provider domains over the last 30 days. It uses data you already collect, needs no procurement, and typically runs in under an hour. Treat the output as a floor rather than an inventory, since it will miss local models, OAuth-only tools, and AI embedded in approved SaaS.
Does DSPM prevent shadow AI?
No. Data security posture management tells you where sensitive data lives and who can reach it, which is useful context for scoring what a shadow AI tool could expose. It doesn’t discover the tool. Pair it with identity, network, and endpoint discovery, and use it to prioritize what the other surfaces surface.
How is shadow AI different from shadow IT?
Shadow IT puts your data somewhere you didn’t approve. Shadow AI reads that data, sends it to infrastructure you don’t control, and may keep it in a form you can’t audit or delete. Shadow IT is also comparatively rare per employee, while unsanctioned AI use is closer to the norm among people who use AI at work.
Where to start
Run the DNS query. It costs an afternoon, uses logs you already have, and gives you the one thing every other decision depends on: a real list instead of an estimate.
Then pick the surface you have the least visibility into, which for most teams is identity, and pull the third-party OAuth grants from your identity provider. Those two passes won’t give you a complete inventory. They will tell you how wrong your current number is, and that’s the useful part.