How to Detect Shadow AI: Methods, Tools, and Blind Spots
Shadow AI detection has become harder because Shadow AI itself has changed.
A few years ago, the problem could often be reduced to employees opening an unapproved generative AI website. In 2026, the same organization may also have personal AI accounts, desktop assistants, coding copilots, locally running models, direct model API calls, AI features embedded in approved SaaS products, autonomous agents, and Model Context Protocol (MCP) connections.
These activities do not leave the same security signals.
A network control may tell you that an employee accessed an AI service without showing what data was submitted. A DLP control may identify sensitive information in a prompt but know little about an unapproved model inside a development repository. An AI gateway provides detailed visibility into traffic routed through it, but it cannot automatically account for AI usage that bypasses that gateway.
That makes Shadow AI detection a coverage problem, not a single-tool problem.
A practical detection program needs to answer three questions:
What AI is being used? What company data or systems can it reach? What can the organization monitor or control?
The need for that visibility is no longer hypothetical. IBM’s 2025 Cost of a Data Breach research, based on breaches at 600 organizations, found that one in five organizations reported a breach involving Shadow AI. Among organizations with AI governance policies, only 34% regularly audited for unsanctioned AI. Organizations with high Shadow AI use also experienced breach costs averaging $670,000 more than organizations with low or no Shadow AI use.
The challenge is also expanding beyond public chatbots. Netskope’s 2026 AI Report found that 30% of AI users in its dataset used only personal AI applications, while another 14% used both personal and organization-managed apps. Netskope also reports that discovery priorities are shifting toward AI agents, MCP servers, and local AI infrastructure.
Effective Shadow AI detection therefore starts by defining what needs to be visible.
What Shadow AI Detection Actually Needs to Find
A Shadow AI inventory should cover more than a list of generative AI websites.
| AI surface | What may need to be detected |
| Public AI services | Consumer GenAI applications and personal accounts used for work |
| AI-enabled SaaS | AI features activated inside otherwise approved business applications |
| Browser and desktop AI | Extensions, standalone assistants, desktop clients |
| Developer AI | Coding assistants, model APIs, AI SDKs, libraries and frameworks |
| Local AI | Models and agents running directly on employee or developer devices |
| AI supply chain | Models and AI components pulled into repositories or application code |
| Agentic AI | Autonomous agents, tool connections, MCP clients and servers |
| AI-connected enterprise data | Drives, repositories, mailboxes, databases and other systems accessible to AI |
| AI data flows | Prompts, pasted content, file uploads, responses and other sensitive-data movement |
This distinction is important because an organization can have good visibility into one surface and remain almost blind to another.
Microsoft’s own current guidance illustrates the separation. Its Shadow AI deployment model treats discovery, access restriction, sensitive-data protection, and governance as separate stages rather than one detection capability. Microsoft Defender for Cloud Apps can discover AI applications, while Purview capabilities can identify sensitive information being entered into prompts, pasted into AI sites, or uploaded from endpoints.
NIST’s AI Risk Management Framework reaches a similar conclusion from a governance perspective. GOVERN 1.6 calls for mechanisms to inventory AI systems so organizations can maintain a holistic view of their AI assets rather than depend on partial inventories.
But an inventory becomes useful only when it contains enough context to distinguish ordinary adoption from material exposure.
Shadow AI Detection Requires Three Kinds of Visibility
A useful way to evaluate Shadow AI detection capabilities is to separate usage visibility, data visibility, and access or action visibility.
1. Usage visibility: What AI is present?
This is the basic discovery layer.
Security needs to know that an AI application, model, agent, integration, or API is being used, ideally together with information such as the user, device, workload, department, repository, or business owner associated with it.
Network logs, cloud discovery, endpoints, browser controls, identity systems and development tooling can all contribute to this layer.
But knowing that an application exists tells you very little about what happened inside it.
Two employees may both use the same AI platform. One asks it to rewrite public marketing copy. The other uploads an unreleased contract containing customer information. Application discovery can record both events as usage of the same service even though the risk is completely different.
2. Data visibility: What information is reaching AI?
The next layer asks what company information the AI interaction contains.
Relevant signals may include sensitive prompts, pasted text, uploaded documents, source code, customer records, intellectual property, regulated data, or information returned in AI responses.
Microsoft, for example, separates AI application discovery from controls that detect sensitive information being shared through prompts, paste actions, uploads and network traffic. Proofpoint similarly documents monitoring of sensitive prompts and file uploads across both approved and Shadow AI applications.
That distinction matters because detecting an AI application is not the same as detecting AI data exposure.
3. Access and action visibility: What can the AI reach or do?
Agentic AI adds a third question.
An autonomous agent may not wait for a user to paste information manually. It may have permission to read local files, query repositories, call APIs, execute code, or interact with enterprise systems.
Microsoft’s 2026 Shadow AI preview currently detects OpenClaw on managed Windows devices enrolled in Intune, with additional local agents such as Ollama Desktop planned for upcoming releases. Microsoft also describes unmanaged local and cloud-hosted agents as a new wave of Shadow AI because they may autonomously modify code or access confidential information.
At this layer, simply asking “Which AI tool is being used?” is insufficient. Security also needs to understand permissions, tool calls, connected systems and the data available to the agent.
This is why Shadow AI detection methods need to be combined rather than evaluated in isolation.
Shadow AI Detection Methods: What Each One Sees and Misses
The most useful way to compare detection methods is not by asking which one is “best,” but by asking which signal it observes and where its blind spots begin.
| Detection method | What it can reveal | Typical blind spots | Best suited for |
| Network / DNS / SWG / SSE | Connections to known AI services, traffic patterns, users and destinations | Local AI, some off-network activity, limited business context from DNS alone | Discovering external AI service usage |
| CASB / SaaS discovery | Cloud AI applications, usage trends, sanctioned vs. unsanctioned services | Local models, some desktop and developer activity | Enterprise SaaS visibility |
| Identity / OAuth review | AI applications connected to corporate identities and data, granted scopes and permissions | Personal accounts, local models, unauthenticated tools | Detecting connected AI services and excessive access |
| Browser / endpoint monitoring | Browser usage, desktop AI, IDEs, CLIs, extensions and local processes | Unmanaged devices without coverage | Employee and developer AI usage |
| DLP / data-centric controls | Sensitive prompts, paste actions, uploads and other data movement | May not provide a complete AI asset inventory | Detecting data exposure |
| AppSec / repository scanning | Models, SDKs, AI libraries, agents, MCP components and AI dependencies in software | Employee use of unrelated AI SaaS | Developer and AI supply-chain visibility |
| AI gateway / runtime monitoring | Model requests routed through the gateway, identities, prompts, responses and policy events | Any AI traffic that bypasses the governed route | Controlled AI APIs and internal AI systems |
| Procurement / surveys | Business purpose, paid subscriptions, departmental experiments | Free tools, hidden integrations, incomplete self-reporting | Adding business context to technical discovery |
No one row provides complete coverage.
Network and DNS analysis
Network telemetry is often one of the fastest places to begin because external AI services generally create observable connections.
DNS logs can help identify requests to known AI domains. Secure Web Gateways, SSE platforms and similar controls can add user attribution, application classification and policy enforcement.
That makes them useful for answering questions such as: Which external AI services are employees accessing? How frequently? From which users or departments?
But DNS should not be confused with full Shadow AI detection.
A DNS event identifies a domain resolution, not what data an employee submitted afterward. Network-level approaches can also provide limited visibility into local models, some endpoint-native agents, or activity occurring outside managed traffic paths.
Their strength is destination visibility, not complete AI context.
CASB and SaaS discovery
CASB and related cloud-discovery capabilities help identify applications employees are using and distinguish sanctioned from unsanctioned services.
Microsoft Defender for Cloud Apps, for example, can identify generative AI applications in use, provide usage details and risk assessments, and let administrators mark applications as sanctioned or unsanctioned.
This creates a useful application inventory, particularly for organizations already routing significant SaaS activity through managed enterprise controls.
The blind spot is scope. SaaS discovery alone will not necessarily find a locally running model, an AI package added to a repository, or every agent running inside a developer environment.
Identity and OAuth auditing
Not all Shadow AI is easiest to find from the network.
Some AI applications reveal themselves because employees authorize them to access corporate systems.
Reviewing enterprise applications, OAuth grants, application identities and permission scopes can uncover AI services connected to mailboxes, files, calendars, cloud storage and other enterprise resources.
This is particularly important for AI integrations because the security question may not be whether someone opened an application, but whether that application received persistent access to company data.
The blind spot is equally clear: identity telemetry will not reveal an employee using a personal AI account that never authenticates through corporate identity infrastructure.
Browser and endpoint monitoring
As AI moves from web pages into desktop software, IDEs, CLIs and autonomous agents, endpoint visibility becomes more important.
Endpoint controls can potentially observe processes, applications and AI activity much closer to where the work takes place.
Cyberhaven, for example, documents Shadow AI discovery across endpoints, browsers, CLIs and IDEs, including coding assistants, agent frameworks and MCP servers. Microsoft has also begun adding visibility for unmanaged AI agents and standalone desktop AI applications through its endpoint and administration tooling.
The main limitation is coverage. An endpoint control cannot provide reliable visibility into a device on which it is not deployed or into environments outside its monitoring scope.
For organizations with contractors, BYOD, development workstations or heterogeneous operating systems, that distinction can be material.
DLP and data-centric detection
DLP becomes important when the security team needs to move from “AI was used” to “sensitive information was exposed.”
Depending on the architecture, data-centric controls can inspect prompts, clipboard actions, file uploads and other information moving toward AI services.
This allows security teams to differentiate low-risk usage from interactions involving source code, PII, financial information, intellectual property or other protected data.
Current Microsoft guidance explicitly separates discovery from this protection layer: Endpoint DLP can detect sensitive information pasted or uploaded to AI sites, while other Purview controls can detect sensitive information in prompts and network traffic.
Proofpoint similarly distinguishes Shadow AI application visibility from sensitive prompt, upload and response monitoring. Nightfall AI takes a related, AI-native approach — it combines data detection and classification with visibility into AI agent and MCP data flows, aiming to distinguish legitimate business activity from exfiltration without a separate proxy or network change.
The limitation is that DLP answers a data question. It should not automatically be treated as a complete inventory of every AI asset, model, integration or agent in the organization.
Repository and software supply-chain detection
Developer Shadow AI creates a different discovery problem.
Models, AI SDKs, libraries, frameworks, agents and MCP components can enter an organization through source code and software supply-chain workflows rather than employee web browsing.
JFrog’s Shadow AI Detection documentation, for example, describes scanning indexed repositories with JFrog Xray to identify AI model packages and map them to projects, repositories and artifact paths. Its documentation explicitly states that this Shadow AI detection capability currently supports model packages.
Checkmarx approaches the problem through application security. Its AI Inventory capability, launched in June 2026, is designed to identify models, agents, MCP servers, AI libraries and SDKs in application repositories and generate an AI Bill of Materials.
These examples illustrate why “Shadow AI detection software” is not one homogeneous category. A repository security product and a web security platform may both claim Shadow AI detection capabilities while observing entirely different parts of the environment.
AI gateways and runtime monitoring
An AI gateway can provide very strong visibility when approved applications route their model traffic through it.
Depending on implementation, the organization may be able to record users or workloads, model providers, prompts, responses, token consumption, sensitive-data findings and policy decisions from one control point.
That makes gateways useful for governed enterprise AI.
But their architectural limitation is important: a gateway observes traffic that goes through the gateway.
An employee using a personal AI website, a developer calling an external API directly, or a local agent operating outside the governed route may remain invisible unless another control detects it.
AI gateways are therefore powerful detection and control points, but they should not be mistaken for enterprise-wide Shadow AI discovery.
Where Shadow AI Detection Commonly Fails
The most dangerous detection gaps are often not complete absence of visibility. They are situations where an organization sees part of the activity and assumes it sees the whole risk.
Seeing the application but not the data
Knowing that 200 employees used a particular AI service does not tell you whether they submitted public information or sensitive company material.
Application discovery without data context can generate large inventories without helping security prioritize the events that matter most.
Treating approved AI as automatically safe
An approved application can still create risky interactions.
Microsoft’s own Shadow AI guidance includes a dedicated stage for preventing sensitive data from being shared with sanctioned AI applications. Approval of the application and approval of every data flow are not the same decision.
Detection therefore should not stop once a vendor appears on an allowlist.
Missing personal accounts
A company may approve an enterprise AI platform while employees continue using personal accounts for convenience, existing history, different features or experimentation.
Netskope’s 2026 data shows why this remains relevant: 44% of AI users in its dataset were still using personal AI applications either exclusively or alongside managed ones.
A control that sees the domain but cannot distinguish corporate from personal usage may therefore provide less context than the security team assumes.
Missing developer AI
Software teams can introduce AI through repositories, libraries, model downloads, direct API calls, IDE assistants and local tooling.
These activities may be invisible to a program designed primarily around browser-based employee AI usage.
Detection coverage should therefore include the SDLC where AI development or AI-assisted engineering is material to the organization.
Missing local agents and MCP connections
Agentic AI makes the visibility problem more difficult because the AI can operate at the endpoint and interact with other tools.
The relevant questions become: Which agent is running? Which MCP servers or tools can it call? Which local files can it read? Which credentials does it inherit? What actions can it execute?
This requires observability closer to the endpoint, agent runtime or development environment rather than assuming that web traffic tells the full story.
Collecting events without creating an inventory
Detection data scattered across a proxy, endpoint platform, identity provider, DLP console, SIEM and application-security platform can still leave the organization without an answer to a basic question:
Which AI is currently being used, by whom, with what data and access?
The value comes from correlating those signals into an inventory that can support decisions.
Recognize your organization in one of these gaps?
Shadow AI Detection Tools: Choose by Coverage, Not by Category Label
Searching for the best Shadow AI detection tool can create the wrong buying question.
Different platforms focus on different detection surfaces.
Zscaler’s current AI security offering, for example, emphasizes discovery of AI application usage, prompt and response visibility, inline DLP, access control and AI asset discovery. Proofpoint emphasizes visibility into approved and Shadow AI data use, including prompts, uploads and sensitive-data exposure. DTEX approaches Shadow AI through an insider-risk and behavioral-analytics lens, focused on how sensitive data moves once an unsanctioned AI tool is in use. JFrog’s documented Shadow AI detection is centered on unmanaged model packages in repositories, while Checkmarx focuses on AI components inside the software development lifecycle.
Those are not interchangeable capabilities.
When evaluating Shadow AI detection platforms, map the product against the detection problem first.
| Decision criterion | What to verify |
| AI surface coverage | Web, SaaS, desktop, endpoint, IDE, CLI, APIs, local models, agents, MCP and repositories |
| Attribution | Whether activity can be tied to a user, device, workload, repository or business owner |
| Data context | Whether prompts, uploads and other sensitive-data movement can be classified |
| Access context | Whether OAuth permissions, connected systems or agent capabilities are visible |
| Personal vs. enterprise use | Whether the platform can distinguish relevant account or usage context |
| Developer coverage | Whether models, SDKs, AI libraries and agent components can be discovered |
| Enforcement | Whether controls can warn, redact, restrict, revoke or block |
| Auditability | Whether useful evidence is retained for investigation and review |
| Integration | Whether findings can feed existing SIEM, SOAR, ticketing, DLP or governance workflows |
| Blind spots | Which AI activity the platform explicitly cannot observe |
The last question is particularly useful.
A vendor that can clearly explain what its platform does not see often gives the security team more actionable information than one that simply promises “complete AI visibility.”
How to Test Your Shadow AI Detection Coverage
A product demonstration is not enough to prove that detection works in your environment.
Test realistic scenarios against the controls you actually operate.
| Test scenario | Detection signal you should expect |
| Employee opens a public AI service from a corporate device | Network, browser, CASB or endpoint event |
| Employee uses a personal AI account for work | Browser/endpoint signal plus account context where available |
| Confidential text is pasted into an AI prompt | Browser, endpoint or DLP data event |
| Sensitive document is uploaded to an AI service | DLP or endpoint file-transfer event |
| Approved SaaS enables a new AI capability | SaaS/SSPM, configuration or governance discovery |
| Employee authorizes an AI application through OAuth | Identity or SaaS access event |
| Developer calls an external LLM API directly | Network, code, endpoint or gateway signal depending on architecture |
| Coding assistant runs inside an IDE or CLI | Endpoint or developer-environment telemetry |
| Local model runs on a workstation | Endpoint/local process or AI asset discovery |
| Model package is added to a repository | Software supply-chain or repository scan |
| Agent connects to an unapproved MCP server | Agent, endpoint, AppSec or MCP-specific telemetry |
| AI agent reads local or enterprise data | Runtime/endpoint/data-access telemetry |
For each scenario, do not stop at “Was it detected?”
Ask whether the event tells you who or what was responsible, what AI asset was involved, whether sensitive data was present, what systems or permissions were exposed, and what response the security team can take.
That difference separates raw telemetry from useful Shadow AI detection.
Shadow AI Detection Without Blocking Productivity
Finding Shadow AI does not mean every unsanctioned interaction should immediately be blocked.
That approach can simply move usage to less visible devices, accounts or tools.
A more practical control model uses the context discovered during detection to choose a proportionate response.
| Response | When it makes sense |
| Allow | Tool and use case meet organizational requirements |
| Warn or coach | Activity is low risk but the employee needs guidance or an approved alternative |
| Protect | AI use is acceptable, but specific data or actions need to be restricted |
| Restrict | Particular users, functions, uploads or integrations create unacceptable exposure |
| Block | The application or behavior cannot be brought within acceptable risk |
Current products already reflect this direction. Zscaler documents controls that can allow, block or coach AI access and prevent specific forms of data movement. Cyberhaven documents block, warn and redact controls based on AI and data context. Proofpoint similarly describes blocking or redacting sensitive information without requiring a blanket ban on AI.
The operating principle is simple:
Control the risky interaction as narrowly as possible rather than assuming the existence of the AI tool is the entire risk.
That preserves legitimate adoption while making high-risk activity harder to ignore.
Shadow AI Detection Checklist
A practical Shadow AI detection review should establish whether the organization can answer the following questions.
- Do we know which public AI applications employees use?
- Can we identify personal AI use where our architecture allows it?
- Do we know which approved SaaS products have AI capabilities enabled?
- Can we discover AI browser extensions and desktop applications?
- Can we identify AI activity inside IDEs and CLIs?
- Do we know which external model APIs developers or applications call?
- Can we identify locally running models and agents?
- Can we discover AI models, SDKs and agent components in repositories?
- Can we identify MCP servers and other agent connections?
- Can we see AI applications authorized through corporate identity or OAuth?
- Can we detect sensitive information in prompts, paste actions and uploads?
- Can we determine which enterprise systems or data an AI application can access?
- Can findings be tied to a user, device, workload or business owner?
- Can we classify an AI asset as approved, restricted, unknown or prohibited?
- Can we retain sufficient evidence for investigation and audit?
- Do we know which Shadow AI scenarios remain invisible to our current tooling?
The final item is the most important.
A detection program is not mature because it has many security products. It is mature when the organization understands what those products can see and what remains outside their field of view.
The Goal Is Coverage, Not Another AI Tool List
The most useful Shadow AI detection program does not start by asking which security vendor has the longest list of supported AI applications.
It starts by identifying the organization’s AI surfaces and determining which signals exist for each one.
Can you see external AI applications? Can you distinguish meaningful data exposure from ordinary use? Can you identify AI connected to enterprise systems? Can you find developer AI, local models and autonomous agents? Can you explain what your existing tools still miss?
Those answers determine whether you have genuine Shadow AI visibility or simply several disconnected sources of security telemetry.
As AI moves further into endpoints, development environments, SaaS products and autonomous workflows, that distinction will matter more.
The first objective is therefore not to block every unknown AI system.
It is to establish a reliable picture of what AI is operating across the organization, what data and access it has, and where the remaining blind spots are.
From there, the organization can classify usage, apply appropriate controls and decide which risks actually require intervention.
Not Sure What Your Current Tools Actually See?
Most organizations discover their real coverage gap only after mapping every AI surface against every control they already own — and finding several combinations nobody had tested.
A Secure AI Usage Audit from CodeIT does that mapping for you: which AI is in use across your organization, what data and systems it can reach, and exactly where your current detection stack goes blind.
Ready to reveal your blind spots?
FAQ
Shadow AI detection is the process of discovering AI applications, models, agents, integrations and AI-enabled services being used without sufficient organizational visibility or approval.
Effective Shadow AI detection goes beyond identifying application names. It should help determine who or what is using the AI, what data or enterprise systems it can access, and whether the activity can be monitored or controlled.
The main Shadow AI detection methods include network and DNS monitoring, Secure Web Gateway or SSE controls, CASB and SaaS discovery, identity and OAuth auditing, browser and endpoint monitoring, DLP, repository and AppSec scanning, and AI gateway or runtime monitoring.
Organizations usually need several of these methods because each observes a different part of the AI environment.
DNS monitoring can help identify connections to known AI domains and is useful as an early discovery signal.
It cannot show the complete interaction, determine what sensitive data was submitted, or reliably discover local AI systems that never need the monitored external domain. DNS should therefore be treated as one input rather than a complete Shadow AI detection method.
Microsoft provides Shadow AI detection and protection through several connected capabilities rather than Purview alone.
Current Microsoft guidance combines Defender for Cloud Apps for discovering AI applications with Purview capabilities for detecting sensitive AI interactions and data movement. Entra and Intune can add identity, access and device-level controls. Microsoft is also adding dedicated Shadow AI visibility for unmanaged agents in the Microsoft 365 admin center.
There is no single best platform for every Shadow AI scenario.
The appropriate tool depends on the blind spot. An organization primarily concerned with employee web use needs different telemetry from one trying to inventory models and MCP components in its software supply chain or detect agents running locally on developer endpoints.
Evaluate Shadow AI detection software by the environments, signals and data flows it can actually observe rather than by the number of AI products in its catalog.
Detection establishes visibility: which AI is being used, where, by whom and under what context.
Prevention adds an enforcement decision, such as warning a user, blocking sensitive data, restricting permissions, redirecting activity toward an approved tool, or blocking the application entirely.
Detection generally needs to come first because an organization cannot apply proportionate controls to AI activity it does not understand.
