Shadow AI reaches company data through OAuth and personal accounts

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WatchGuard's report: Shadow AI can reach corporate data through OAuth consent, personal accounts and network-only access, leaving security teams blind until exposure occurs.

Why it matters: IAM, NHI and cloud security teams need to correlate identity, endpoint and network signals so unsanctioned AI use can be governed before it creates data leakage or audit gaps.

By the numbers:

• 64% of employees report using unsanctioned AI tools for work tasks.
• Shadow AI incidents cost organisations an average of $5.39 million, above the global average breach cost of $4.99 million.

Context

Shadow AI is a governance problem as much as a security one: employees can adopt tools in seconds, often outside approved procurement, identity review and data handling controls. The risk is not only that an unapproved application exists, but that it can be linked to corporate data before anyone has an inventory of it. shadow AI discovery is the right starting point because the visibility gap sits across identity, device and network telemetry, not inside one console.

The core failure is fragmented evidence. OAuth consent logs show one class of access, personal accounts hide another, and network telemetry reveals services that never touch the corporate identity stack. That means traditional app inventories miss the path by which data moves into external AI services. In practice, the starting position is typical of modern SaaS and AI use, not an edge case.

For identity teams, the important change is that access governance now has to account for tools that are never formally onboarded. The challenge is not only who signed in, but which application gained permissions, which data was uploaded, and whether the usage stayed within policy once the initial click happened.

Key questions

Q: What are the signs that shadow AI is already operating in an organisation?

A: Common signs include sudden productivity jumps in a team, unusual data uploads to external AI platforms, and unexplained API calls or suspicious queries to third-party services. These signals often indicate that employees are using unauthorized tools outside IT visibility. The practical response is to investigate data flows, user behaviour, and application logs together.

Q: Why do OAuth consents create shadow AI risk even when the app is approved?

A: OAuth consents can turn a short user interaction into durable cloud access with read, write or delete scope. Even if the app was individually approved, the permission may persist long after the employee stops using it. That makes consent review and revocation part of access governance, not a one-time onboarding task.

Q: How does network telemetry help find unsanctioned AI use?

A: Network telemetry helps find unsanctioned AI use by showing connections to known AI services, unusual DNS lookups, web traffic to browser-based chat tools, and data uploads to unfamiliar endpoints. Security teams can correlate that traffic with user identity, device posture, proxy logs, and API calls to spot shadow AI, exfiltration, and policy violations.

Q: Where does SaaS governance stop covering shadow AI?

A: SaaS governance stops at the corporate identity boundary, where control over sanctioned tenant access, app approvals, and account provisioning ends. Shadow AI begins when employees use external AI tools through personal accounts, unmanaged devices, or unsanctioned browser sessions outside SSO, CASB, and access policy enforcement.

Technical breakdown

OAuth consent creates the first shadow AI access path

OAuth consent lets a user grant a third-party application access to data through delegated permissions rather than sharing a password. In AI and SaaS adoption, that means an employee can connect an assistant or productivity tool to mail, calendar, files or contacts in a few clicks. The security issue is persistence: once granted, permissions can outlive the original business need and remain active until someone reviews or revokes them. Consent phishing exploits the same mechanism by tricking users into approving access that looks legitimate. See the Shadow AI and AI Agent Discovery Guide. See the Shadow AI and AI Agent Discovery Guide.

Practical implication: Review and revoke third-party OAuth grants before focusing on app inventory counts alone.

Personal accounts bypass corporate identity visibility

When employees use personal accounts to reach AI services, the activity can sit outside Microsoft 365 or Google Workspace telemetry because no corporate identity was used. That removes the usual anchor for detection, policy enforcement and audit. The data path still exists, but the organisation sees only the result, not the sign-in event or the service-level permission trail. This is why shadow AI is not the same as shadow IT in older endpoint-centric models: the access can occur without an enterprise-managed authentication event to correlate.

Practical implication: Correlate browser, endpoint and SaaS usage to surface AI services reached through non-corporate identities.

Network-only AI usage demands cross-telemetry correlation

Some AI and SaaS services leave no identity-platform trace at all. The only evidence may be firewall or network connections from managed devices, blended into ordinary web traffic. That makes simple allow or deny controls insufficient because the service may never request a tenant permission and never authenticate through a corporate provider. Detection therefore depends on matching destination reputation, device context and user activity patterns across sources. Without that correlation, usage can look like routine browsing even when the application handles sensitive information.

Practical implication: Baseline AI destinations in network logs and tie them back to device and user context before approving them.

Threat narrative

Attacker objective: The objective is to obtain access to corporate data through a trusted user action or unmanaged service path while avoiding normal governance controls.

1. Entry occurs when an employee authorises a third-party AI or SaaS application through OAuth consent, uses a personal account, or reaches the service from a managed device without corporate authentication.
2. Credential or access abuse follows when the application gains delegated permission to mail, files, calendars or other business data, or when the service begins handling sensitive uploads outside enterprise oversight.
3. Impact emerges as unapproved data exposure, policy violations or audit failure, because the organisation did not know which service had access or how far the access extended.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• OmniGPT breach claim 2025: A hacker claims to have leaked 34 million OmniGPT AI chat messages holding users' API keys and credentials; OmniGPT has not confirmed it.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow AI is now an access governance problem, not just an application inventory problem. The article shows that employees can bring AI services into the environment through multiple on-ramps, and each one leaves different evidence. That changes the discipline from counting tools to governing how data, identity and consent intersect. Practitioners should treat discovery as the entry point to control, not the end state.

Consent-based access creates a standing permission problem that identity teams often underestimate. Once a user grants an application access to company resources, the permission can persist long after the business need disappears. That is a governance assumption failure, because the control model expects someone to notice and review the grant in time. Teams need to think in terms of delegated access lifecycle, not one-time approval.

Personal-account adoption is the clearest sign that traditional SaaS governance stops at the tenant boundary. If employees can process business information outside corporate identities, the organisation loses visibility into both data handling and policy compliance. That makes Shadow AI a boundary problem between identity governance, data security and acceptable use enforcement. Security leaders should align monitoring with where work actually happens, not where policy assumes it happens.

Network-only visibility exposes a broader shadow AI visibility gap that many programmes are not built to close. The article makes clear that some AI use will never appear in identity logs or SaaS permission trails. That means governance must correlate endpoint, firewall and identity evidence before risk decisions can be made. The practical consequence is straightforward: if telemetry stays siloed, so does the risk.

From our research library:

• One in five organisations reported a breach due to shadow AI, and 97% of those breached through an AI model or application lacked proper AI access controls, according to IBM's 2025 Cost of a Data Breach Report.

What this signals

Shadow AI discovery will increasingly behave like an identity and data correlation problem. Security teams will need to stitch together consent logs, personal-account usage and network telemetry before they can decide whether a tool is sanctioned or simply visible in one place. Over time, the programme challenge will shift from discovery alone to governed response, where access is removed as soon as the data path looks unsafe.

Continuous visibility beats one-time inventory. A static list of approved AI apps cannot keep pace with employees who adopt new services in minutes and bind them to corporate data with a few clicks. The practical direction is toward monitoring that can explain both the app and the access path, so policy decisions are based on current usage rather than stale approvals.

Shadow AI visibility gap: the organisation that cannot connect identity, device and network evidence will keep mistaking unsanctioned AI use for ordinary web activity. That gap matters most when the service never appears in tenant logs but still processes business information, because response then starts after exposure rather than before it.

For practitioners

• Establish a shadow AI discovery baseline Correlate OAuth grants, SaaS app lists, browser activity and network destinations to identify AI services that already exist in the environment.
• Review and revoke high-risk consent grants Prioritise applications with access to email, files, calendars or contacts, then remove permissions that no longer match a documented business need.
• Separate personal-account AI use from approved workflows Define where business data may be processed, then enforce those boundaries with policy, user guidance and monitoring that covers non-corporate sign-ins.
• Build a cross-telemetry review path Use network telemetry, identity logs and endpoint context together so AI usage that never touches the tenant still appears in governance workflows.

Key takeaways

• Shadow AI is not just a procurement or policy issue. It is an access governance problem created by fast adoption, delegated permissions and unmanaged data paths.
• The evidence is split across identity, endpoint and network telemetry, which means a single control source will miss at least part of the risk.
• Practitioners need correlation and rapid revocation, or unsanctioned AI use will remain invisible until it becomes a data exposure event.

Related NHI Mgmt Group resources: Shadow AI and AI Agent Discovery Guide · Insider Risk from AI Tools Guide · Attack Surface Management Guide · Vercel Context.ai OAuth Supply Chain Breach

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.
• Consent Phishing: A social engineering attack that persuades a user to approve a malicious OAuth application. The attacker gains delegated access through legitimate authorization rather than stealing a password, which makes the resulting token-based access harder to detect and revoke than a normal sign-in compromise.
• SaaS: Software as a service is a delivery model where the vendor hosts and operates the application, and customers access it over the internet. It reduces the buyer’s operational burden and upfront infrastructure work, but usually gives the vendor more control over the runtime environment, release cadence, and service experience.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management and workload identity. It is designed for practitioners who need to connect identity controls to modern access paths across cloud and AI use cases.