When shadow AI first became a boardroom concern, the threat model was simple: employees paste customer data into ChatGPT, that data gets used to train models, compliance nightmares follow. Security teams responded with usage policies, domain blocks, and DLP tooling pointed at AI destinations. It was a reasonable response to the threat that existed in 2023.
It doesn't fit the problem anymore.
The Threat Has Evolved
The current generation of AI tools doesn't just ingest pasted data — it requests permissions. Productivity AI tools ask to connect to your email. AI meeting assistants request access to your calendar and video conferencing platform. AI coding tools want access to your source code repositories. AI customer success platforms want a Salesforce integration.
Each of these is an OAuth grant. Each grant is an authorization token that persists long after an employee has stopped using the tool or even remembers they connected it. And each token represents standing access to enterprise systems that attackers can target — not through phishing or brute force, but through compromising the AI vendor itself.
The Klue breach announced this week is an instructive case. Attackers didn't phish Huntress or Recorded Future employees. They compromised Klue — a competitive intelligence vendor with OAuth access to its customers' Salesforce environments — and used those standing tokens to exfiltrate data from downstream organizations. The attack didn't require a single malicious click from the victim.
The Access Sprawl Problem
Most organizations have no complete inventory of which AI tools their employees have connected to enterprise systems. The OAuth grant flow is frictionless by design — an employee authenticates, clicks "allow," and gets back to work. IT never sees it. Security never reviews it.
This creates what researchers are calling AI OAuth sprawl: a growing surface of semi-forgotten access grants to AI vendors whose security postures are rarely scrutinized at the same level as a formal enterprise software procurement. Unlike a sanctioned SaaS tool that goes through vendor review, many shadow AI connections are made by individual contributors with no security sign-off.
The scale is significant. In enterprise environments with thousands of employees, it is common to find hundreds of active OAuth grants to AI tools across identity providers — the majority of which are unknown to security teams.
Why DLP Doesn't Address This
Data loss prevention tools are designed to detect and block data leaving the organization through outbound channels. They work by inspecting traffic for patterns that look like sensitive data — PII, card numbers, credentials.
But when an AI tool accesses your Salesforce environment through a valid OAuth token, there is no outbound "paste" event to intercept. The data flows through a legitimate API call to a legitimate integration. DLP sees authorized activity. The access is real because the grant was real.
This is why the access control layer — not the data leakage layer — is where the risk now lives.
What an Effective Shadow AI Response Looks Like
The organizations making progress on this problem in 2026 are shifting from a blocking posture to a visibility posture with selective enforcement:
1. OAuth token inventory — Use your identity provider's (Entra ID, Okta, Google Workspace) admin APIs to enumerate all third-party app connections. This surfaces the full extent of AI OAuth sprawl. Many organizations run this audit and find 3-5x more connected apps than their internal inventory suggests.
2. Classify by access scope — Not all grants are equal. An AI tool with read-only access to calendar data is a different risk profile than one with read-write access to your CRM or code repositories. Prioritize review of grants with broad data access.
3. Revoke stale grants — Any OAuth grant for an AI tool that hasn't been accessed in 90 days should be reviewed and likely revoked. Most identity providers have usage telemetry that makes this tractable.
4. Rate-limit or scope third-party API access — For CRM and collaboration platforms, restrict third-party integrations to specific objects and operations rather than granting broad access. Salesforce, for example, supports fine-grained Connected App policies.
5. Vendor security assessment for high-value integrations — Any AI tool granted access to CRM, code, HR, or financial data should undergo the same security review as any other third-party vendor. The Klue incident is a reminder that attackers go through the weakest link in the chain.
The Reframe
The shadow AI conversation needs to shift from "don't paste data into AI tools" — a policy that was always difficult to enforce and is becoming harder as AI becomes embedded in every productivity tool — to "govern what AI tools can access."
The former is a user behavior problem. The latter is a systems architecture problem. Systems architecture problems are tractable in ways that user behavior rarely is.
DLP policies are not going away, but they are no longer the primary control surface. OAuth lifecycle management, third-party app governance, and supply chain security for SaaS vendors are where security teams need to direct attention as the shadow AI threat matures.