Shadow AI Detection Methods for Enterprise Security Teams
GenAI traffic surged more than 890% in 2024. Shadow AI tool usage grew 156% between 2023 and 2025. These figures don't describe a familiar problem getting worse. They describe a qualitative shift in the threat surface, one that has already outpaced the detection postures most enterprises spent years building.
Shadow IT was, at its core, a cataloging problem. You identified unauthorized SaaS endpoints, enforced blocklists, and worked the list down. Shadow AI is different in kind. It doesn't merely reside in external systems; it actively processes, learns from, and in many cases retains enterprise data under consumer terms that provide no enterprise deletion pathway. The Samsung incident of 2023 remains a widely cited illustration of this risk — three separate data-exposure events in twenty days, in which engineers reportedly fed proprietary source code, internal meeting transcripts, and chip-yield test sequences into ChatGPT under consumer terms. The data left the organization with no recovery mechanism and no audit trail. No blocklist would have caught it, because the tool wasn't novel. The behavior was.
The behavioral data surrounding that class of incident is now substantial. According to Menlo Security's 2025 Browser Security Report, 68% of employees access AI tools through personal accounts using free-tier services, and 57% enter sensitive data into those applications. IBM's 2025 Cost of a Data Breach Report places AI-associated breaches at more than $650,000 per incident above the baseline average, with a 247-day mean identification and containment window. Only 12% of companies report the ability to detect all shadow AI usage, per the same IBM report, and fewer than 11% of AI applications in the workplace are visible to IT teams, per the Awareways Trend Report 2025. The other 89% are operating in structural blind spots. This is the baseline condition, not a tail risk.
What follows is a systematic account of how shadow AI can be detected, where each detection method fails, and what a complete detection posture actually requires.
Network Traffic Analysis: Catching AI Connections at the Wire
The first detection layer operates at the network level, monitoring outbound HTTPS traffic to AI API endpoints, DNS queries to AI-associated domains, and payload sizes consistent with prompt and completion exchanges. When an employee submits a prompt to OpenAI, Anthropic, Hugging Face, Cohere, or Replicate, that request traverses the corporate network and resolves through DNS. Both events are observable.
In practice, this means deploying SSL/TLS inspection or routing traffic through a CASB proxy capable of decrypting and classifying AI-bound sessions. Allowlist and blocklist enforcement at the firewall or secure web gateway layer handles known AI service domains. Anomaly detection on upload volume, particularly bulk text or structured file transfers to unfamiliar API endpoints, provides a behavioral signal. DNS logging adds coverage for novel or newly registered AI service domains before they appear on vendor blocklists.
The gaps are specific, and understanding them matters as much as deploying the layer itself. Browser extensions that operate within already-trusted HTTPS sessions to sanctioned SaaS portals bypass this detection surface entirely. A 2025 campaign documented by security researcher John Tuckner involved more than 40 AI productivity extensions that scraped data from active browser tabs and bypassed DLP filters without generating anomalous outbound traffic. AI features embedded inside sanctioned applications, such as Salesforce Einstein or Microsoft Copilot in Teams, produce traffic indistinguishable from normal product use. API calls made from developer laptops over personal hotspots or VPNs exit the corporate network before any inspection occurs.
The s1ngularity and Shai-Hulud attacks of late 2025 mark a useful ceiling for what network analysis can reliably catch. In those campaigns, AI-powered malware hijacked local CLI tools to exfiltrate GitHub and npm tokens, then used those credentials to republish malicious packages. The exfiltration path was indistinguishable from legitimate developer tool traffic. Network analysis is a necessary first layer. It is not sufficient on its own.
Identity and Access Monitoring: Finding AI Usage in the Authentication Record
Shadow AI agents typically operate under legitimate user credentials. They appear in authentication logs as authorized sessions. What distinguishes them isn't their presence but their behavioral pattern, and identifying that pattern requires knowing what to instrument.
The highest-value signals are OAuth token grants. When employees authorize third-party AI applications against corporate identity providers such as Okta or Microsoft Entra ID, a grant record is created, and that record is often the earliest observable signal that an unsanctioned tool has been connected to the corporate environment. Service account anomalies are equally informative — a service account that begins calling an LLM API or an unfamiliar external endpoint is a high-confidence indicator of agentic activity. SCIM provisioning gaps, where AI tools bypass SSO entirely and are therefore absent from the identity provider's application registry, identify a distinct class of shadow tooling. Agents requesting read-all-mail or access-all-files permissions, relative to a stated narrow purpose, consistently warrant scrutiny.
The agentic dimension makes this layer more complex than it first appears. Agents built on frameworks like LangChain or AutoGPT frequently run under a developer's personal OAuth token, and the tool call chain following the initial grant is invisible to the identity provider unless the gateway or agent framework is separately instrumented. IBM's 2025 Cost of a Data Breach Report found that 63% of organizations either lack an AI governance policy or are still developing one. Without a governed application registry, there is no baseline against which to difference identity logs. You cannot detect deviation from a normal you have not defined.
The integration point that makes identity monitoring actionable is a SIEM. A spike in OAuth grants to AI applications coinciding with sensitive data access is substantially more informative than either event in isolation. The layer's hard limit — consumer AI tools accessed through a personal browser profile or personal Google and Microsoft account generate no corporate IdP signals at all.
SaaS Discovery and App Graph Analysis: Mapping What Employees Have Actually Authorized
Organizations manage an average of 490 SaaS applications, and only 47% of those are authorized, per Reco's State of Shadow AI report. SaaS discovery is the layer built to map that territory, not the authorized portion, but all of it.
The primary mechanism is OAuth token graph analysis, scanning Google Workspace or Microsoft 365 admin APIs to enumerate every third-party application that employees have individually granted access to corporate accounts. This produces a comprehensive view of the app graph — not just what IT provisioned, but what employees have authorized on their own initiative. The delta between those two populations is where shadow AI lives. Browser extension inventories, pulled from endpoint management platforms like Jamf or Intune, surface the extension layer that network monitoring cannot reach. Procurement and expense data mining identifies AI subscriptions charged to corporate cards without IT approval. App risk scoring then grades each discovered application against security criteria, including encryption posture, MFA enforcement, and enterprise deletion pathway.
Reco's research identified multiple high-risk shadow AI applications lacking these basic controls. The app graph reveals which specific tools employees trust enough to connect to their work accounts, what data scopes those connections carry, and whether any security review has been conducted. The answer is frequently no, and seeing that documented in a scan report rather than hypothesized in a risk register tends to change how urgently leadership treats the problem.
SaaS discovery also surfaces agentic deployments that other layers miss. An agent framework registered as an OAuth application in a corporate Google tenant is detectable through the app graph even if its network traffic is indistinguishable from a normal API call. The remaining gap is real — SaaS discovery catches apps connected to corporate identity but still misses the 68% of employees using AI through personal accounts where no corporate OAuth grant is ever created.
Behavioral Telemetry and Endpoint Signals: Detecting AI Use When All Other Layers Are Blind
Behavioral telemetry operates at the endpoint and watches for data movement patterns that correlate with AI tool usage regardless of what network, identity, or SaaS signals are present. It is the detection layer you fall back on when the others come up empty.
The signals it monitors include clipboard and file-transfer events — large copy-paste operations from internal documents to a browser tab pointed at an AI service domain. Typing cadence and input volume on known AI service URLs, captured by endpoint DLP agents, provide a secondary signal. File upload events to non-allowlisted HTTPS endpoints, especially structured data formats such as CSV, JSON, or SQL exports routed to unfamiliar destinations, are strongly indicative. Process execution signals cover a distinct and growing class of risk — local model runners like Ollama or LM Studio, Python environments with LLM libraries, and MCP server processes running directly on developer endpoints.
That last category is the hardest detection problem in the current landscape. Open-source models running entirely on the device generate no outbound network traffic whatsoever. Behavioral and process telemetry is the only available detection surface for that class of deployment. Data-centric DLP platforms that scan SaaS messages, documents, and workflows for sensitive content flowing toward AI tools complement this layer by catching data movement even when the tool itself evades discovery.
Sophisticated agentic workflows still resist endpoint-only detection. Orchestrated tool calls distributed across time look like ordinary user activity when observed at any single point in the sequence. Anomaly detection in this context requires baselines built across sessions, not point-in-time event matching. Teams that skip that distinction will generate high false-positive volumes before surfacing a confirmed incident, and high false-positive rates erode analyst trust in tooling faster than almost anything else.
Why Each Layer Misses What the Others Catch: Building a Combined Posture
No single detection method has complete coverage, and the gaps aren't random or evenly distributed. Network traffic analysis catches external API connections and misses embedded AI features and local models. Identity monitoring catches OAuth grants and misses personal-account access. SaaS discovery catches connected apps and misses browser-only AI use with no OAuth grant. Behavioral telemetry catches data movement but generates signal volume that demands careful tuning. Each layer's blind spot is precisely where an adjacent layer has coverage.
A detection posture that matches the actual threat surface feeds all four signal types into a SIEM or SOAR and constructs correlation rules that trigger on combinations. An employee with a new OAuth grant to an AI tool, concurrent with a spike in file uploads from a managed device and no corresponding IAM policy approval, is a substantially more actionable signal than any of those three observations standing alone. Combination is what converts noise into an incident.
For teams with constrained capacity, the build sequence matters. SaaS discovery and identity monitoring should come first; they offer the highest signal-to-noise ratio and integrate most naturally with existing IAM infrastructure. The network layer follows. Behavioral telemetry provides the broadest coverage but carries the highest tuning cost and is most effective once the other layers are producing baselines to correlate against. Deploying behavioral telemetry before those baselines exist generates noise before it generates signal.
Vectra AI's research found that 49% of organizations expect a shadow AI incident within the next twelve months. Building all four layers before that incident occurs is time-bounded work.
The Agentic Detection Gap That Conventional Methods Don't Close
Agents and MCP servers are structurally different from the shadow AI the prior layers were designed to detect. Most security teams intellectually acknowledge this. Fewer have fully reckoned with what the difference means operationally, and the gap between intellectual acknowledgment and operational readiness is where the next wave of incidents will originate.
Agents execute multi-step tool call chains autonomously. Each individual step looks legitimate in isolation — an authorized user credential makes an authorized API call. The problem emerges from the combination and sequence of calls, which can create effects that no single permission policy anticipated. A read-calendar permission combined with a send-email permission creates an exfiltration pathway that neither permission alone would trigger. The composition is the vulnerability, not the individual capability.
MCP servers deployed locally or in developer environments generate no SaaS OAuth grants and minimal network anomalies. Frameworks like LangChain, AutoGPT, and CrewAI allow individual developers to deploy agents against internal APIs without any IT touchpoint. GitGuardian's 2025 research found 24,008 unique secrets exposed in MCP configuration files, including Google API keys and PostgreSQL connection strings. Ad hoc MCP deployment is already creating credential sprawl at scale, and most of that exposure is invisible to the four detection layers described above.
Without a governed control point, each agent carries its own API keys, OAuth tokens, and service account credentials for every tool it accesses. Those credentials scatter across environment variables and configuration files with no central audit trail. The s1ngularity and Shai-Hulud attacks demonstrated exactly what that exposure enables — stolen credentials from developer tool environments, used to republish malicious packages at scale, bypassing static security scans entirely. What the four detection layers cannot provide is a detection surface that sits between agents and the systems they call. That requires a governed control point at the protocol layer, not another scan of the endpoint or network perimeter.
What a Governed AI Control Layer Adds That Detection Alone Cannot Provide
Detection tells you shadow AI is present. It does not stop the data from leaving. The distance between those two facts is where governance operates, and closing it is an enforcement problem, not a detection problem.
At the authentication layer, a governed control plane means every MCP tool call authenticated against existing identity providers via OIDC or OAuth 2.1, eliminating anonymous agent interactions entirely. Role-based access control at the tool level allows an agent to be permitted for CRM reads but not writes, regardless of what the underlying API permits. Real-time prompt inspection for PII, secrets, and injection payloads catches the Samsung-class incident before the data reaches the external model. An immutable audit log of every tool call, capturing which agent, which tool, what arguments, whose identity, and what was returned, is precisely the artifact whose absence contributes to the 247-day identification and containment windows IBM documented. A centralized MCP server registry replaces ad hoc deployment and makes shadow MCP servers visible and governable.
There is also a behavioral dimension to governance that detection alone cannot address. When employees have access to approved tools through clear, legitimate pathways, unsanctioned workarounds become less attractive and less necessary. Governance that is purely restrictive without providing capable alternatives displaces risk rather than reduces it.
SpeakeasyAPI sits between the identity layer and the AI tool, capturing both the OAuth grant and the downstream API calls an agent makes. It converts identity logs from a partial signal into a complete audit trail of who authorized what and what the agent actually did with that authorization. For security teams that have built the four detection layers and are confronting the agentic gap, a governed control plane is where detection posture becomes enforcement posture. The detection methods described throughout this piece are available now. The threat they address is already operating at scale inside most enterprise environments.
