Vercel oauth breach exposes the hidden risk of shadow AI

At a glance

What this is: A Vercel breach linked to a compromised AI SaaS OAuth integration exposed how shadow integrations can turn one connected app into a broad identity and secrets risk.

Why it matters: It matters because IAM, NHI, and workplace identity teams must treat OAuth app consent, offboarding, and secret exposure as a shared governance control plane.

By the numbers:

• On average we see 17 unique AI app integrations per organization in Microsoft and Google alone.
• The 2025 Verizon DBIR reported that 54% of all ransomware attacks traced back to infostealer-enabled credential theft.
• 46% of systems with compromised corporate credentials were non-managed devices.

👉 Read Push Security's analysis of the Vercel OAuth breach and shadow AI exposure

Context

OAuth-connected apps create a second identity plane inside enterprise SaaS, where a single approved user can expose far more than their own mailbox or files. In this case, the governance failure was not only stolen access, but the presence of an unmanaged integration in Google Workspace that retained downstream reach after its original purpose had faded.

Shadow AI is often discussed as an application risk, but the real security issue is shadow integration sprawl. When employees connect external apps to core tenants without lifecycle controls, the organisation loses sight of who can access what, which tokens still exist, and which third-party privileges have quietly become persistent.

Key questions

Q: How should security teams handle OAuth app consent in enterprise tenants?

A: Security teams should move to default-deny consent for new OAuth apps in core tenants, then approve only integrations with a clear business owner, scoped use case, and revocation path. The important test is not whether the app is popular, but whether its live privileges are still needed and observable across the tenant.

Q: Why do shadow integrations create more risk than ordinary shadow IT?

A: Shadow integrations extend access into the apps that already hold enterprise data, so one forgotten connection can become a long-lived trust path into mail, files, dashboards, or code systems. The risk is amplified when the user who created the grant is also the person with broad internal access, because the integration inherits that reach.

Q: What do security teams get wrong about AI app governance?

A: They often focus on the app itself and ignore the connectors. AI apps are dangerous when they can chain into multiple systems through OAuth, because the integration becomes the attack surface. Teams need to govern the permissions, owners, and revocation of each live connection, not just the app catalogue entry.

Q: Who is accountable when a third-party integration exposes corporate secrets?

A: Accountability is shared, but the enterprise owns the governance failure if it allowed the integration to persist without review. Frameworks such as the OWASP Non-Human Identity Top 10 and Zero Trust Architecture both point to the same expectation: access paths must be continuously verified, bounded, and removable.

Technical breakdown

OAuth consent and downstream scope in SaaS tenants

OAuth does not usually grant a blanket tenant takeover at the moment of consent, but it can inherit the full practical power of the consenting user inside collaborative systems. That means shared drives, shared documents, calendars, and internal tools can become reachable through one app grant if the user is well-permissioned. In hybrid SaaS estates, the effective blast radius is defined by user privilege hygiene, tenant configuration, and how broadly the connected app can reuse the token across services.

Practical implication: restrict user-driven OAuth consent and review the real downstream reach of every integration, not just the requested scope string.

Shadow AI, shadow integrations, and OAuth sprawl

Shadow AI is not only about unapproved chatbots. The larger risk comes from shadow integrations, where a legitimate or trial app is connected into enterprise systems and then forgotten. AI apps are especially prone to this because they are designed to chain services together, often via OAuth, to move data between tools. Every new connector widens the attack surface and increases the number of third-party trust relationships that must be governed as identities, not just applications.

Practical implication: inventory AI app connections separately from app installs, because integrations can outlive the original user trial and remain privileged long after use stops.

Infostealers, session tokens, and device trust collapse

Infostealers remain effective because they target the device and browser session rather than trying to defeat authentication in real time. Once an attacker captures credentials or session tokens, they can replay access and bypass controls that assume the login event was trustworthy. The article also points to non-managed or personal devices as a likely weak point, which matters because browser sync, local token storage, and weaker endpoint posture can collapse enterprise boundaries without any new password being cracked.

Practical implication: treat unmanaged and developer devices as first-class identity risk sources, and monitor for token replay paths that bypass normal sign-in protections.

Threat narrative

Attacker objective: The objective was to convert one compromised integration into broad access to secrets, source code, and customer-relevant cloud data for ransom and follow-on abuse.

1. Entry began when a compromised third-party AI SaaS provider exposed OAuth tokens that were already trusted inside the Google Workspace tenant.
2. Credential access and abuse followed through stored OAuth grants in the third party’s platform, which let the attacker move into a Vercel employee account with high-value access.
3. Impact came when the attacker exfiltrated internal dashboards, employee records, API keys, NPM tokens, and GitHub tokens, then attempted extortion with the stolen material.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shadow integrations have become a standing identity risk, not a side effect of SaaS adoption. This breach worked because an approved user-driven integration retained reach inside a core tenant after the business purpose had weakened. OAuth grants now need the same lifecycle scrutiny as service accounts and API keys, because the trust relationship survives long after the employee who created it forgets the app exists. Practitioners should treat every unreviewed integration as a latent access path.

OAuth consent without admin approval creates an identity governance blind spot that most programmes still underestimate. The problem is not simply user error. The problem is that a self-service consent model can create privileged third-party reach into shared drives, dashboards, and secrets with no separate approval checkpoint. That is a control gap, but it is also a governance assumption failure: the tenant assumes the user can safely decide which external app should join the enterprise trust fabric. The practical conclusion is that consent must be governed as an access decision, not a convenience setting.

Shadow AI accelerates the same old SaaS risk, but with more connectors and faster privilege accumulation. AI applications are increasingly designed to chain data sources, which means one trusted integration can quickly become a multi-system access path. The named concept here is integration blast radius: the total reachable data and action surface created when one app token is allowed to traverse multiple enterprise services. Teams should assess integrations by reachable impact, not by the popularity or intent of the app itself.

Unmanaged and personal devices remain a major multiplier in OAuth-based compromise. The breach narrative points to device hygiene, browser sync, and token persistence as key enablers once the attacker had a foothold. This is why SaaS identity governance cannot stop at the cloud tenant boundary. If the endpoint is not trusted, the token is not trusted, and if the token is not trusted, the integration is not truly governed.

The Vercel case validates the need to govern third-party connections as part of NHI and SaaS identity strategy. Push Security’s analysis fits the broader NHI pattern: the most damaging access paths are often the ones nobody intended to become permanent. Security teams should stop asking whether an app is approved and start asking whether its live trust chain is still justified, observable, and revocable.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• Forward pivot: The same governance gap shows up in breach cases where third-party access outlives oversight, as analysed in The 52 NHI Breaches Report.

What this signals

Integration blast radius is the right lens for AI-era SaaS governance: the question is no longer whether an app is approved, but how far its OAuth reach can travel once connected. That is why the control surface must include consent, offboarding, and browser-level visibility across both managed and unmanaged endpoints.

The programme signal is clear. As AI apps become more interconnectable, the enterprise will need to govern app-to-app trust with the same discipline used for service accounts and workload identities. Teams that still treat OAuth as a convenience feature will keep discovering that the real breach path was an ordinary integration nobody re-reviewed.

Security leaders should expect more breach chains that begin with a benign trial, a forgotten connector, or a compromised third-party tenant. The practical response is to centralise review of live integrations, link it to identity lifecycle controls, and map recurring patterns against the OWASP Non-Human Identity Top 10.

For practitioners

• Default-deny new OAuth grants Block end-user approval of new OAuth integrations in core tenants unless an administrator explicitly reviews the request and the requested scopes.
• Audit existing integrations for stale trust Review connected apps on a scheduled basis, confirm business ownership, and remove integrations that no longer have a current operational need.
• Treat AI apps as integration sprawl risks Inventory AI tools separately from general SaaS because their connector patterns can expand access across mail, docs, storage, and workflow systems.
• Harden the accounts that can expose secrets Limit who can read environment variables, token stores, dashboards, and connected repositories so one compromised user cannot dump the crown jewels.
• Remove trust from unmanaged and BYOD endpoints Require stronger endpoint posture for browsers that hold corporate sessions, and investigate browser sync and token persistence on non-managed devices.

Key takeaways

• The breach showed that one compromised OAuth integration can expose secrets, customer data, and internal systems when governance is weak.
• The scale of the problem is growing because AI apps and SaaS workflows add more connectors, more trust paths, and more forgotten grants.
• Teams need to govern OAuth consent, integration lifecycle, and device trust as a single identity problem, not three separate ones.

Key terms

• OAuth Integration: An OAuth integration is a delegated trust relationship between an application and a user account or tenant. In practice, it can grant a third-party app access to mail, files, APIs, and shared resources that extend far beyond the initial consent screen. Governance must treat it as a live identity binding.
• Shadow Integration: A shadow integration is a connected app, token, or delegated link that exists outside approved governance or has outlived its original business purpose. It often survives because nobody owns its review, revocation, or monitoring, which makes it a persistent access path rather than a temporary convenience.
• Integration Blast Radius: Integration blast radius is the total amount of data and action a single connected app can reach once OAuth permissions are combined with user privilege and collaborative sharing. It is wider than the scope text alone suggests, because real enterprise permissions, shared resources, and token reuse determine the effective impact.
• Shadow AI: Shadow AI is the use of AI applications, assistants, or connectors that have not been fully governed by the organisation. The risk is not only the model or prompt activity, but the untracked identity relationships, OAuth grants, and data paths those tools create inside enterprise systems.

Deepen your knowledge

OAuth consent governance and shadow integration control are core topics in the NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with SaaS sprawl or AI app connectors, it is worth exploring.

This post draws on content published by Push Security covering the Vercel OAuth breach: April 2026 compromise via a third-party AI SaaS OAuth integration. Read the original.