OAuth supply chain attacks are outpacing enterprise identity controls

At a glance

What this is: This is an analysis of a Vercel incident that began with a compromised third-party OAuth app and ended with unauthorized access to internal systems and some customer data.

Why it matters: It matters because every IAM, NHI, and human identity programme now has to treat third-party OAuth grants as standing attack surface, not just convenience access.

By the numbers:

• The attacker could use stolen credentials within an average of 17 minutes after AWS credentials are exposed publicly, and as quickly as 9 minutes in some cases.

👉 Read SlashID's analysis of the Vercel OAuth breach and delegated access risk

Context

OAuth 2.0 supply chain abuse happens when a user or employee grants a third-party app access that later becomes a liability. In this case, the primary identity problem is not authentication failure but delegated trust that outlives the security posture of the app receiving it.

The breach matters for NHI governance because OAuth grants function as non-human identity access paths with persistence, scope, and revocation risk. Once a compromised app inherits an employee's approvals, the attacker is operating through legitimate tokens rather than noisy intrusion tools, which makes traditional perimeter thinking too slow.

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 broad OAuth scopes increase breach impact?

A: Broad scopes turn one consent decision into multiple reachable resources, which gives an attacker a much larger blast radius if the app is compromised. Mail, drive, calendar, and directory access can expose credentials, internal documents, and organisational structure. The wider the bundle, the more likely the compromise becomes a workspace-level incident rather than a single-app event.

Q: How can security teams tell whether OAuth access is drifting out of policy?

A: Look for apps that request more scopes than their function requires, grants that were never revisited, and applications that suddenly gain broader permissions. A healthy programme correlates scope, usage, and revocation history rather than relying on one-time approval checks. If an app still holds access after its business purpose has faded, policy drift has already begun.

Q: Who is accountable when a third-party OAuth app causes a breach?

A: Accountability usually sits across the app owner, the identity team, and the business approver because the risk is created by delegated trust and then sustained by governance gaps. The organisation remains responsible for how grants are approved, monitored, and revoked. Regulators and auditors will usually ask whether the access was necessary, monitored, and removed in time.

Technical breakdown

How compromised OAuth apps inherit legitimate access

OAuth 2.0 lets a user authorize an application to access specific resources on their behalf. The application receives access tokens and refresh tokens that remain valid until revoked, so compromise of the app developer or its token store can turn a normal consent grant into attacker-controlled access. In this incident pattern, the app does not need to break into the target domain directly. It only needs a valid delegated grant and the ability to reuse it. That is why consent scope, token lifetime, and revocation coverage matter more than one-time login events.

Practical implication: inventory all third-party OAuth grants and treat each one as a revocable access relationship.

Why broad scopes create oversized blast radius

OAuth scopes define what the app can do, but users often approve them in bundles. When an application requests Drive, Gmail, Calendar, or directory access together, the result is a single delegated trust decision with many downstream effects. A compromised token can expose email content, documents, metadata, and administrative structure, which lets attackers map the environment and pivot to higher-value targets. The weakness is not only the token, but the tendency to grant more access than the app truly needs.

Practical implication: limit scopes to the minimum functional set and reject all-or-nothing consent patterns wherever possible.

Why manual review fails at OAuth grant scale

Manual admin-console review cannot keep pace when organisations have dozens or hundreds of third-party apps. Attackers benefit from the delay between token theft, app reputation checks, and human triage. OAuth abuse often looks like ordinary application use until a specific client ID, unusual scope combination, or bulk grant pattern is correlated across logs. That means detection depends on continuous identity visibility, not periodic spot checks. Without it, a compromised app can persist long enough to exfiltrate data and spread laterally through trusted services.

Practical implication: build continuous monitoring for new grants, scope escalation, and dormant apps that still retain access.

Threat narrative

Attacker objective: The attacker aimed to inherit trusted third-party access and use it to reach internal systems and sensitive data while blending into legitimate OAuth activity.

1. Entry occurred when a Context.ai employee with administrative privileges was infected with Lumma Stealer, which exfiltrated browser credentials, session cookies, and OAuth tokens from the workstation.
2. Credential access then extended to a compromised OAuth application registered by Context.ai, allowing the attacker to reuse legitimate delegated access into Vercel-related Google Workspace resources.
3. Escalation followed through broad consent and workspace trust, giving the attacker access to internal environments, environment variables, and a subset of customer data without needing a traditional perimeter breach.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 is now a standing identity control surface, not a one-time user action. The Vercel incident shows that a granted app can outlive the conditions under which it was approved, which turns consent into persistent attack surface. In identity governance terms, the issue is not just who approved the app, but how long the delegated trust remained in force after the app was compromised. Practitioners should treat OAuth grants as lifecycle-managed access relationships, not as static configuration.

Broad consent creates identity blast radius that IAM teams still underestimate. When a third-party app can reach mail, drive, calendar, or directory data through one approval flow, the attacker inherits more than a token. They inherit context, discovery, and a path to higher-value identities. That is why broad OAuth scope bundles deserve the same scrutiny as privileged service accounts and vendor access paths. The practitioner conclusion is simple: scope aggregation is a governance failure, not a convenience feature.

Third-party OAuth access is a non-human identity problem hiding inside human approval workflows. Employees approve the grant, but the resulting access belongs to the app and persists independently of the user's intent. That creates a cross-actor governance gap where human sign-off masks machine persistence. The result is that human IAM controls, by themselves, do not contain non-human exposure. Organisations need to govern the delegated identity, not just the person who clicked allow.

Context.ai-style compromise proves that visibility without revocation is only partial control. The report highlights a gap between seeing the app and stopping its access. Manual review can identify the grant after the fact, but if revocation is slow, the attacker has already used the trust. This is the named failure mode: delegated trust without lifecycle offboarding. The practitioner takeaway is that identity governance must be able to remove third-party access at the same speed that it discovers it.

OAuth investigations should be framed as identity supply chain incidents. The compromise began upstream, then propagated through authorised tokens into enterprise systems. That makes the attack chain structurally similar to other NHI breaches where a trusted issuer, integration, or service account becomes the entry point. For practitioners, this means vendor onboarding, consent review, and offboarding must be integrated into one governance model rather than handled as separate hygiene tasks.

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.
• That confidence gap is why practitioners should pair OAuth visibility with governance workflows in 52 NHI Breaches Analysis before the next delegated trust incident lands.

What this signals

Delegated trust has become a lifecycle problem. Once an OAuth grant is approved, it behaves like standing access unless someone actively revokes it, reviews it, and correlates it to business purpose. That means identity programmes need to treat third-party app access as governed entitlement, not just cloud configuration.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, the operational gap is not subtle. Security teams should expect hidden app sprawl, delayed detection, and weak revocation discipline unless they centralise identity graph coverage.

Delegated trust without lifecycle offboarding: once a third-party app is no longer valid, its access still needs an explicit removal path. That failure mode is now common enough that many teams should validate it against the patterns in the 52 NHI breaches Report and align review cycles with actual grant persistence, not annual paperwork.

For practitioners

• Inventory every third-party OAuth grant Map all apps authorized across Google Workspace, Entra, Okta, Salesforce, and similar systems, then flag dormant grants, unused apps, and broad consent bundles that still persist.
• Restrict consent to minimum viable scopes Review each application against its actual function and remove permissions that exceed the task, especially mail, drive, directory, and admin-level access.
• Create a fast revocation path for compromised apps Define who can revoke third-party grants, how bulk revocation is executed, and how affected users are identified from the identity graph before the attacker finishes lateral use.
• Monitor for scope escalation and bulk grant patterns Alert on apps that gain broader scopes over time or rapidly accumulate approvals across many users, because those patterns often precede compromise or phishing.

Key takeaways

• The breach shows that OAuth consent can function as durable attack surface when third-party apps are compromised.
• The scale of the problem is amplified by broad scopes, delayed detection, and the fact that many organisations still lack full visibility into third-party app access.
• The control that changes the outcome is not just review, but fast discovery plus revocation of delegated access before the attacker can reuse legitimate tokens.

Key terms

• OAuth Grant: An OAuth grant is the delegated permission a user gives an application to access specific resources on their behalf. In identity governance, the grant becomes a standing access relationship that must be tracked, reviewed, and revoked when the application or business need changes.
• Scope Creep: Scope creep is the gradual expansion of what a delegated application can do beyond its original purpose. In OAuth environments, it usually appears as broader permissions, extra APIs, or added administrative reach that increase the blast radius of a compromise.
• Identity Graph: An identity graph is a consolidated view of users, applications, grants, and relationships across an environment. For OAuth governance, it helps teams see which third-party apps are authorized, what they can reach, and which users or systems would be exposed if access were abused.
• Delegated Trust: Delegated trust is the security model in which one identity is allowed to act for another through an approved access grant. In this article's context, it is the core failure point because the trust persists after the third-party app is compromised unless governance removes it.

Deepen your knowledge

OAuth grant visibility and delegated-access governance 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 app access in a similar environment, it is worth exploring.

This post draws on content published by SlashID covering the Vercel OAuth breach: OAuth 2.0 supply chain risk and identity delegation abuse. Read the original.