Vercel oauth breach exposes the hidden risk of shadow AI

At a glance

What this is: This analysis shows how a single shadow AI OAuth integration in Google Workspace became a path to Vercel secrets, source code and customer data after the connected third party was compromised.

Why it matters: It matters because IAM and IGA teams must govern OAuth grants, app offboarding and third-party access as first-class identity risks across both enterprise SaaS and shadow AI.

By the numbers:

• On average, Push Security sees 17 unique AI app integrations per organization in Microsoft and Google alone.
• Push Security reports that 1 in 4 of the last million logins were password logins, 2 in 5 were not protected by MFA, and 1 in 5 used a weak, breached, or reused password.
• Push Security says 54% of ransomware attacks traced back to infostealer-enabled credential theft in the 2025 Verizon DBIR.

Context

An OAuth grant can silently turn a routine SaaS trial into persistent enterprise access, especially when users connect external apps to core collaboration tenants without admin review. In this case, the primary identity problem is not the application itself but the ungoverned third-party trust created inside Google Workspace, where one integration expanded the attack surface far beyond its original purpose.

Shadow AI matters here because it behaves like shadow SaaS with added integration density, not because every AI app is inherently malicious. When a user authorises an external app and that app is later compromised, the downstream risk lands on the enterprise tenant, the connected identities, and the data shared through those permissions.

Key questions

Q: What breaks when users are allowed to approve OAuth apps freely?

A: When users can approve OAuth applications without tight governance, a single click can create long-lived delegated access to mail, files, chat, and APIs. The failure is not sign-in protection but consent control. Security teams lose visibility into which apps were trusted, which scopes were granted, and how far the token can reach.

Q: Why do third-party OAuth integrations create such a large attack surface?

A: They extend trust beyond the primary platform into every downstream system the app can touch. If the integration can read or write code, tokens, or deployment data, a compromise of the supplier or app can turn into access across multiple environments. The risk grows when approvals are developer-driven and never revalidated against current business need.

Q: What are the signs that OAuth consent governance is failing?

A: Common signs include broad scopes granted to unfamiliar applications, app registrations that survive beyond their business purpose, and consent events that are logged but not acted on. If reviewers only see the abuse in hindsight, governance is too slow for the risk level. The control needs policy, not just audit trails.

Q: How should security teams respond when a third-party OAuth app is compromised?

A: Treat the app as a trusted identity path and assume the attacker may have reached downstream systems through delegated access. Revoke suspicious consent, review scopes, check audit logs, and rotate any secrets that the app or linked user could access. The goal is to cut off both persistence and secret reuse before the compromise spreads.

Technical breakdown

How OAuth sprawl expands the attack surface

OAuth is an authorisation framework, not a password replacement. When a user consents to an app, the app receives delegated access scoped to that user, but the effective blast radius often includes shared drives, collaborative documents, inbox-linked workflows and any data exposed through that identity. In practice, a well-permissioned user can become a high-impact conduit to internal systems if the tenant allows self-service app grants and lacks routine app review. The risk is amplified when the app is forgotten after a trial, because the grant remains active even when business need has vanished.

Practical implication: treat OAuth grants as governed access paths, not convenience features, and review them with the same discipline as privileged accounts.

Why compromised third-party apps become tenant compromise paths

A third-party SaaS integration inherits trust from both sides of the connection. If the external app is compromised, the attacker can often reuse its stored OAuth tokens or connected sessions to move into the enterprise tenant, then pivot to the user’s accessible data and adjacent services. In this case, the integration was connected to Google Workspace and the token exposure extended into downstream accounts and high-value secrets. The technical failure is not just token theft. It is the absence of containment between the third-party app’s security posture and the enterprise identities it can act through.

Practical implication: isolate third-party integrations from sensitive data domains and require explicit lifecycle review before any app keeps tenant-level access.

Why shadow AI is an identity governance problem

Shadow AI is often discussed as a content or data leakage issue, but the deeper problem is identity delegation without governance. When employees connect consumer or trial AI tools to enterprise SaaS, they create hidden trust chains that are hard to inventory, harder to revoke, and easy to underestimate. The article’s Vercel example shows that a deprecated app can remain a live identity bridge long after the original use case has ended. That makes app offboarding, grant inventory and admin-controlled consent the real control points, not user awareness alone.

Practical implication: inventory AI-related OAuth integrations continuously and remove any app that lacks a clear owner, business purpose or revocation path.

Threat narrative

Attacker objective: The attacker sought high-value tenant access and secrets that could be monetised through extortion and further downstream abuse.

1. Entry occurred when a Vercel employee connected a third-party AI app into Google Workspace, creating a live OAuth trust relationship into the tenant.
2. Credential access followed when the third-party app was compromised and the attacker reused stored OAuth tokens to access downstream accounts and sensitive data.
3. Impact came from exfiltration of employee records, API keys, NPM tokens, GitHub tokens and other secrets, followed by ransom pressure on Vercel.

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.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 becomes an identity governance problem the moment it inherits enterprise trust: The article is not really about an AI app, it is about a delegated access path that escaped governance. Once an external app is allowed into a core tenant, its security posture becomes part of the enterprise identity perimeter. Practitioners need to treat every self-adopted integration as an identity object with ownership, approval and revocation requirements, not as a shadow productivity tool.

Default-deny OAuth consent is the right control boundary because user intent is not the same as business approval: A user can authorise an app without understanding the tenant-wide blast radius of the resulting grant. That is especially dangerous when shared documents, internal dashboards or developer secrets are reachable through the same account. The governance lesson is that consent at the user layer cannot substitute for admin-level control over enterprise trust relationships.

Deprecated integrations create trust debt: The article shows how trial apps, consumer products and forgotten connections remain active after the business need has disappeared. That is not a one-off hygiene miss, it is a lifecycle failure in app governance. If an organisation cannot prove who owns an OAuth grant, why it exists and when it will be removed, the integration should be treated as unmanaged exposure.

Blast radius, not just app status, is the decisive metric: The danger is not whether the app is branded as AI or SaaS. The decisive question is how much authority the connected user already has and which collaborative resources the token can reach. That is why high-permission users and loosely separated workspaces can turn a single grant into data, code and secret exposure.

Supply chain trust for SaaS now extends to browser-visible app consent: The same governance logic that applies to third-party risk in procurement now applies inside the browser and the SaaS admin console. External app trust is no longer a back-office concern. It is part of identity perimeter design, and practitioners should assume that unmanaged consent will be exploited if the connected provider is ever compromised.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Shadow AI and shadow SaaS are converging: The issue is not simply that employees try new tools, it is that those tools increasingly arrive with OAuth links into core tenants and shared data. That means app consent, not just app inventory, is now a governance control point for IAM, IGA and SaaS security teams.

OAuth consent is becoming a latent blast-radius multiplier: Once an app sits inside Google Workspace or a similar tenant, the relevant question is how much of the user’s effective reach the grant can inherit. A single integration can expose more than a personal mailbox if the user already has access to shared drives, internal dashboards or developer secrets.

App offboarding needs lifecycle discipline, not just blocking new installs: Forgotten integrations are the long tail of this risk. Teams should make every connected app prove continued business purpose, because the control failure is not the original approval alone but the failure to remove it when the trial, pilot or side project ends.

For practitioners

• Enforce admin approval for new OAuth grants Disable self-service consent for new enterprise integrations in core tenants and require explicit admin review before any external app can access user data or shared resources.
• Audit existing OAuth integrations for ownership and necessity Inventory every connected app, confirm a business owner for each grant, and remove deprecated integrations that no longer have a current use case or active review.
• Separate high-value identities from routine collaboration accounts Limit which users can expose secrets, dashboards, tokens and internal tooling through collaborative SaaS accounts, especially where a single grant could span sensitive systems.
• Review AI app and browser extension exposure together Treat AI SaaS integrations, browser extensions and consented OAuth apps as one attack surface so that unmanaged trials do not become hidden persistence paths.
• Rotate exposed secrets and revoke suspect grants after compromise If a connected app is suspected of compromise, revoke the OAuth grant, rotate any credentials the account could reach, and verify that no downstream tokens remain valid.

Key takeaways

• Shadow AI becomes a governance issue when an external app is allowed to inherit enterprise trust through OAuth and then remain connected after the original business need has passed.
• The breach illustrates how one granted integration can expose secrets, source code and customer data when the connected third party is compromised.
• Default-deny consent, continuous app review and timely revocation are the controls that change the outcome, because they reduce the blast radius before a compromise can spread.

Key terms

• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• 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 Sprawl: OAuth sprawl is the accumulation of many third-party applications, grants, and token relationships that no team can fully track. It creates hidden access paths, stale permissions, and ownership ambiguity, which is why inventory and lifecycle control matter as much as initial approval.
• Trust Boundary: A trust boundary is the point where one system’s authority should stop and another system’s authority should begin. For internal automation, weak trust boundaries let monitoring, remediation, and execution share privileges that should have remained separate.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.