Vercel breach shows SaaS supply chain risk is now identity risk

At a glance

What this is: This analysis shows how a compromised third-party SaaS integration can turn a valid OAuth token into downstream access across enterprise systems.

Why it matters: It matters because IAM teams need to govern connected applications as part of NHI risk, not treat them as low-friction productivity add-ons.

👉 Read Obsidian Security's analysis of the Vercel breach and SaaS supply chain risk

Context

A SaaS supply chain breach occurs when trusted third-party software becomes the path into an enterprise environment through inherited access. In this case, the security gap was not a password reset failure or a direct platform intrusion, but the unmanaged trust created when an employee connected a third-party AI tool to corporate Google accounts and granted persistent OAuth access.

For IAM and NHI practitioners, the central problem is transitive trust. Once an OAuth token exists, it behaves like a legitimate identity across connected systems, which makes discovery, revocation, and blast-radius analysis far harder than with a single user account. The pattern is increasingly typical in modern SaaS environments, especially where shadow AI and unapproved integrations expand faster than governance controls.

Key questions

Q: How should security teams govern OAuth-connected SaaS integrations as NHIs?

A: Treat each connected application as a non-human identity with an owner, scope, lifecycle, and revocation path. Review what data it can reach, how long its access persists, and whether the connection still serves a current business purpose. If an integration cannot be mapped and monitored, it should not remain trusted.

Q: What is the difference between direct account compromise and SaaS supply chain compromise?

A: Direct account compromise targets the user or service account itself, usually through password theft or session hijacking. SaaS supply chain compromise starts with a trusted third-party integration and then reuses valid delegated access to move into enterprise systems. The second model is harder to detect because the token often looks legitimate.

Q: Why do OAuth tokens create hidden risk in enterprise environments?

A: OAuth tokens can operate quietly in the background after consent, which means they often bypass login alerts and MFA prompts. They also inherit whatever permissions the original approval granted, so one token can expose mail, documents, code repositories, or downstream SaaS tools if the scope is broad enough.

Q: When should teams revoke a third-party SaaS integration?

A: Revoke it when the app no longer has a clear business owner, when its permissions exceed the use case, when it was added outside approved governance, or when its behaviour changes in ways you cannot explain. If you cannot justify the access continuously, the safest answer is to remove it.

Technical breakdown

How OAuth-connected SaaS apps become non-human identities

OAuth integrations behave like delegated non-human identities because they carry standing permissions after initial consent. In practice, the app receives a token that can access specific SaaS resources without prompting for a password or MFA again. That token may be stored by the third-party service, reused across backend workflows, and inherited by downstream systems that assume the original authorization remains trustworthy. The main technical failure is not token issuance itself, but the absence of continuous validation, scoped privilege, and lifecycle control once the integration is live.

Practical implication: Inventory OAuth-connected apps as NHI assets and review them with the same rigor as service accounts and API keys.

Why transitive trust expands the blast radius

Transitive trust means one authorization can create multiple layers of downstream exposure. When an employee authorizes a third-party app, they are also trusting that app’s cloud environment, internal access controls, developers, and any connected services that store tokens or metadata. If any one of those layers is compromised, the attacker can often reuse valid credentials that still look normal to the receiving SaaS platform. This is why incident scope is slow to reconstruct and why access from a legitimate token can bypass many anomaly detectors.

Practical implication: Map every connected app to the data and systems it can reach before an incident forces you to reconstruct it manually.

Why behavioral baselines matter for token abuse detection

A hijacked OAuth token often avoids classic authentication alerts because it is still technically valid. Detection therefore shifts to behaviour: where the integration connects from, what it accesses, how often it acts, and whether that pattern changes suddenly. This is especially important for AI tools and other shadow integrations that may generate background activity across Google Workspace, GitHub, Slack, and similar services. If the normal pattern is never defined, compromise becomes visible only after data movement starts.

Practical implication: Baseline each integration’s normal access patterns and alert on deviations from expected source, volume, and target systems.

Threat narrative

Attacker objective: The attacker aimed to steal sensitive SaaS data and use the compromised environment as a launch point for additional breaches.

1. Entry occurred through a third-party AI tool connected to a corporate Google account with persistent OAuth access.
2. Credential harvesting followed when the attacker gained access to the third-party tool’s AWS environment and found stored OAuth tokens.
3. Escalation happened when the stolen token was reused to access Vercel systems and move laterally into credentials, API keys, and source code.

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

Transitive trust is the real NHI risk in SaaS supply chains. The breach did not begin with a broken password but with an over-extended authorization chain that linked an employee account to a third-party tool and then to downstream systems. That is a governance problem, not just an incident response problem. IAM teams need to treat delegated app access as an NHI class with its own inventory, risk review, and revocation rules.

Shadow AI expands the attack surface faster than current access governance can absorb. The article’s scenario is a warning that unmanaged AI tools can inherit standing access before security teams even know they exist. That makes discovery and approval workflows insufficient on their own. Practitioners need continuous visibility into who connected what, what that integration can reach, and whether the access is still justified.

Ephemeral authentication alone does not solve persistent trust debt. Even when tokens are valid for only part of the workflow, the surrounding authorization chain can remain open long enough to support theft and lateral movement. The control objective is not only shortening token lifetime but reducing the number of places a token can be stored, reused, or silently inherited. The practical answer is stricter lifecycle governance for every delegated identity.

Blast-radius clarity is becoming a core security requirement, not an investigation luxury. In SaaS environments, the first question is no longer whether an integration was compromised, but what it could reach before detection. That shifts the control model from point-in-time approval to continuous entitlement mapping and behavioral monitoring. Security teams that cannot answer blast radius quickly will keep losing time after the fact.

From our research:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and those incidents are 13% more likely to be categorised as critical than code-based leaks.
• The right next step is to compare this SaaS exposure pattern with 52 NHI Breaches Analysis and use it to pressure-test your delegated-access review process.

What this signals

Transitive access is now a governance category, not just an implementation detail. As more business workflows depend on connected SaaS tools, the security question shifts from who logged in to what the integration can reach on the user’s behalf. For practitioners, that means building control points around app ownership, consent, and revocation rather than assuming platform-level authentication is enough. The OWASP Non-Human Identity Top 10 is a useful lens for classifying this risk.

Ephemeral tokens do not eliminate blast radius when storage and reuse paths remain open. Once a token is copied into a third-party environment, the surrounding control failure becomes more important than token age alone. The programme implication is straightforward: if an integration can store secrets, reach core SaaS systems, and operate without behavioural monitoring, it belongs in the highest-risk review queue.

With 64% of valid secrets leaked in 2022 still valid and exploitable today, according to The State of Secrets Sprawl 2026, revocation discipline matters more than detection alone. That figure should push teams to treat connected apps and tokens as lifecycle assets with explicit offboarding, not static approvals. In practice, your next incident may be prevented by a clean removal process, not a faster alert.

For practitioners

• Inventory all third-party OAuth grants Build a current list of every app connected to core SaaS accounts, including shadow integrations that employees added without IT approval. Flag any app with write access, admin scope, or access to source code and secrets repositories.
• Revoke standing access for high-risk integrations Remove persistent tokens where the business use case does not require continuous access. Require time-bound reauthorization for integrations that can reach Google Workspace, GitHub, Slack, or other crown-jewel systems.
• Baseline normal integration behaviour Record where each integration normally connects from, what it reads or writes, and how often it acts. Alert on unusual IP ranges, new geographies, sudden data access, or changes in request volume that could indicate token abuse.
• Tie OAuth review into NHI governance Include OAuth-connected apps in NHI lifecycle reviews alongside service accounts, API keys, and certificates. Use the same approval, ownership, rotation, and offboarding discipline so third-party access cannot persist unchecked.

Key takeaways

• The Vercel incident shows that a trusted third-party integration can behave like a fully valid identity inside enterprise systems.
• OAuth token abuse is difficult to detect because the access is legitimate at the protocol layer even when the actor is not.
• Security teams need continuous inventory, behaviour baselining, and lifecycle revocation for connected apps before the next incident forces the review.

Key terms

• OAuth-connected NHI: A non-human identity created when a third-party application is granted OAuth access to enterprise systems. It is not a person, but it can act with delegated authority, persist over time, and reach sensitive data if the scope is broad or the integration is poorly governed.
• Transitive trust: The hidden risk created when one trusted app inherits confidence from another trusted relationship. In SaaS environments, approving a third-party tool means trusting its hosting, storage, developers, and connected services, which widens the attack surface beyond the original login event.
• Blast radius: The amount of data, systems, and accounts an attacker can reach after compromising one identity or integration. In NHI governance, blast radius is the practical measure of how far a token, key, or certificate can move before it is revoked or contained.
• Shadow AI: An AI tool or agent that has been introduced into the environment without security visibility or formal approval. Shadow AI often becomes risky because it inherits access through user consent, stores secrets, or operates across SaaS systems that were never reviewed as part of IAM governance.

Deepen your knowledge

OAuth-connected SaaS integrations and shadow AI are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is building governance around delegated access and token risk, the course provides a practical starting point.

This post draws on content published by Obsidian Security: The Vercel Breach and the Growing SaaS Supply Chain Challenge. Read the original.