Vercel breach exposes OAuth trust gaps in Google Workspace

At a glance

What this is: This is an analysis of the Vercel breach chain, showing how a consumer app compromise and permissive OAuth consent exposed enterprise systems through Google Workspace trust relationships.

Why it matters: It matters because IAM, NHI, and SaaS governance teams must treat OAuth consents, tokens, and third-party app access as credentialed attack surface rather than procurement-only risk.

By the numbers:

• The stolen data reportedly includes API keys, NPM tokens, GitHub tokens, source code, and 580 employee records.

👉 Read Clutch Security's analysis of the Vercel breach and OAuth trust gaps

Context

OAuth consent has become a shadow access path inside many enterprises. A user can grant a third-party application persistent access to email, files, and identity-linked data without that relationship passing through procurement, vendor review, or traditional IAM inventory.

In this case, a consumer app sign-up and a permissive Google Workspace setting created a trust chain that allowed an attacker to move from a compromised endpoint into enterprise systems. That is a typical SaaS governance failure pattern, not an edge case.

The primary issue is not malware novelty. It is that OAuth tokens and app consents now behave like long-lived non-human identities, yet many identity programmes still treat them as peripheral integrations rather than governed access credentials.

Key questions

Q: What breaks when OAuth consent is not centrally governed?

A: When consent is not centrally governed, employees can grant third-party apps persistent access to enterprise data without security review. That breaks the assumption that only procured vendors can reach sensitive systems. The result is shadow access that bypasses inventory, risk assessment, and lifecycle control, leaving identity teams blind to delegated privileges already inside the tenant.

Q: Why do OAuth tokens increase lateral movement risk in SaaS environments?

A: OAuth tokens increase lateral movement risk because they can remain valid after the initial user session, bypass MFA, and preserve scoped access until revoked. In SaaS environments, that makes a single consented app a durable bridge into email, files, logs, and admin-adjacent data. Identity governance must treat token scope and revocation as first-class controls.

Q: How do security teams know if third-party app access is out of control?

A: Security teams know the problem is out of control when they cannot answer how many external apps have tenant access, what scopes they hold, and who approved them. A healthy programme can reconcile app inventory with live OAuth grants and remove stale or unowned consents quickly. If that is impossible, the control boundary has already failed.

Q: Who is accountable when a user grants a risky third-party app access?

A: Accountability is shared, but the security function owns the policy boundary. Users can create the event, yet the enterprise is responsible for setting consent rules, monitoring delegated access, and revoking unnecessary scopes. Frameworks such as NIST CSF and OWASP-NHI help formalise that ownership across identity, SaaS, and NHI governance.

Technical breakdown

How stolen OAuth tokens become enterprise access

OAuth tokens are delegated credentials. Once a user consents, the app can act with the scopes granted until the token is revoked or expires, which means compromise of the app or upstream account can preserve access without password reuse. In SaaS environments, those tokens often bridge email, files, logs, and admin-adjacent data because the app inherits trust from the user and the tenant policy. The practical problem is not just theft. It is that valid token use can look normal until the attacker begins enumerating resources or harvesting data.

Practical implication: Treat OAuth tokens as governed credentials and restrict third-party app consent before they enter the tenant.

Google Workspace consent as a hidden privilege boundary

Workspace admin defaults can determine whether users may approve broad third-party scopes on their own. When consent is permissive, the privilege decision moves out of central control and into the user click path, which is exactly where attackers want it. This collapses the separation between consumer-style sign-up and enterprise authorization. Once a token exists, it can survive password resets and bypass MFA because the permission was already delegated. That makes consent policy a privilege boundary, not a convenience setting.

Practical implication: Lock third-party consent to admin-approved apps and review scope grants as part of privilege governance.

Why OAuth trust relationships behave like standing NHI access

OAuth apps, service tokens, and API keys all create machine-to-machine access that persists beyond a single login event. The key difference from human access is that the trust is not re-established every session. In this breach, that persistence allowed a consumer product relationship to become an enterprise pivot point. The same pattern appears whenever an application is trusted once and then left in place without lifecycle review, scope minimisation, or offboarding discipline. That is a non-human identity governance problem, not just a SaaS hygiene issue.

Practical implication: Inventory third-party OAuth grants and fold them into NHI lifecycle review, including offboarding and scope recertification.

Threat narrative

Attacker objective: The attacker aimed to use delegated trust relationships to reach internal systems, steal high-value credentials and data, and monetise the access through extortion.

1. Entry began when a Context.ai employee downloaded Roblox cheat scripts bundled with Lumma Stealer, which harvested browser credentials, cookies, and API keys from the work machine.
2. Credential access followed when the attacker used stolen credentials and OAuth tokens to reach Context.ai systems, then pivoted through a Vercel employee's Google Workspace account granted broad consent.
3. Impact came when the attacker enumerated environment variables, project settings, deployment configurations, and logs, then exfiltrated API keys, tokens, source code, and employee records.

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

OAuth consent drift is a governance failure, not a simple integration risk. The breach worked because a user-facing permission screen was allowed to create enterprise-grade access outside procurement and outside central identity review. That means the control gap is not only token theft, but the absence of lifecycle governance for third-party app consents. Practitioners should treat consent grants as governed entitlements, not incidental usage.

Standing credential exposure window: This breach exposed the assumption that delegated access is short-lived enough to be observed and corrected before it is abused. That assumption fails when OAuth tokens persist across sessions, survive password resets, and remain valid after the originating user context changes. The implication is that review-based governance cannot protect access that outlives the event that created it.

Google Workspace now functions as an identity control plane for SaaS-native enterprises. When email, documents, and token delegation sit in the same trust boundary, compromise of one consented application can become a broad identity event rather than a point incident. The relevant frameworks are OWASP-NHI and NIST CSF, because the problem is credential governance across machine-access paths. Practitioners should stop separating SaaS app governance from identity governance.

Vendor risk questionnaires do not model shadow OAuth relationships. The attack path bypassed the normal supplier onboarding logic because the downstream enterprise had no procurement record of the app that was actually trusted. That breaks the assumption that third-party exposure is knowable through contract inventory alone. The practical conclusion is that identity telemetry must reveal every external app holding privileged access, regardless of who bought it.

Consumer-app sign-up is now an enterprise access decision. A free product account created by an employee can become a lateral-movement bridge into corporate systems if consent policy is permissive. That is a non-human identity problem wrapped inside a human workflow. Practitioners should align human identity policy, NHI governance, and SaaS consent controls into one access model.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: 1 in 4 organisations are already investing in dedicated NHI security capabilities, according to The State of Non-Human Identity Security.
• The governance gap now sits between SaaS consent and identity lifecycle, which is why the NHI Lifecycle Management Guide is the next resource to apply.

What this signals

Shadow OAuth consent is now part of the NHI attack surface. When a single app approval can create durable machine access, identity teams need a lifecycle model that tracks external grants the way they track service accounts and API keys. The operational question is no longer whether employees may click consent screens, but whether the resulting entitlements are visible, owned, and revocable within the same governance fabric.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security, SaaS governance and NHI governance are converging into one control problem. Enterprises that still separate procurement-managed vendors from employee-granted access will continue to miss the real trust boundary. The right next step is to inventory delegated access alongside other non-human credentials.

Consent-chain governance: this is the control model that matters here, because the breach shows how a human click can create an NHI-style access path with enterprise reach. Security programmes should prepare for app consent, token scope, and offboarding to be reviewed as one lifecycle, not three disconnected processes. The NHI Lifecycle Management Guide is the relevant starting point for that redesign.

For practitioners

• Restrict OAuth app consent by default Allow only admin-approved applications to receive enterprise scopes in Google Workspace and Microsoft 365, then document exceptions with business justification and expiry. This closes the user-click path that turned consumer sign-up into enterprise access.
• Inventory every third-party app with delegated access Build a live register of OAuth grants, scopes, and owners that includes apps employees authorised directly, not just procured vendors. Reconcile the register against tenant logs so shadow apps do not remain outside review.
• Classify OAuth tokens as high-value credentials Apply the same handling discipline used for API keys and service account secrets, including revocation workflows, scope minimisation, and alerting on unusual token use. Treat password resets as irrelevant unless the token itself is revoked.
• Monitor for exposed app identifiers and suspicious scope use Search for the published OAuth App ID in tenant logs and investigate any authorization history, then alert on broad scopes such as full mail and drive access. The key signal is delegated access that exceeds the app's normal function.

Key takeaways

• The breach exposed a governance blind spot where consumer-style OAuth consent created enterprise access without central review.
• The scale is not theoretical, because the attacker reportedly sought $2 million and exfiltrated credentials, source code, and employee records.
• The control that would have mattered most was default restriction of third-party consent combined with live visibility into delegated access.

Key terms

• OAuth Consent Drift: OAuth consent drift is the gradual accumulation of third-party application permissions that no one actively owns or reviews. It becomes a governance problem when app scopes persist beyond the original use case, creating hidden access paths that behave like standing credentials inside the tenant.
• Delegated Access: Delegated access is permission granted to one application or service to act on behalf of a user or tenant. In identity programmes, it must be treated as a credentialed relationship with scope, owner, and expiry, not as a harmless integration detail.
• Shadow OAuth Relationship: A shadow OAuth relationship is an external application granted access by a user without a procurement record, risk review, or clear owner. It is the SaaS equivalent of unmanaged machine identity, because it can persist quietly while still holding meaningful access.
• Standing Credential Exposure Window: The standing credential exposure window is the period during which a valid token or secret can be used before governance detects or revokes it. For OAuth and other NHI credentials, that window often outlasts the triggering event, which is why lifecycle control matters more than reactive review.

Deepen your knowledge

OAuth consent governance and delegated access are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to bring SaaS app permissions into the same control model as service accounts and API keys, it is worth exploring.

This post draws on content published by Clutch Security covering the Vercel breach: Six Hard Truths About the Vercel Breach (And What to Do About Them). Read the original.