Your buyer's identity infrastructure is already collecting evidence of ungoverned AI adoption. OAuth consent records, SSO bypass alerts, personal IdP tokens on managed endpoints. The signal is sitting in authentication logs. Most security teams aren't reading it as an AI problem because it looks, at first glance, like a shadow SaaS problem. And they know how to handle shadow SaaS.
That familiarity is an asset with a blind spot built in. Shadow AI follows the shadow SaaS pattern right up to the point where it diverges in ways that the old remediation playbook doesn't cover. The divergence is specific, structural, and it matters for your next discovery call.
Two datasets worth citing, with the caveats you need to cite them honestly
The Verizon 2025 DBIR found that 15% of employees routinely access generative AI on corporate devices, defined as at least once every 15 days. Of those, 72% authenticate with personal, non-corporate email accounts. Another 17% use corporate email without integrated authentication. Only 11% go through corporate SSO.
72% of employees using GenAI at work authenticate with personal accounts. Only 11% go through corporate SSO. Ask your buyer if they know their own ratio.
Methodology context: the DBIR's 18th edition analyzed over 22,000 incidents and 12,000 confirmed breaches from nearly 100 global contributors across 139 countries. That's the industry's most established breach dataset. But the GenAI authentication finding is narrower. It's scoped to corporate-managed devices, which means employees accessing AI from personal devices are invisible to it. The specific contributor(s) who provided the GenAI telemetry aren't named, so you can't evaluate sample representativeness for this particular finding the way you can for the DBIR's core breach statistics. The data source type (endpoint telemetry vs. survey) is inferred from context, not confirmed. Cite it as directionally strong. Don't cite it as precise. (Note: the 2026 DBIR is now in market and may contain updated numbers. Verify before a high-stakes conversation.)
The Public Sector AI Adoption Index 2026, published by Public First for the Center for Data Innovation with Google sponsorship, surveyed 3,335 public servants across 10 countries, including 301 in the U.S. The finding that travels: 70% of public servants in organizations with limited AI guidance use AI tools without their managers knowing. A paired number: 64% of enthusiastic AI users in those same low-enablement environments rely on personal logins.
The critical caveat is the conditional. That 70% describes behavior specifically where guidance is limited. It does not describe all government agencies. The full survey instrument, including exact question wording and how "limited guidance" was operationally defined, isn't available in the published summaries. Google funded the research; Public First conducted it independently. The U.S. sample of 301 is adequate for establishing a pattern, thin for agency-level conclusions. Use it to describe the dynamic, not to characterize any specific buyer's environment.
Both datasets point the same direction. The governed path is losing. Employees are authenticating to AI services through channels that bypass everything the buyer built.
The shelf life of your shadow SaaS instincts
You've lived through this pattern. Employee needs a tool. The approved option doesn't exist or takes six weeks to provision. They sign up with a personal account. An OAuth grant appears in the logs connecting an unfamiliar service to corporate data. You know the discovery sequence. You know the remediation playbook: find the grants, assess the scopes, sanction or block.
Shadow AI starts identically. An employee connects ChatGPT to their work email. A developer authorizes a coding assistant to access a repository. A program manager grants an AI summarization tool read access to their calendar. Each creates an OAuth consent event that looks, in the logs, like every other unsanctioned SaaS adoption you've tracked.
Your OAuth intuition serves you well here. A few steps further, and the terrain changes.
Shadow SaaS moved data. An employee put a file in Dropbox, and the file was in Dropbox. The risk was data exposure, and the blast radius was the data itself. You could measure it, scope it, remediate it. Shadow AI moves data too, but the data comes back. A draft written by an ungoverned AI tool gets pasted into an internal document. A code suggestion from an unauthorized assistant gets committed to a production repo. The AI's output re-enters the enterprise as work product, carrying whatever errors or hallucinations came with it, and nobody downstream knows the provenance. That's a new problem, but it's still a problem you can reason about with your existing model.
Go one level deeper. Shadow AI processes data and creates new access paths that compound autonomously. When an employee grants an AI agent OAuth access to their Google Drive, that agent can read, and in some configurations act on, everything the employee can access. If that agent connects to another service through a plugin or MCP-style tool integration (where the agent dynamically discovers and invokes capabilities in other systems, meaning the access surface isn't static but expands as the agent operates), the access chain extends further. Each link is a non-human identity with broad, potentially long-lived privileges. None of them went through onboarding, MFA enrollment, or access review. There's no offboarding process because nobody provisioned them in the first place. The identity perimeter got delegated around, one OAuth consent at a time. The shadow SaaS playbook treated the unsanctioned tool as the endpoint. An AI tool with agent capabilities is a node that creates other nodes.
What this looks like in authentication telemetry
If you're helping a buyer understand what to look for, these are the specific artifacts.
OAuth consent grants to AI services. The most visible signal. An employee authorizes an AI tool to access email, calendar, file storage, or a code repository. The grant appears in the identity provider's consent log. Scopes matter enormously: Files.ReadWrite.All or Mail.ReadWrite on an AI service client is a different risk profile than profile and email. High-risk scopes granted to unfamiliar AI clients are the highest-priority finding.
Personal IdP tokens on managed endpoints. The DBIR's 72% made visible. An employee on a corporate laptop authenticates to a personal Google or Microsoft account and uses that personal identity to access an AI service. The endpoint management system sees the device. The identity provider sees the corporate session. But the AI authentication flows through a personal account the organization doesn't control, can't audit, and can't revoke.
API connections bypassing SSO. Netskope's telemetry shows 66% of organizations have users making API calls to api.openai.com, distinct from browser-based ChatGPT access. API-level access suggests programmatic integrations, custom tools, or agent frameworks operating outside the browser where most monitoring still focuses. These connections often use API keys generated directly by the employee, completely outside SSO.
Browser extension permissions. LayerX's research found one in six enterprise users runs at least one AI-enabled browser extension, with 73% of those carrying high or critical permission scopes. An AI writing assistant with access to everything typed in the browser is a persistent, live data grant sitting below typical detection thresholds. (LayerX is a browser security vendor; treat their statistics as directionally credible with commercial context.)
The diagnostic problem is fragmentation. An employee installs an AI tool on a managed laptop, connects it to Google Drive via OAuth, and signs in with a free-tier personal account. Your EDR sees the install. Google Workspace logs the OAuth grant. The identity provider records a sign-in event. Each tool in the stack sees its own slice. The OAuth alert is low-priority in one console. The endpoint finding is medium-severity in another. The sign-in log is informational in a third. Nothing connects them to the same employee, the same tool, the same risk. Security teams either chase each fragment manually or, more commonly, deprioritize all of them because no single alert crosses the threshold.
Okta's Agent Discovery capability in ISPM, part of the Okta for AI Agents suite announced as generally available for U.S. customers on April 30, 2026 (though individual ISPM features may still be in Early Access), addresses this convergence problem. It uses a browser plugin to capture OAuth consent events in real time, maps the relationship between the AI tool and the data source, tags grants it identifies as AI-associated, and surfaces the scopes so security teams can see the blast radius. Whether your buyer runs Okta or not, the capability illustrates the detection model: the identity layer is where these signals converge, because AI tools authenticate through identity infrastructure even when they bypass everything else.
Friction-driven adoption
Raise this topic with a defensive buyer and the framing you choose will determine whether the conversation opens or closes.
Employees authenticate to AI tools with personal accounts because the governed path doesn't exist, or it's too slow, or the approved tool doesn't do what they need. The Public Sector AI Adoption Index makes this explicit: shadow usage concentrations track directly to low-enablement environments. Where organizations provide AI through formal platforms, shadow usage drops. Where they don't, employees improvise.
Call it a provisioning gap. Walking into a CISO conversation implying employees are going rogue gets you defensiveness. Observing that authentication data suggests employees want AI tools and are finding their own path to them describes a solvable infrastructure problem.
The buyer's identity telemetry is doing double duty here, and it's worth naming both functions. The same OAuth grants that represent ungoverned risk also represent employees telling you what tools they need. A cluster of personal-account authentications to a specific AI service is a security finding and a demand signal. Reading it as both gives you a productive frame: what to provision next, rather than who violated policy.
Discovery questions that surface identity-layer pain
These are for CAIO or CISO conversations. Each one maps to a specific finding or telemetry gap described above, so the buyer can verify the answer against data they already have.
-
"Do you have visibility into OAuth consent grants from AI services in your environment today?" Tests whether the buyer is reading the signal at all. Most aren't. The answer tells you how much of the conversation is net-new awareness versus refinement.
-
"When employees use generative AI on managed devices, do you know whether they're authenticating through corporate SSO or personal accounts?" Maps directly to the DBIR's 72/17/11 split. The buyer almost certainly doesn't know their own ratio. The question creates curiosity without accusation.
-
"If an AI tool that an employee authorized via OAuth connects to a second enterprise application through a plugin or API, does that second connection pass through your identity provider?" Surfaces the access-chain problem. Most buyers haven't thought about the transitive trust implications. The question makes the gap concrete.
-
"How are you handling non-human identities created by AI agents or integrations? Do they go through the same lifecycle management as service accounts?" Opens the governance conversation. AI agents that persist with long-lived tokens and no offboarding process are service accounts that nobody provisioned.
-
"What's your current process when an employee requests access to an AI tool that isn't in your approved catalog?" Tests the friction hypothesis. If the answer is "we don't have one" or "it takes weeks," you've identified why employees are going around the perimeter. The identity problem and the enablement problem are the same problem.
Each question works because it starts from something the buyer can check. The authentication data exists. The OAuth grants are logged. The gap between what's recorded and what's reviewed is where your conversation lives.
Things to follow up on...
-
The 2026 DBIR dropped: Verizon's 2026 edition is now in market and may update the 72%/11% GenAI authentication split with a full year of additional telemetry — worth checking before you build a deck around last year's numbers.
-
IBM priced the breach: The IBM Cost of a Data Breach Report 2025 found shadow AI contributed to 20% of breaches studied, adding an average of $670,000 per incident, which gives the CISO conversation a dollar figure if the identity telemetry argument alone isn't landing.
-
Netskope sees the API layer: Their Shadow AI and Agentic AI report found 66% of organizations have users making API calls to api.openai.com distinct from browser access, suggesting programmatic and agent-framework integrations that sit outside browser-focused monitoring entirely.
-
CyberArk quantified the governance gap: Their 2025 Identity Security Threat Landscape report found 96% of enterprises recognize AI agents as a risk, but fewer than half have governance controls in place — a stat that pairs well with the discovery question about non-human identity lifecycle management.

