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 data through Context AI.

Why it matters: It matters because IAM and SaaS governance teams have to treat consented app access as part of the identity perimeter, not a separate integration concern.

Context

OAuth consent grants let a third-party application access specific data on a user's behalf, which makes them part of the identity control plane rather than a simple application integration. In this case, the security problem was not direct compromise of the target platform but delegated access that survived long enough to be abused.

Expel's analysis shows why consented app access needs the same scrutiny as privileged accounts and service tokens. When a third-party application is compromised, the resulting access can bypass perimeter assumptions and appear legitimate unless teams actively inventory grants, scope, and unusual app behavior.

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 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: How should security teams reduce the impact of malicious OAuth consent grants?

A: They should restrict which apps and users can complete high-risk consent paths, remove unnecessary Conditional Access exclusions, and review token reuse across app families. The goal is to shrink the blast radius of any single browser interaction so that one successful consent does not become broad platform access.

Q: When should organisations revoke third-party access credentials?

A: Organisations should revoke third-party access credentials whenever the business purpose changes, an incident occurs, the vendor scope expands unexpectedly, or the credential has not been explicitly revalidated. Standing access should be the exception, not the default. If the credential is no longer clearly justified, it is already overdue for removal.

Technical breakdown

How abused OAuth grants become an access path

OAuth grants are delegated authorisations, not passwords, so an attacker who compromises the third-party application can often reuse the approved access path without triggering a fresh login. The key issue is scope: if the grant allows broad mailbox, profile, or data access, the application becomes a standing trust relationship that can be exploited from the trusted side. In supply chain cases, the target rarely sees a direct intrusion first, only legitimate-looking API activity under an approved client ID.

Practical implication: treat approved OAuth applications as governed identities with explicit scope review and revocation authority.

Why consented app access behaves like shadow identity risk

A shadow app is any approved third-party application that is no longer well understood, monitored, or justified by the business owner. In practice, OAuth consent often accumulates over time, creating access paths that are technically legitimate but operationally forgotten. That makes discovery harder than with a user account, because the authorization is embedded in the relationship between the tenant, the user, and the app client ID rather than in a visible login event.

Practical implication: maintain an inventory of consented apps, owners, scopes, and last-use signals across the tenant.

How client IDs help incident scoping across environments

An OAuth client ID is the application identifier that ties consented access to a specific third-party app instance. When an incident bulletin exposes that identifier, defenders can search for the same app presence across tenants and environments, which turns one reported compromise into a concrete hunt pattern. That scoping approach is especially useful when the initial compromise happened outside the victim organisation, because it identifies where the same delegated access relationship may still exist.

Practical implication: use disclosed client IDs and app identifiers to hunt for the same grant pattern before revoking or restricting access.

Threat narrative

Attacker objective: The attacker wanted to use third-party delegated access to reach Vercel data without a direct compromise of Vercel itself.

1. Entry occurred when attackers gained control of a compromised Context AI account, giving them a foothold inside the third-party trust relationship rather than inside Vercel directly.
2. Credential access happened through the already-approved OAuth grant, which let the attacker use delegated application permissions instead of stealing Vercel credentials.
3. Impact followed when the attacker used that delegated access to reach and steal data from Vercel through the supply chain path.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party OAuth consent is now part of the identity perimeter. Once a user grants an external application access, the security boundary extends beyond the local tenant and into the app's own compromise posture. That means a clean internal environment can still be exposed by a delegated relationship that was approved months earlier. Practitioners need to govern consented apps as identities with lifecycle and scope, not as passive integrations.

Ephemeral trust is a misnomer when consent never expires. OAuth grants often outlive the business reason for approving them, which creates dormant access that attackers can activate later through the app side of the relationship. The governance failure is not just excessive privilege, but trust persistence without continuous justification. Teams should interpret every standing consent as a dormant access path until proven otherwise.

Shadow app inventory is the missing control plane for SaaS-to-SaaS risk. The article's hunt for an abused client ID shows that detection depends on knowing which applications are present, who approved them, and what they can reach. Without that inventory, incident response becomes guesswork and review cycles miss the highest-risk grants. The implication is clear: app governance must be operational, searchable, and tied to ownership.

OAuth supply chain abuse exposes a control gap in user-approved delegation. The compromised Context AI account was the broken trust link, not the target platform's primary authentication layer. That changes how practitioners should think about third-party access, because the control failure sits in delegated authorisation and offboarding discipline. The practical conclusion is that consent review, scope restriction, and revocation need to be treated as core IAM work, not admin cleanup.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Security researchers tracked consent phishing campaigns affecting 900 tenants and 3,000 user accounts in 2025.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

OAuth consent is an identity governance problem, not just a SaaS configuration issue. Once delegated access exists, the control objective shifts from initial approval to ongoing scope discipline, owner attribution, and revocation. Teams that already manage service accounts and privileged users should apply the same lifecycle thinking to third-party apps, because the blast radius is defined by what the app can still reach.

The practical signal for IAM teams is that app inventories need to be searchable by client ID, scope, and approver so that one disclosed incident can be turned into a tenant-wide hunt. That is the operational difference between reviewing integrations and governing identities.

For practitioners

• Audit third-party OAuth consent grants Review all consented applications for scope, owner, and business justification, then flag grants that no longer match active use or approved vendors.
• Restrict user-approved permissions Limit which permissions users can grant to third-party apps, especially mailbox, data export, and offline access scopes that expand blast radius.
• Hunt for unexpected client IDs Search tenants for the disclosed application client ID and similar uncommon OAuth app identifiers to find where the same trust relationship exists.
• Revoke stale delegated access Remove OAuth grants that are no longer operationally needed and require reapproval when the app, owner, or business purpose changes.
• Monitor unusual third-party app behaviour Alert on rare app usage, anomalous API activity, and applications appearing in sensitive data paths that were not expected in normal operations.

Key takeaways

• A compromised third-party OAuth grant can expose data without a direct breach of the target platform.
• The real control gap is delegated access that remains valid after the business need or trust assumption has changed.
• Consented apps need inventory, scope review, and revocation discipline because they function as governed identity paths.

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 App Governance: Third-party app governance is the discipline of controlling external applications that have been approved to access internal data or workflows. It covers ownership, scope, justification, monitoring, and offboarding so that delegated access does not become a hidden identity path.
• Client ID: The public identifier that tells an identity provider which application is requesting access. It is not a secret and does not prove the executable behind the request is legitimate, which is why impersonation of desktop clients can succeed if governance relies on the identifier alone.
• Shadow app: A shadow app is an OAuth or GitHub App that exists in the environment without clear ownership or active oversight. These integrations are risky because they can retain broad permissions quietly, making it hard to judge whether the access is still needed or still appropriate.

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 building or maturing an IAM programme, it is worth exploring.