Shadow AI Discovery Methods and Tooling
Security teams are not losing the shadow AI battle because they lack effort. They are losing it because they are using the wrong map. Discovering unsanctioned AI requires cataloging every AI app, account, integration, and embedded feature that exposes corporate data to third-party providers, and that inventory lives at multiple layers of the stack simultaneously. No single detection method reaches all of them.
The awareness gap is not subtle. Security teams typically believe they know about a handful of AI tools running inside their organizations. The real number runs into dozens. The HiddenLayer 2026 AI Threat Landscape Report, drawing on 250 IT and security leaders, found that roughly three-quarters of organizations now cite shadow AI as a definite or probable problem, representing one of the largest year-over-year shifts in that dataset. The UpGuard State of Shadow AI report, surveying 500 security leaders and hundreds of employees globally, found that the majority of both groups report using unapproved AI tools — the people responsible for stopping the problem are, statistically, also participating in it.
Personal accounts are the dominant blind spot. Roughly half of employees using generative AI platforms do so through personal accounts the company cannot see or govern, per the 2025 State of Shadow AI Report. The 2026 Verizon DBIR corroborated this: most AI access on corporate devices runs through personal, non-corporate accounts. That single behavioral pattern defeats a wide swath of conventional detection infrastructure, which depends on corporate identity signals to attribute activity to a specific user or device. No corporate identity, no signal.
Smaller organizations assume that size provides natural insulation. It does not. Without dedicated security teams or formal governance programs, per-capita shadow AI exposure at small and mid-market companies runs at least as high as at large enterprises, and often higher, because the absence of any program means no detection at all.
The city of Eindhoven documented employees uploading 2,368 files containing personal data to public AI tools in a single 30-day period, per its 2025 transparency report. This was a municipality with mature security teams and existing controls already operating. Shadow AI is not a tail risk that diligent teams have managed down — it is an active, ongoing exposure.
Why shadow AI evades the detection approaches built for shadow IT
Shadow IT, for all the headaches it caused, left a discoverable trail. Procurement records, software installs, recognizable network signatures, browser extension manifests: any one of those artifacts was sufficient for a CASB or application inventory to catch the problem. Security tooling from the 2010s was, in retrospect, well-matched to the threat.
Shadow AI systematically removes most of that trail. Browser-based access to a tool like ChatGPT or Claude leaves no endpoint footprint; the application runs entirely in a tab and disappears when the tab closes. Personal accounts generate no corporate identity signal, no OAuth grant the organization can audit, no SSO log entry.
The embedded AI feature problem is particularly corrosive to existing frameworks. When a sanctioned platform like Notion or GitHub quietly enables an AI capability, it shares the same domain, the same authentication flow, and the same traffic pattern as the approved product. A CASB rule or blocklist built around application identity cannot distinguish between a user accessing approved Notion content and that same user feeding a contract into Notion AI, because the traffic looks identical. The tool is approved; the behavior is not; the detection gap lives in that distinction.
Developer API usage compounds this further. A data scientist calling the OpenAI API from a Jupyter notebook, billed to a personal credit card, leaves no procurement touchpoint whatsoever. The detection requirement has shifted qualitatively: finding shadow AI means achieving visibility into data flows, prompt content, and identity behavior, not just maintaining a list of unauthorized application names. A program built on any single detection layer will have predictable blind spots. That is a structural fact, not a criticism.
Network traffic analysis and CASB: what they catch and where they stop
Network-layer analysis works by examining DNS queries, TLS certificates, and traffic patterns to identify connections to known AI service endpoints: OpenAI, Anthropic, Google AI, and hundreds of smaller providers. CASB platforms extend this from passive observation to active policy enforcement, enabling organizations to block, alert, or restrict data flows to unapproved AI platforms rather than simply log them.
The enterprise options here are substantive. Netskope, Zscaler AI Protect, and Palo Alto Networks Prisma SASE 4.0, the last covering more than 6,000 generative AI applications, all offer generative AI governance capabilities built on this foundation. For managed devices on a corporate network, this layer provides enterprise-wide coverage that scales without per-endpoint deployment, and it feeds enforcement rather than mere visibility.
The structural limitations are real, though. Network-layer inspection misses AI usage on personal devices even when those devices are accessing corporate data. Encrypted tunnels and VPNs obscure traffic. Novel or niche AI services not yet catalogued in threat intelligence databases are invisible to any blocklist. Browser extensions communicate through the browser's own encrypted channel. Embedded AI features inside approved SaaS are definitionally indistinguishable from the approved product at the network layer. And AI tools accessed through personal accounts on managed devices bypass corporate identity entirely.
CASB catches the most obvious surface: direct, relatively unauthenticated access to known AI endpoints on managed devices. It is a necessary starting point, not a sufficient one.
Browser-level monitoring: the detection layer that reaches what network inspection misses
Most shadow AI is accessed through web browsers. That single observation points to the browser as the detection surface that catches tools capable of evading every other method described here.
Browser-level monitoring surfaces visits to AI service domains even when access occurs through personal accounts. It catches AI-powered browser extensions interacting with enterprise content in real time, file and data uploads to AI platforms as they happen, and prompt content and interaction context that network inspection cannot read inside encrypted sessions. Network analysis sees that a connection to an AI endpoint occurred; browser-level monitoring can see what was sent.
Harmonic Security, Prompt Security (acquired by SentinelOne in August 2025), and Cato Networks' Enterprise Browser all operate at this layer, providing interaction-level visibility that CASB cannot reach. Endpoint monitoring extends the same principle to desktop and mobile applications interacting with AI services outside the browser.
The constraint is straightforward: browser-level monitoring requires deployment on managed devices. Organizations with large BYOD populations or contractors operating outside device management should expect this layer to leave that gap open. What browser monitoring tells you is which tools are being used and what data is flowing through them. It does not tell you who approved what, what permissions those tools have inherited, or which of them are operating with elevated privileges. That question belongs to identity analysis.
Identity signals, OAuth audits, and SSO logs as a shadow AI detection layer
An employee accessing an AI tool through a personal account leaves no corporate network trace, but an OAuth grant from a corporate account to that tool does. The identity layer is where access patterns become auditable even when the tools themselves are invisible elsewhere.
The relevant artifacts to examine in identity provider and SSO logs: OAuth grants to unapproved AI applications, with particular attention to the scope of access granted rather than just the name of the application; authentications to AI tools using personal accounts on managed devices; service accounts showing AI-related API activity that no human owner can explain; and non-human identities, automation scripts and agents, accumulating permissions that IT never explicitly granted.
The agent-specific risk deserves direct attention. AI agents inherit human-scale access through OAuth and execute at machine speed. The access models built for human users assume deliberate, relatively slow interaction. They do not account for an agent that can enumerate, read, and exfiltrate at a rate no human workflow would generate. Broad OAuth scope plus high execution velocity is the combination where shadow AI crosses from a data governance concern into a security incident.
Reco.ai operates at this layer, mapping AI activity to user and non-human identities and exposing access levels and permission scope across the environment. Combined with CASB telemetry, this layer surfaces AI hiding inside approved SaaS through unexpected OAuth grants that the network layer would never have flagged. What identity analysis still misses: AI tools that bypass OAuth entirely. Browser-only access through personal accounts, locally deployed models, and developer API calls using personal credentials are invisible here. Endpoint interrogation addresses that gap.
SaaS management platforms and email-based discovery for finding AI in the SaaS estate
Shadow AI spreads through SaaS channels in ways that are easy to miss. Employees sign up for AI services using corporate email addresses, approve OAuth connections from within already-approved platforms, or expense subscriptions that never reach IT procurement. The asset exists; it just never entered the approved inventory.
SaaS management platforms and SSPM tools discover this by monitoring corporate email-based sign-ups to AI services, OAuth grants originating from within approved SaaS platforms, and usage patterns tied to specific employees. Zylo, as a concrete example, discovers AI subscriptions that bypass IT approval and procurement, connecting usage back to individual employees across the SaaS estate.
Email-based discovery is a complementary approach: it connects to the corporate email provider, scans historical and ongoing email activity for evidence of AI tool adoption, and can surface what is already in the environment without requiring weeks of forward-looking data collection. The historical coverage is particularly useful for auditing a backlog of ungoverned adoption that accumulated before anyone thought to look.
Both methods miss AI tools operating outside the SaaS model entirely. A locally deployed language model, a browser extension that never generates a sign-up email, and a developer API call billed to a personal credit card are all invisible here. That specific population — the developer or technical user who routes around procurement channels by design — is addressed by endpoint interrogation.
Endpoint interrogation for detecting local AI infrastructure
Developers, data scientists, and technical analysts are the population most likely to generate shadow AI exposure that every other method misses. They install local model runtimes, run MCP servers on development laptops, and call AI APIs directly from scripts and notebooks, frequently using personal payment methods to avoid generating any procurement footprint. This is not accidental; it is the path of least friction for someone who knows what they want to build and has no patience for a ticketing system.
Endpoint interrogation looks for installed applications providing AI capabilities, including local LLM runtimes and coding assistants with offline modes; running processes associated with language models or model servers; local MCP servers that enable agent functionality, along with the cloud resources and identities those servers can reach; and API keys stored in environment variables or configuration files pointing to external AI providers.
Qualys TotalAI provides layered MCP server discovery across network, host, and supply chain perspectives, addressing the reality that most organizations currently have no visibility into what their MCP servers expose or the degree to which they can be misused. Knostic's Kirin operates at the IDE layer where developers actually interact with AI coding assistants, functioning at interaction time rather than scanning logs after the fact.
Microsoft's direction here is worth noting explicitly. Microsoft Agent 365, which reached general availability in May 2026, surfaces local agent discovery through Microsoft Defender and Intune, mapping relationships between agents, devices, configured MCP servers, identities, and reachable cloud resources. Framing agentic AI governance as an endpoint security concern is accurate, and it is overdue.
An MCP server running on a developer's laptop is an agent runtime with access to whatever credentials and cloud resources that developer can reach. This is the category where shadow AI stops being a data leakage concern and starts being an autonomous action risk. Shadow AI findings with execution capability should sit at the top of the queue; not all of them carry equal weight.
Purpose-built shadow AI discovery platforms and how they differ from layered point tools
The core architectural distinction between point tools and purpose-built shadow AI platforms is not the sophistication of any individual detection method. It is cross-correlation. A tool surfacing in network traffic, an OAuth grant, and a billing email is higher confidence than any single signal in isolation. Severity scoring and remediation prioritization across a unified inventory, rather than per-source alerts requiring a human to manually connect the dots, is the operational value that purpose-built platforms deliver.
Sola Security cross-correlates findings across multiple data sources, converting disconnected signals into severity-scored findings with remediation guidance attached. Credo AI produces a real-time catalog of active AI tools organized by department and user, then applies risk classification to the result; the governance-first framing is visible in the product design. Cyberhaven takes a different angle, tracing how information moves across applications to provide data-flow lineage rather than just tool presence. Knowing that a specific document traveled from a sanctioned repository into an unapproved AI tool is a qualitatively different finding than knowing the AI tool exists. Nightfall focuses on the data security side, scanning messages, documents, and workflows for sensitive content exposed to AI tools using context-aware detection that adapts to behavioral patterns over time. Teramind uses session recording and behavioral baselining to flag anomalous data-sharing patterns indicative of feeding sensitive information to AI tools. C1, which launched in July 2026, combines cloud-side and endpoint-side discovery in a single platform and represents one of the more recently arrived entrants specifically targeting this problem.
One framing worth internalizing before evaluating these platforms: a purpose-built solution is not a replacement for network, identity, and endpoint instrumentation. It is a correlation layer that makes the signals from those existing methods more actionable. Organizations that have yet to instrument the underlying layers will find that purpose-built platforms have less data to cross-correlate and produce correspondingly incomplete inventories. Build the detection surface first; add the correlation layer to operationalize it.
