Vercel breach shows governed OAuth is now an NHI control point

At a glance

What this is: This analysis argues that the Vercel breach was an identity boundary failure, not a code vulnerability, and shows how a compromised third-party OAuth connection can expose internal systems and secrets.

Why it matters: IAM and NHI teams need to treat OAuth-connected apps as governed identities because one weak integration can create broad blast radius across the software supply chain.

👉 Read Curity's analysis of the Vercel breach and governed OAuth

Context

An OAuth-connected application can become an identity bridge into internal systems when trust is granted too broadly. That makes governed OAuth a non-human identity problem as much as an access management problem, because the token, scope, and runtime context determine whether a third-party app can move from convenience to compromise. The Vercel breach is a useful example of how enterprise access assumptions fail once integrations are treated as trusted by default.

The article’s core claim is that the real weakness was not infrastructure but control failure around third-party access, token lifetime, and secret exposure. That is a typical pattern in modern software supply chains, where service-to-service trust and delegated access often outpace review. For IAM and NHI practitioners, the question is no longer whether OAuth is in use, but whether its governance is strong enough to contain compromise when an external app is taken over.

Key questions

Q: How should security teams govern third-party OAuth apps that reach internal systems?

A: Security teams should treat third-party OAuth apps as high-risk non-human identities. That means scoping permissions narrowly, reviewing consent regularly, shortening token lifetimes, and revoking access when the app is not actively needed. If the integration can reach internal systems or secret stores, it should be subject to runtime policy checks and owner accountability, not blanket trust.

Q: Why do delegated OAuth connections increase the risk of NHI compromise?

A: Delegated OAuth connections can outlive the original business need and carry more access than users realise. When the connected app is compromised, the attacker inherits the delegated authority, not just the app itself. That creates an NHI problem because the token becomes a reusable identity path into systems, often with enough privilege to expose credentials or move laterally.

Q: What breaks when organisations leave standing privilege in SaaS integrations?

A: Standing privilege turns a stolen or abused token into a long-lived access path. If the integration stays authorised after the task is complete, the attacker can keep using it until someone notices. That breaks containment, widens blast radius, and makes secret exposure more likely. The control gap is not only authentication, but the failure to expire access when risk changes.

Q: How can teams reduce blast radius after a compromised OAuth integration?

A: Teams should immediately revoke the affected token, rotate any secrets exposed through the integration, and review connected systems for secondary access paths. They should also audit whether other apps share the same scopes or trust chain. The first 24 to 72 hours should focus on containment, revocation, and inventory, not only on root cause analysis.

Technical breakdown

Why OAuth integrations become high-risk identity bridges

OAuth delegates access through tokens and scopes, which means a connected application can act with authority derived from the user or service that approved it. If scope is broad, token life is long, or approval is not revisited, the integration behaves like a persistent non-human identity with access beyond its intended purpose. In this case, compromise of a third-party SaaS application created a path into an employee account and then internal systems. The failure mode is not OAuth itself but implicit trust in the connection after initial consent.

Practical implication: Treat every OAuth connection as an identity that needs scope review, time limits, and revocation paths.

How context-based authorization reduces token abuse

Context-based authorization evaluates access at runtime using signals such as device posture, location, IP reputation, anomaly detection, and task context. That matters because a stolen or abused token can still be valid while the surrounding conditions no longer look normal. A zero-trust model does not assume the token alone proves legitimacy. Instead, it asks whether the request still fits the expected session, actor, and purpose before permitting access. This makes lateral movement harder after a third-party compromise.

Practical implication: Add runtime policy checks to high-risk OAuth flows so valid tokens are still challenged when context changes.

Why just-in-time access is stronger than standing privilege for agents and apps

Just-in-time access issues privileges only when needed and removes them after the task window closes. For non-human identities, that is more effective than standing privilege because compromised credentials have less time and less utility. If an integration or AI agent only holds the minimum scope for the current action, the attacker inherits far less. The architectural point is simple: reduce the value of stolen access by making access temporary, narrow, and continuously re-evaluated. That is especially important where secrets and API keys are stored in internal systems exposed through delegated access.

Practical implication: Use time-bound, task-scoped access for third-party apps and AI agents instead of persistent entitlements.

Threat narrative

Attacker objective: The attacker aimed to turn a single compromised integration into broad internal access and monetisable secret exposure.

1. Entry occurred through a compromised third-party OAuth integration tied to an employee account.
2. Escalation followed when that delegated access was used to reach internal Vercel systems and exposed secrets.
3. Impact included theft of customer credentials, API keys, database credentials, and signing keys, with reported dark web resale activity.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Governed OAuth is now an NHI control plane, not a convenience feature. The Vercel breach shows that delegated access can become a durable identity path when approval, scope, and revocation are weak. That changes the governance question from app onboarding to identity containment. Practitioners should manage OAuth connections as high-risk non-human identities.

Identity blast radius is the right concept for this class of breach. A single compromised integration can cascade from one employee account into internal systems, secret stores, and downstream customer exposure. Traditional perimeter thinking misses this because the breach is inside valid authentication. Security teams need to measure how far one token can move, not just whether the token is technically valid.

Context-aware authorization should be treated as a baseline for third-party access. Runtime evaluation gives defenders a chance to stop abuse after initial consent, especially when device, location, or behaviour no longer match expected conditions. Without that layer, token theft and session abuse remain easy to operationalise. Practitioners should assume delegated access will be abused and design policy to make that abuse short-lived.

Just-in-time access is becoming the practical answer to OAuth sprawl. Standing privilege makes compromise more valuable, while task-scoped access limits both duration and scope of misuse. That is especially relevant as AI tools and SaaS integrations multiply across enterprise environments. IAM leaders should move from static trust decisions to continuously re-evaluated access decisions.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, and those incidents are 13% more likely to be categorised as critical than code-based leaks.
• For adjacent context, read the Guide to the Secret Sprawl Challenge for remediation patterns that shorten exposure windows after a delegated-access compromise.

What this signals

Identity blast radius is now the operational metric that matters most. In environments filled with connected apps, the question is not whether OAuth works, but how far one compromised token can reach before policy intervenes. Teams should map privileged integrations to the systems and secrets they can touch, then measure where a single consent grants more access than the business actually requires.

The shift toward AI-driven assistants and SaaS automation makes this problem more acute, not less. When delegated access is broad, the control surface expands faster than manual review can keep up, so continuous verification and time-bound access become essential programme controls. Practitioners should expect more breaches to look like valid access abuse rather than obvious malware.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the pattern is clear: machine access is leaking in the same places that modern automation is being wired together. That means NHI governance has to cover consent, scope, token lifetime, and secret handling as one control domain, not separate problems, if teams want to stay ahead of delegated-access abuse.

For practitioners

• Audit every third-party OAuth connection Inventory connected apps, owners, scopes, consent history, and token lifetimes, then classify them by business criticality and data exposure. Prioritise the integrations that can reach internal systems or secret stores.
• Enforce scope minimisation and short token lifetimes Restrict OAuth scopes to the minimum needed for each use case and shorten token lifetime wherever operationally possible. Re-issue access for high-risk actions instead of relying on long-lived consent.
• Add runtime policy checks to delegated access Require context-aware approval for sensitive requests using signals such as device posture, network location, and anomalous behaviour. This is where continuous verification reduces the value of a stolen token.
• Move secrets out of broadly reachable internal paths Separate credentials, API keys, database secrets, and signing keys from systems reachable through common integrations. Limit which services can read them and ensure exposure triggers rapid revocation.
• Use just-in-time access for high-risk non-human identities Replace standing privilege with task-scoped access for service accounts, AI agents, and third-party automations. Reauthorise access when the task changes or the session expires.

Key takeaways

• The Vercel breach shows that a compromised OAuth integration can function as an identity bridge into internal systems, even when infrastructure itself is not the root cause.
• Credential exposure remains hard to contain because leaked secrets often stay valid long after discovery, which makes revocation and scope control essential.
• Security teams should govern delegated access as a non-human identity problem by enforcing runtime checks, short lifetimes, and just-in-time privileges.

Key terms

• Governed OAuth: Governed OAuth is the practice of treating delegated app access as a controlled identity relationship rather than a one-time convenience setting. It requires scope review, consent oversight, token lifecycle management, and revocation paths so a connected application cannot quietly retain more access than the business intended.
• Identity blast radius: Identity blast radius is the amount of system access an attacker can gain after compromising one identity, token, or delegated connection. In NHI environments, it is shaped by scope, token lifetime, downstream permissions, and how quickly access is re-evaluated after abnormal behaviour appears.
• Access intelligence: Access intelligence is a runtime authorization approach that combines identity, context, and policy before granting or continuing access. It reduces the value of stolen credentials by requiring the request to still look legitimate at the moment of use, not just at the moment of approval.
• Just-in-time access: Just-in-time access is a model where privileges are granted only when a task requires them and withdrawn when the task ends. For non-human identities, it limits the usefulness of compromised credentials by shortening the time window and narrowing the actions an attacker can perform.

Deepen your knowledge

OAuth governance and just-in-time access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for third-party integrations and AI-driven access paths, it is worth exploring.

This post draws on content published by Curity: the Vercel breach and the case for governed OAuth. Read the original.