Vercel breach shows SaaS supply chain risk is now identity risk

At a glance

What this is: This is an analysis of the Vercel breach in which a compromised third-party app and a valid OAuth token enabled unauthorized access, API key theft, and source code exfiltration.

Why it matters: It matters because SaaS integrations now create standing identity trust across core systems, so IAM, IGA, and incident response teams need visibility into third-party access, token scope, and downstream blast radius.

Context

SaaS supply chain risk becomes an identity problem when a third-party app inherits legitimate access into core enterprise systems. In this case, the control failure was not a password reset or a broken perimeter, but an OAuth grant that outlived the organisation's awareness of who could touch it.

The Vercel incident shows how connected applications extend trust transitively across Google Workspace, GitHub, Slack, and similar environments. Once a token is issued, downstream systems treat it as a valid identity, which makes exposure hard to notice and harder to scope once abuse begins.

Key questions

Q: What breaks when a third-party OAuth app is compromised?

A: A compromised OAuth app inherits whatever delegated scopes users already approved, so the attacker can act through legitimate tokens instead of noisy intrusion methods. That breaks the assumption that user consent remains trustworthy after the app's security posture changes. The practical result is broader access to mail, documents, directories, and other linked systems until the grant is revoked.

Q: Why do compromised SaaS integration tokens create such a large downstream risk for identity and data access?

A: Compromised integration tokens are dangerous because they inherit trust from the connected application and can bypass normal user interaction. If an attacker obtains OAuth or refresh tokens, they may query data, access email, and harvest additional credentials without triggering obvious login failures. The risk compounds when the integration is broadly scoped and connected to multiple business systems.

Q: How should teams find shadow OAuth grants before an incident?

A: Start with a complete third-party app inventory across core identity and collaboration platforms, then compare it to approved business owners and expected scopes. Any app that is unknown, over-scoped, or outside policy should be treated as a governance gap, not just an app issue.

Q: When should organisations automate SaaS access revocation?

A: Organisations should automate SaaS access revocation whenever access is tied to a task, workflow, vendor relationship, or temporary project. If a connector, share, or account no longer has a business purpose, waiting for a manual review leaves unnecessary exposure in place. Automation is most valuable where permissions change faster than humans can track them.

Technical breakdown

How OAuth tokens become standing SaaS identities

OAuth access tokens and grants are not just session artefacts. In SaaS environments they can behave like durable delegated identities, especially when third-party apps are granted broad scopes and are allowed to run without IT oversight. If the token is stored persistently, reused across systems, or tied to privileged workflows, compromise of the upstream app becomes compromise of everything the token can reach. The risk is amplified when the app is connected from employee-managed accounts rather than centrally governed service principals.

Practical implication: Treat OAuth grants as governed identities with ownership, scope limits, and revocation triggers.

Why trust chains make blast radius harder to see

A SaaS trust chain extends beyond the app a user directly authorises. It includes the app vendor, the vendor's cloud environment, their own connected services, and any credentials or tokens stored there. In the Vercel case, the attacker gained access through a compromised third-party tool, then leveraged a valid token to move into downstream systems without triggering the usual authentication alarms. That is why conventional login-based monitoring often misses the earliest stage of abuse.

Practical implication: Map third-party connections to downstream systems before an incident forces manual reconstruction.

How legitimate tokens enable lateral movement

Once a token is accepted as legitimate, defenders lose many of the cues that normally signal intrusion. There is no password spray, no MFA challenge, and often no obvious new device event. If the token was granted broad permissions, the attacker can pivot from one connected service to another, collecting credentials, API keys, and source code along the way. This is not classic perimeter intrusion. It is identity-assisted lateral movement through approved trust relationships.

Practical implication: Baseline normal integration behaviour so token misuse can be spotted as a deviation rather than a login failure.

Threat narrative

Attacker objective: The attacker sought to turn delegated SaaS trust into durable access for theft, resale, and follow-on intrusion.

1. Entry occurred when a Vercel employee connected a third-party AI tool to a corporate Google account, creating a persistent OAuth grant with standing access.
2. Credential access followed when the third-party tool was compromised and attackers recovered a valid token from its AWS environment.
3. Escalation and lateral movement happened when that token was used to enter Vercel systems and move through connected services.
4. Impact was the theft of customer API keys and proprietary source code, with the data later advertised on a criminal forum.

Breaches seen in the wild

• BeyondTrust breach 2024: A stolen BeyondTrust Remote Support API key let a China state-sponsored actor reset accounts and reach US Treasury workstations in 2024.
• Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.

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

Delegated SaaS trust is now an identity perimeter: The Vercel case shows that the real boundary is no longer the corporate login screen, but the set of third-party grants attached to core accounts. Those grants behave like non-human identities with persistent reach, even when no one treats them that way operationally. The implication is that identity governance has to extend to every connected app, not just human users and formal service accounts.

OAuth approval without governance creates trust debt: A grant made for convenience can persist long after the original business context changes. That assumption was designed for controlled, visible integrations, but it fails when employees connect tools outside IT oversight and the connected vendor can itself be compromised. The implication is that SaaS authorisation now needs lifecycle ownership, not just initial consent.

Shadow integrations expand the attack surface faster than reviews can track: The article's core lesson is that organisations rarely know the full inventory of connected apps, what scopes they hold, or which downstream systems they can reach. That turns blast-radius analysis into an after-the-fact reconstruction exercise. Practitioners should treat unmanaged OAuth grants as an inventory and governance gap, not only a threat-detection problem.

Identity risk is now supply chain risk: This breach is not an isolated platform event. It illustrates a pattern in which third-party compromise becomes the delivery mechanism for privileged access into enterprise SaaS, with the token serving as the trust bridge. That means SaaS supply chain assurance must be evaluated through identity controls, offboarding discipline, and token visibility, not solely through vendor security questionnaires.

Blast-radius control is the decisive control plane: Once a connected app is compromised, the question is no longer whether access exists, but how far that access can travel and how quickly it can be revoked. That is a governance problem spanning IAM, IGA, and PAM-style accountability for delegated access. Practitioners should prioritise reach mapping over passive inventory counts because reach determines real exposure.

From our research library:

• The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Shadow OAuth grants are now a core identity governance problem: Security teams need to treat every connected SaaS app as an identity-bearing integration, not a convenience feature. The control question is no longer whether the app works, but what it can reach and who owns its revocation.

Blast-radius mapping has to replace static app inventories: Knowing that a third-party tool is connected is not enough. Practitioners need to know which identities it touches, which systems it can reach, and how quickly those permissions can be removed when compromise is suspected, according to the Ultimate Guide to NHIs.

For practitioners

• Inventory every OAuth grant Pull a full list of third-party applications connected to corporate accounts, including tools employees approved outside IT workflows. Record scopes, owning business units, and the downstream systems each grant can reach.
• Revoke unknown or unnecessary integrations Remove any integration that no longer has a current business owner or that requests write access to core systems without a documented need.
• Rotate credentials tied to connected workflows Review API keys, secrets, and service credentials used by SaaS-connected workflows, especially where a compromised integration could have exposed them.
• Baseline normal integration behaviour Establish expected source IPs, access frequency, and target systems for each OAuth-connected app so deviations can be investigated as possible token misuse.
• Define revocation triggers for third-party access Set clear conditions for revoking OAuth grants when a vendor, integration, or connected account shows compromise, unapproved scope expansion, or unexplained behaviour.

Key takeaways

• This breach shows that a valid OAuth token can act as a trusted identity path even when the upstream app has been compromised.
• The practical risk is not only initial access but the ability to move through SaaS-connected systems and extract high-value assets.
• Governance teams need visibility into who owns third-party grants, what those grants can reach, and how quickly they can be revoked.

Key terms

• SaaS Supply Chain: A SaaS supply chain is the network of third-party applications, integrations, and delegated permissions that connect cloud services to each other. It creates operational efficiency, but it also creates inherited trust paths where a compromise in one system can quickly affect many others.
• 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 Integration: A shadow integration is an undocumented or unmanaged connection between applications that operates outside central governance. These integrations often appear when business teams configure webhooks directly, leaving security teams without clear ownership, data-flow visibility, or retirement controls.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

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.