Shadow AI Discovery: What It Is and How It Works

What Is Shadow AI Discovery?

Shadow AI discovery is the practice of continuously identifying AI tools, models, agents, and integrations running across an organization outside formal approval or security review. For the full definition of shadow AI itself, see our shadow AI guide. This piece focuses specifically on how discovery actually works in practice.

Why Self-Reporting and Approved Inventories Aren't Enough

Most AI governance programs still rely on self-reporting, employee questionnaires, or an approved-tools inventory as their primary visibility mechanism, and that reliance is itself the gap shadow AI exploits. A questionnaire only surfaces what someone chooses to disclose, and an approved inventory only tracks what went through a formal process in the first place, neither of which accounts for the employee who signed up for a consumer AI tool with a personal email, the developer who installed an MCP server from GitHub over the weekend, or the business unit that quietly built a copilot using a no-code platform. Recent research from Optro found 53% of organizations report only partial visibility into employee AI use and another 21% report limited visibility, meaning nearly three-quarters of organizations are operating with a materially incomplete picture, while just 20% say shadow AI use is rare or nonexistent within their environment. Discovery exists precisely because asking people what they're using doesn't produce an accurate answer, and it never will, regardless of how well-intentioned the survey or how detailed the approved-vendor list becomes.

This isn't a failure of employee honesty so much as a mismatch between how governance programs were designed and how AI adoption actually happens. A questionnaire assumes an employee knows what counts as "AI" in the first place, remembers every tool they've tried, and has the time and incentive to report accurately, three assumptions that rarely hold in practice. An approved inventory assumes every new tool routes through a formal request process before use, when in reality most AI tools today require nothing more than an email address and a few minutes to start using. Discovery methods built on automated, technical detection sidestep both assumptions entirely, working from what's actually happening on the network and the endpoint rather than what someone remembers to report.

What Shadow AI Discovery Needs to Find

Unsanctioned Consumer AI Tools

Employees signing up for ChatGPT, Claude, Gemini, or similar tools using personal accounts, often to paste in company data for entirely reasonable productivity reasons, represent the most common and most visible category. It's also the category most existing security tooling was at least partially built to catch, through web filtering and CASB alerts, even if most organizations still aren't catching it consistently.

AI Plug-ins and Browser Extensions

Browser extensions that add AI capabilities to existing workflows, summarizing emails, drafting responses, analyzing spreadsheets, install with a single click and frequently request broad permissions to read page content, which in a browser tab containing sensitive internal systems means broad access to whatever that page displays. These tools rarely appear on any approved software list because they don't feel like installing new software at all.

Shadow AI Agents and Copilots Built by Business Teams

Business units increasingly build their own AI agents and copilots using no-code and low-code platforms, entirely outside engineering or security review. These often carry real data access: a sales team's copilot connected to a CRM, an operations team's agent connected to internal databases, without the access controls or logging a centrally reviewed system would have received.

Shadow MCP Servers on Developer Machines

This is the category most existing shadow AI tooling misses entirely, and it's becoming the largest source of unmanaged risk. Research from Clutch Security, analyzing over 15,000 MCP server deployments across enterprises, found 86% run locally on developer machines rather than in any managed, remote environment, executing with developer-level privileges and direct access to local credentials, files, and API keys. A separate Clutch finding put this in organizational terms: within a typical 10,000-employee organization, 15% of employees run an average of two MCP servers each, and 38% of those servers come from unofficial implementations by unknown authors, distributed through package managers like npm and PyPI that provide no meaningful verification of who actually built them. OWASP's own MCP Top 10 formally classifies this as MCP09:2025, Shadow MCP Servers, describing exactly the failure mode: teams deploy servers without central registration, network monitoring shows unauthorized services running on unusual ports, and there's no automated discovery scan catching any of it.

A local MCP server sits entirely outside traditional security controls, and that invisibility is the whole problem. EDR sees a normal Node.js or Python process. Network monitoring sees ordinary HTTPS traffic to what looks like a legitimate API. Database logs show queries originating from a developer's own machine, indistinguishable from the developer's own routine activity. Nothing in a standard security stack flags any single piece of this as unusual, because individually, none of it is, which is exactly what makes the aggregate risk so easy to miss until it's already been exploited.

Embedded AI in Third-Party/SaaS Software

Many SaaS platforms have quietly added AI features to existing products, sometimes enabled by default, that process customer or company data through a model the organization never separately evaluated or approved. This category is easy to miss because the software itself was already sanctioned; the AI feature riding along inside it wasn't.

How Shadow AI Discovery Works: Detection Methods

Network Traffic and DNS/Proxy Monitoring

Monitoring outbound connections to known AI service domains through DNS and proxy logs catches usage of hosted AI tools and APIs, including many consumer tools and third-party integrations that route through recognizable endpoints, though this method alone misses locally executing tools that don't generate obviously distinguishable network signatures.

Endpoint and Browser-Level Telemetry

Endpoint monitoring catches what network-level detection misses: locally installed applications, browser extensions, and desktop AI tools that may communicate over generic HTTPS traffic indistinguishable from legitimate business use at the network layer alone. This is also the layer where locally running MCP servers become visible, through process monitoring and configuration file scanning rather than network signatures.

API and Application Usage Analytics

Reviewing OAuth grants and API access logs surfaces which third-party AI applications employees have authorized to connect to corporate systems, often the clearest signal of shadow AI usage that's already reached beyond an individual's own device into shared company data.

File Behavior Analysis

Tracking data uploads to external destinations, particularly to domains associated with AI tools, and monitoring for unusual download or export patterns from internal systems catches the specific moment sensitive data actually leaves a controlled environment, which is often the point that matters most regardless of which tool facilitated it.

From Discovery to Action

Connecting Discovered Tools to Sensitive Data and Identities

A list of discovered tools is only the starting point. Real value comes from connecting each discovered tool to what sensitive data it can access, which identities are using it, and which business context it operates in, turning a flat inventory into an actual risk picture rather than just a longer list of names.

Risk Scoring and Prioritization

Not every discovered AI tool warrants the same response. Separating low-risk experimentation, an individual using a public AI tool for non-sensitive drafting, from high-risk usage, a tool with access to regulated customer data or broad system permissions, is what makes a discovery program actionable rather than overwhelming. Treating every finding with equal urgency guarantees the genuinely dangerous ones get lost in the noise.

Assigning Ownership and Accountability

Every discovered tool needs a named owner, whether that's the individual who introduced it, the business unit that depends on it, or a security team member responsible for the remediation decision. Discovery without assigned ownership tends to produce a growing list nobody actually acts on.

Remediation: Policy Enforcement, Access Reduction, Education

Remediation isn't binary. Options range from reducing a tool's data access without removing it entirely, to enforcing policy through technical controls, to simply educating the team that introduced it about a safer, already-approved alternative. The right response depends on the risk level established during scoring, not a single default action applied uniformly.

Why Blocking Alone Doesn't Work

The Scale Problem

New AI tools launch constantly, and a blocklist built today is measurably incomplete by the time it's deployed. Trying to block shadow AI purely through a growing denylist is a losing race against the pace of tool proliferation, since the list can never keep up with what gets released next, and every new consumer app, browser extension, or MCP server represents another entry the list didn't yet include when an employee first tried it.

Driving Usage Underground vs. Governed Enablement

Blocking access to AI tools without offering a sanctioned alternative doesn't eliminate the underlying need employees are trying to meet; it pushes that usage further underground, onto personal devices and personal accounts where an organization has even less visibility than before. An employee blocked from using an AI tool on a managed laptop will often simply switch to a personal phone, taking the same data risk further out of reach of any monitoring at all. Governed enablement, providing approved tools that meet the same need through a channel with actual oversight, addresses the demand directly instead of just suppressing the visible symptom, and it tends to produce better security outcomes precisely because it keeps usage inside a system that can actually see it.

Shadow AI Discovery for Agentic AI and MCP Environments

The discovery challenge compounds significantly once agents and MCP servers enter the picture, since an agent's tool access and an MCP server's trust boundary both introduce risk that a simple inventory of "which AI tools are installed" doesn't capture. See our agentic AI security guide and MCP security guide for how discovery needs to extend into these environments specifically.

Building Continuous Shadow AI Discovery

One-Time Scan vs. Continuous Monitoring

A discovery scan run once produces a snapshot that starts going stale the moment it's completed, since new tools, extensions, and MCP servers get introduced continuously across a large organization. Continuous, automated discovery is the only approach that keeps pace with how quickly the shadow AI footprint actually changes.

Integrating Discovery into Governance Programs

Discovery findings need to feed directly into an organization's broader governance program rather than existing as an isolated security exercise. See our AI governance framework guide for how discovered assets connect to ownership, policy, and compliance reporting more broadly.

How Akto Approaches Shadow AI Discovery

Discovery Across Employee Endpoints, Cloud, and Agents

Akto continuously discovers AI usage across employee endpoints, cloud infrastructure, and agent deployments, covering the full range of categories in this guide rather than a single detection method applied in isolation.

Identifying Shadow Agents and Shadow MCP Servers

Akto pays particular attention to the category most existing tooling misses: locally running MCP servers and shadow agents built outside formal review, surfacing exactly the invisible attack vectors that OWASP's MCP09:2025 classification and Clutch's own research both point to as the fastest-growing blind spot in enterprise AI environments.

Turning Discovery into Guardrails and Governance

Discovered tools and servers feed directly into Akto's risk assessment and runtime guardrails, closing the loop between finding shadow AI and actually managing it, rather than producing a static inventory that goes stale the moment it's compiled.

Final Thoughts on Shadow AI Discovery

Shadow AI discovery exists because the alternative, asking people what they're using and trusting an approved-tools list to reflect reality, has already been shown not to work. The categories that matter most today go well beyond consumer chatbots: shadow agents built by business teams and, increasingly, shadow MCP servers running with developer privileges on machines no security tool is watching. Organizations that treat discovery as continuous infrastructure, feeding directly into risk scoring, ownership, and governed remediation, are the ones actually closing the gap rather than managing it after the fact.

FAQs on Shadow AI Discovery

What is shadow AI discovery?

Shadow AI discovery is the practice of continuously identifying AI tools, models, agents, and integrations running across an organization outside formal approval or security review, using automated detection methods rather than relying on employees to self-report their own usage.

Why isn't self-reporting enough to find shadow AI in an organization?

Self-reporting only surfaces what someone chooses to disclose, and an approved-tools inventory only tracks what went through formal review in the first place. Research shows the majority of organizations have only partial or limited visibility into actual employee AI use, confirming that asking people what they use doesn't produce an accurate picture.

What kinds of shadow AI does discovery need to detect?

Unsanctioned consumer AI tools, browser extensions and plug-ins, shadow agents and copilots built by business teams, shadow MCP servers on developer machines, and AI features embedded inside already-approved third-party SaaS software.

What is a shadow MCP server, and why is it a risk?

A shadow MCP server is an MCP server deployed without central registration or security review, most often running locally on a developer's machine with developer-level privileges and access to local credentials and files. Research found 86% of MCP server deployments run locally rather than in managed environments, and over a third of those come from unofficial implementations by unknown authors, making this one of the fastest-growing and least visible categories of shadow AI risk.

How does network traffic monitoring detect shadow AI?

By analyzing DNS and proxy logs for connections to known AI service domains, network monitoring catches usage of hosted AI tools and APIs, though it typically misses locally executing tools like MCP servers that don't generate distinguishable network signatures.

Can browser extensions reveal shadow AI usage?

Yes. Endpoint and browser-level telemetry catches AI-powered extensions and desktop tools that network monitoring alone misses, since many of these communicate over generic HTTPS traffic that looks identical to legitimate business use at the network layer.

How do you prioritize which discovered AI tools are highest risk?

By connecting each discovered tool to the sensitive data it can access, the identities using it, and its business context, then separating low-risk individual experimentation from high-risk usage involving regulated data or broad system permissions, so remediation effort goes where it actually matters.

Does blocking AI tools reduce shadow AI, or push it underground?

Blocking without offering a sanctioned alternative tends to push usage further underground, onto personal devices and accounts with even less organizational visibility than before. Governed enablement, providing an approved tool that meets the same underlying need, addresses the demand rather than just suppressing its visible symptom.

How do you connect discovered shadow AI tools to sensitive data exposure?

By mapping each discovered tool's access permissions, the identities using it, and its data flows against an organization's sensitive data inventory, turning a flat list of tools into an actual risk picture rather than just a longer inventory.

Who should own remediation after shadow AI is discovered?

Every discovered tool needs an assigned owner, whether the individual who introduced it, the business unit relying on it, or a security team member responsible for the remediation decision. Without assigned ownership, discovery tends to produce a growing list nobody actually acts on.

Is shadow AI discovery a one-time scan or an ongoing process?

It needs to be continuous. A one-time scan produces a snapshot that starts going stale immediately, since new tools, extensions, and MCP servers get introduced constantly across any organization of meaningful size.

How does shadow AI discovery apply to AI agents and MCP servers specifically?

Discovery needs to extend beyond simple tool inventory to cover agent tool access and MCP server trust boundaries specifically, since these introduce risk that a basic "is this AI tool installed" check doesn't capture on its own.

What's the difference between shadow AI discovery and shadow AI governance?

Discovery is the process of finding what AI is actually running. Governance is the broader program that turns those findings into policy, ownership, remediation workflows, and compliance reporting. Discovery feeds governance; it doesn't replace it.

How quickly can an organization get visibility into its shadow AI usage?

Initial visibility into major categories like consumer AI tools and browser extensions can often be established quickly through existing network and endpoint telemetry, but comprehensive coverage, particularly of shadow MCP servers and locally built agents, requires purpose-built, continuous discovery rather than a one-time audit.

How does Akto help discover shadow AI, including shadow agents and MCP servers?

Akto continuously discovers AI usage across employee endpoints, cloud infrastructure, and agent deployments, with particular focus on locally running MCP servers and shadow agents that most existing tooling misses, feeding findings directly into risk assessment and runtime guardrails rather than producing a static, one-time inventory.