OAuth supply chain abuse exposed Vercel data through third-party access

At a glance

What this is: This is an analysis of how a compromised third-party OAuth grant enabled access to Vercel and what that reveals about delegated identity risk.

Why it matters: It matters because IAM, IGA, and NHI teams must govern third-party consent, app visibility, and permission scope as part of the access perimeter, not as a side issue.

👉 Read Expel's analysis of the Vercel OAuth supply chain breach

Context

OAuth consent grants let a third-party application act within a defined permission scope, but the control only works if the app remains trustworthy and the scope stays narrow. In this case, the security problem is not direct account compromise at the destination but delegated access through a compromised integration.

That makes OAuth governance a shared responsibility across human approval, third-party application lifecycle, and non-human access monitoring. The Vercel incident is a familiar pattern in environments where app consent grows faster than review discipline, and that starting position is unfortunately typical rather than exceptional.

Key questions

Q: How should security teams govern third-party OAuth grants in enterprise environments?

A: Security teams should treat third-party OAuth grants as privileged access, not as ordinary app settings. Each grant should have a business owner, a scope review, an expiry or revalidation date, and a revocation path. If a grant can reach sensitive data or internal systems, it belongs in the same governance workflow as elevated credentials and NHI inventory.

Q: Why do compromised OAuth apps create such a high-risk access path?

A: Because the attacker inherits legitimate delegated access rather than forcing a fresh login or password compromise. That lets malicious activity blend into normal application behaviour, especially when permissions are broad and monitoring is weak. The risk is highest where app consent is long-lived and poorly inventoried.

Q: What breaks when organisations cannot see third-party app consent clearly?

A: They lose the ability to distinguish sanctioned integrations from shadow apps, and incident scoping becomes slow and incomplete. Without visibility into approved scopes, ownership, and usage, security teams cannot quickly identify which client IDs are active or whether they should be revoked.

Q: How can organisations reduce risk from third-party OAuth integrations?

A: Organisations should inventory every integration, limit scopes to business necessity, and monitor token behaviour for abnormal timing, volume, or source location. They should also review vendors that can hold refresh tokens, because a compromise in that layer can extend into many downstream environments.

Technical breakdown

How compromised OAuth grants become a supply chain path

OAuth grants are delegated authorisations, not passwords. A user or administrator approves a third-party application to access specific resources, and the resulting token or client authorization can persist until it is revoked or expires. If the third-party app is compromised, attackers can inherit the app’s approved reach without needing to defeat the destination system directly. The weakness is often not cryptography, but trust placement across identities, apps, and approval workflows.

Practical implication: map every OAuth grant to an owning business process and revoke stale or unneeded third-party consents.

Why app client IDs matter in incident hunting

An application client ID is the stable identifier defenders can use to find where a specific OAuth app appears across tenants and environments. When a vendor discloses an abused client ID, security teams can search logs, identity stores, and consent records for the same application footprint. That hunt depends on visibility into app registrations, consent events, and token usage, not just endpoint or network telemetry. Without that linkage, delegated access remains invisible during scoping.

Practical implication: centralise OAuth inventory so client IDs can be searched quickly across identity and audit logs.

Why consent scope is the real control boundary

OAuth risk rises when users can approve broad scopes or when organisations allow unmanaged third-party applications to accumulate access over time. Consent scope defines what the app may do, but governance determines whether that scope was justified, reviewed, and removed when the relationship changed. In practice, the same permission model that supports productivity also creates a durable access path if review discipline is weak. That is why OAuth should be treated as privileged delegation, not routine app onboarding.

Practical implication: restrict user-granted permissions and require approval for high-risk scopes before they are allowed in production.

Threat narrative

Attacker objective: The attacker’s objective was to reach and steal data from Vercel by abusing delegated access from a compromised third-party app.

1. Entry occurred through a compromised third-party OAuth grant tied to Context AI, allowing the attacker to reuse legitimate delegated access rather than attack Vercel directly.
2. Escalation happened because the app’s approved permissions provided a trusted path into Vercel-associated data and systems, bypassing normal account compromise signals.
3. Impact was the theft of data from Vercel through an abused integration, showing how supply chain access can become destination compromise.

Breaches seen in the wild

• Klue OAuth Supply Chain Breach — OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
• Vercel Context.ai OAuth Supply Chain Breach — Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

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

NHI Mgmt Group analysis

Delegated access has become part of the identity perimeter. OAuth grants now function like durable machine-to-machine trust links, so a compromised third-party app can inherit access without touching the primary organisation’s login controls. That shifts the governance problem from authentication alone to consent lifecycle, scope review, and revocation discipline. Practitioners should treat every approved app as an identity object with an owner, purpose, and expiry.

Shadow app risk is often a visibility failure before it becomes a breach. The real gap is not that OAuth exists, but that many organisations cannot reliably inventory where a given client ID is authorised, who approved it, and whether the app still needs access. That makes discovery, consent logging, and periodic recertification core controls rather than administrative extras. Teams should assume unreviewed app consent is an active control gap, not benign configuration drift.

OAuth governance is where human approval and NHI control meet. A person approves the grant, but the resulting access is exercised by a non-human application that can persist independently of the original user’s intent. That means human IAM policies, IGA review cycles, and NHI governance must be aligned around the same delegated access record. Security teams should stop treating third-party app consent as a separate silo.

Ephemeral approval without lifecycle control creates trust debt. OAuth was designed for bounded delegation, but in practice many environments accumulate long-lived approvals that outlive business need, vendor trust, and user awareness. The concept worth naming here is consent sprawl: authorised app access that expands faster than review. Practitioners should recognise that unmanaged consent is simply another form of standing privilege.

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.
• 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 visibility gap makes Ultimate Guide to NHIs , Key Challenges and Risks the right next step for teams tightening delegated access control.

What this signals

Consent sprawl is now a governance problem, not just an integration problem. When third-party apps can hold meaningful access across business systems, the approval record becomes as important as the credential itself. Teams that already run access reviews for privileged humans should extend the same discipline to OAuth grants, because delegated access now behaves like standing privilege in practice.

The next control maturity step is correlation: approved app, active token, scope, owner, and business justification need to line up in one record. Without that, incident response will continue to start with a hunt instead of a decision. For broader NHI control context, teams should pair OAuth review with the patterns in the 52 NHI breaches Report.

For practitioners

• Inventory every third-party OAuth grant Build a current list of approved applications, scopes, owners, and last-used dates so hidden grants can be reviewed before they become incident paths.
• Restrict user-granted scopes by policy Limit which permissions end users can approve, especially for read-write access, mailbox access, data export, and offline token scopes.
• Hunt for unexpected client IDs Search identity logs and consent records for unfamiliar application client IDs, then validate whether those apps are sanctioned or should be removed.
• Recertify third-party access on a fixed cadence Review app consent against business purpose, data sensitivity, and vendor trust changes, then revoke access that no longer has an active owner.

Key takeaways

• Third-party OAuth grants can become a direct breach path when the app is compromised, even if the destination system is not directly attacked.
• The core failure is visibility and lifecycle control over delegated access, especially when approvals outlive the business need behind them.
• Security teams need inventory, scope restriction, and recertification to keep OAuth from becoming persistent standing privilege.

Key terms

• OAuth Consent: The approval that allows an application to access resources on behalf of a user or tenant. In practice, consent can create durable access paths that outlive the original interaction if permissions are broad, unmanaged, or never reviewed. For security teams, it is both an access decision and a lifecycle event.
• Third-Party Visibility: The ability to see how external vendors, SaaS services, and outsourced providers connect to data and systems. It includes knowing what they access, how they authenticate, and whether their permissions are proportionate to the work they perform.
• Consent Sprawl: Consent sprawl is the buildup of many small application approvals that are individually easy to grant but collectively hard to govern. It leads to residual access, unclear ownership, and delayed offboarding because no single process keeps pace with the volume of delegated permissions.

What's in the full analysis

Expel's full analysis covers the operational detail this post intentionally leaves for the source:

• How the compromised OAuth application client ID was used during customer hunts and what that reveals about scoping work
• The exact investigation approach for finding excessive or unexpected OAuth consent grants across environments
• Practical guidance on restricting what permissions users can grant to third-party applications
• The reference details around the disclosed client identifier and why app identity matters in incident response

👉 Expel's full post covers the hunt method, consent-grant scoping, and the specific application identifier involved.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.