OAuth supply chain attacks are outpacing enterprise identity controls

At a glance

What this is: This is an analysis of how a compromised third-party OAuth app became the entry point for the Vercel incident and why delegated consent can outlive trust.

Why it matters: It matters because IAM teams need to govern OAuth grants as standing access paths across human and non-human identity ecosystems, not as one-time user approvals.

Context

OAuth 2.0 grants are delegated access relationships, not transient logins. When a user approves a third-party app, that app can retain access until the grant is revoked, which means the real security boundary is the scope list and the lifecycle of the consented connection.

In the Vercel case, a compromised Context.ai OAuth app was used to inherit access through a Google Workspace account and reach internal systems. That is a supply chain problem expressed through identity control failure, and it is increasingly common wherever SaaS, AI assistants, and third-party integrations are allowed to accumulate broad grants.

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 should teams detect risky OAuth apps before they cause damage?

A: By continuously inventorying grants, flagging unusual scope combinations, and reviewing newly seen applications against expected business use. Manual spot checks are too slow when apps can proliferate across the tenant. Detection has to focus on the consent layer, because valid tokens can still represent unsafe access.

Q: When should organisations revoke OAuth grants or refresh tokens?

A: Revoke them when the application is no longer needed, ownership changes, the user leaves, the business purpose ends, or the granted scopes no longer match the task. If a connection is dormant, broad, or undocumented, it should be treated as a candidate for removal.

Technical breakdown

How compromised OAuth apps inherit legitimate access

OAuth 2.0 is designed to let an application act on a user’s behalf without collecting the user’s password. The risk is that the app receives scoped, persistent access tokens that remain valid until revoked. If an attacker compromises the app, they do not need to bypass authentication again. They simply use the already-authorized trust relationship and any scopes the user granted, which can include mail, files, directory data, or downstream API access depending on the consented permissions.

Practical implication: treat OAuth grants as active credentials and inventory them with the same rigor as other secrets.

Why broad consent turns third-party apps into supply chain risk

The dangerous part is not OAuth itself but the breadth of delegated permission. An app that only needs one workflow can still request expansive scopes, and users often accept them without understanding the downstream blast radius. Once the third party is compromised, every scope that was consented becomes part of the attacker’s access surface. In identity terms, the trust chain extends from the employee to the app developer to the app’s runtime security posture, which is why a third-party compromise can bypass traditional perimeter controls entirely.

Practical implication: review scope requests as access design decisions, not as routine app onboarding clicks.

How detection gaps let stolen tokens stay useful

OAuth token abuse is difficult to spot because the attacker often appears to be a legitimate application using valid tokens. Standard perimeter controls may not flag the activity, especially when access comes from normal cloud services and permitted APIs. That creates a detection gap between token theft, consent abuse, and revocation. In a multi-app environment, the delay between compromise and discovery is often long enough for internal reconnaissance, data access, and token reuse across connected services.

Practical implication: monitor for anomalous grants, unusual scope combinations, and newly seen apps before relying on manual review.

Threat narrative

Attacker objective: The attacker aimed to convert third-party OAuth trust into durable access to internal systems and customer data without triggering perimeter-based defences.

1. Entry occurred when an attacker gained control of a compromised Context.ai OAuth application after the employee’s workstation was infected with infostealer malware.
2. Credential harvesting followed as browser cookies, OAuth tokens, and related credentials were exfiltrated from the infected machine.
3. Escalation happened when the stolen OAuth token was used to access Vercel Google Workspace and internal environments through legitimate consented access.
4. Impact was achieved through access to internal systems, environment variables, and a subset of customer data while the trust relationship still appeared valid.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.

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 supply chain control, not a user convenience feature. This incident shows that delegated access can become a persistent attack surface the moment a third-party app is granted scopes broader than the task requires. Identity governance has to treat consented OAuth grants as part of the access estate, because the blast radius lives in the grant, not only in the account.

Third-party app compromise collapses the trust model that traditional IAM assumes. OAuth 2.0 was designed for delegated access, but most enterprise controls still assume the app itself remains trustworthy after consent. When the app is compromised, the trust chain breaks at the application layer, and revocation becomes the only clean boundary that still matters.

Ephemeral user intent does not match persistent machine access. Employees approve an app once, but the resulting access can outlive the original business need by weeks or months. That creates a governance gap where access certification processes review users, while the real risk sits in the standing OAuth relationship. Practitioners need lifecycle visibility over the app grant itself, not just the account.

Context-aware OAuth governance is becoming a core identity security requirement. The market is moving toward continuous inventory, risk scoring, and revocation of delegated access because manual app review cannot keep pace with the number of grants in modern SaaS estates. Teams that still treat OAuth approvals as static onboarding events will keep missing the same attack path.

Unrestricted scope acceptance is the named concept practitioners should watch. Allowing broad consent, such as an "Allow All" pattern, creates scope accumulation that turns one compromised integration into multiple downstream access paths. The implication is straightforward: scope breadth, not just token theft, defines how far a third-party compromise can reach.

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.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: OAuth 2.0 and OpenID Connect Guide for Identity Teams

What this signals

Unrestricted consent is the issue, not just token theft. Enterprises need to understand which apps hold high-privilege scopes, who approved them, and whether the business owner still exists. The governance problem is that OAuth grants are often treated as onboarding events, while their risk profile changes continuously.

Scope breadth defines the blast radius. When a third-party app can read mail, access files, or query directories, a single compromise can expose both content and context. That is why consent review needs to move closer to issuance time, with revocation paths that match how quickly integrations are added and forgotten.

For practitioners

• Inventory every OAuth grant Map all third-party apps connected to Google Workspace, Entra, Okta, Salesforce, and similar identity providers, then record which users approved them and what scopes they hold.
• Restrict broad consent patterns Block or review apps that request wide scopes such as full mail, directory, or drive access when the stated use case does not require them.
• Cross-check client IDs against indicators Compare published OAuth client IDs and app identifiers with your identity graph so you can identify affected users without manual tenant-by-tenant investigation.
• Revoke dormant or risky app access Remove unused third-party apps and revoke grants that have no current business owner, then confirm the connected tokens are invalidated across the tenant.
• Monitor for scope escalation Alert on apps that gain broader permissions over time, because scope expansion often signals consent phishing, compromise, or policy bypass.

Key takeaways

• The Vercel incident shows that delegated OAuth access can become a breach path when a third-party app is compromised.
• The attack chain moved from token theft to legitimate Google Workspace access, proving that valid consent can still produce unsafe access.
• Continuous grant inventory and fast revocation are the controls that matter most when broad OAuth scopes sit inside the enterprise identity estate.

Key terms

• OAuth Grant: An OAuth grant is the delegated permission an application receives to act on a user's behalf without storing the user's password. In NHI governance, it should be treated as a standing identity relationship with scope, ownership, and revocation requirements, not as a one-time setup detail.
• Consent scope: The exact set of accounts, actions, and time boundaries a user has approved for a third-party application. In regulated financial workflows, scope is not static. It must be checked whenever data is fetched or a transaction is initiated so access does not exceed the original approval.
• Third-Party OAuth Integration: A third-party OAuth integration is an external application that receives delegated access to a SaaS environment through user or admin consent. It expands the attack surface because the integration can become a trusted access path, so security teams must classify and monitor it like any other privileged NHI.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.

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.