OAuth app compromise shows the real NHI risk in Vercel integrations

At a glance

What this is: Astrix Security examines a Vercel-linked OAuth app compromise that spread through connected non-human identities and exposed the governance gap in third-party app trust.

Why it matters: It matters because IAM and NHI teams need to govern OAuth apps, service accounts, and automation as an identity estate, not as isolated integrations.

Context

OAuth app risk is not just an application-integration issue. In this incident, a third-party AI tool gained delegated access through Google Workspace OAuth and became a foothold into Vercel-connected systems, showing how NHI trust can be inherited across platforms.

The governance gap is familiar: developers approve access, integrations persist, and the organisation later loses sight of which service accounts, tokens, browser extensions, and automation workflows are still active. Once that trust chain is established, the security boundary shifts from the app to the identity relationship.

For teams running developer platforms, the question is not whether an integration exists but whether the organisation can explain why it exists, what it can reach, and who is accountable for its lifecycle.

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 third-party OAuth integrations create such a large attack surface?

A: They extend trust beyond the primary platform into every downstream system the app can touch. If the integration can read or write code, tokens, or deployment data, a compromise of the supplier or app can turn into access across multiple environments. The risk grows when approvals are developer-driven and never revalidated against current business need.

Q: How do teams know whether OAuth token governance is actually working?

A: Look for short token lifetimes, tested revocation, no tokens in logs, and a clean mapping from each integration to an accountable owner. If disconnected apps still retain access, or if nobody can explain which scopes are approved, the programme is functioning on paper only.

Q: Should organisations treat OAuth apps differently from service accounts?

A: Yes. OAuth apps are delegated identities with consent-based scope, while service accounts are usually provisioned for controlled system-to-system work. The governance model should reflect that difference: consent, review, and reauthorisation for OAuth apps, and lifecycle, privilege, and rotation controls for service accounts. Both still belong in the NHI estate.

Technical breakdown

How a delegated OAuth foothold becomes an NHI trust chain

OAuth apps do not authenticate like human users. They operate through delegated authorisation, where the app receives scoped access tokens after approval, then uses those tokens to act on behalf of the connected tenant or workspace. In a developer platform context, that access can fan out into service accounts, CI/CD hooks, API tokens, and automation workflows. The weakness is not the protocol itself but the accumulated trust built into integrations that outlive their original purpose. Once the app is installed, the environment often treats it as trusted infrastructure rather than a governed identity.

Practical implication: treat each OAuth app as a governed NHI with a lifecycle, scope, and owner, not as a one-time integration approval.

Why third-party compromise turns into downstream credential exposure

When a supplier or connected app is compromised, the attacker does not need to break the primary platform first. The compromise can expose the tokens and keys already available to that integration, then move laterally through adjacent developer systems and internal tools. In this article, the alleged exposure included access keys, source code, database information, API keys, NPM tokens, and GitHub tokens. That is a classic delegated-access problem: the compromise boundary sits outside the primary tenant, but the privileges extend into the tenant’s most sensitive workflows.

Practical implication: classify connected apps by access scope and downstream reach, then remove any integration whose blast radius exceeds its business purpose.

Why monitoring human logins misses NHI behaviour

Most SOC telemetry is still built around human identity signals such as interactive sign-ins and MFA events. OAuth apps, service accounts, and automation workflows often generate no human-like login trail, so they can keep operating even while their behaviour changes. The article points to anomaly detection on NHI behaviour, which is the right direction: unusual source IPs, unexpected target resources, and access patterns that diverge from a baseline are often the only practical indicators of misuse. Without that layer, a compromised integration can look like normal machine activity until the damage is already done.

Practical implication: extend detection from user sessions to NHI behaviour baselines across OAuth apps, tokens, and automation workflows.

Threat narrative

Attacker objective: The attacker’s objective was to harvest delegated credentials and use them to reach downstream developer systems, source code, and related internal data.

1. Entry occurred through a compromised third-party OAuth app that had been granted delegated access to Vercel-connected systems.
2. Credential access followed as the alleged attacker activity included stolen access keys, API keys, GitHub tokens, and NPM tokens tied to internal deployments.
3. Escalation and lateral movement then extended through connected NHI estates, including service accounts, CI/CD integrations, browser extensions, and automation workflows.
4. Impact was the exposure of connected developer environments and internal systems across thousands of organisations.

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 our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth app trust is now an NHI governance problem, not an integration hygiene problem. The article shows that a single delegated app can inherit enough privilege to touch code, tokens, and automation across multiple platforms. That changes the control plane from application approval to identity lifecycle governance, where ownership, scope, and revocation matter more than whether the app was once legitimate. Practitioners should treat OAuth-connected apps as part of the identity estate.

Delegated access creates identity blast radius that most teams still do not model. The Vercel incident shows how a compromised supplier can expose far more than its own tenant boundary once tokens, CI/CD hooks, and developer tools are chained together. The key concept here is delegated access blast radius: the distance between a granted OAuth permission and the downstream systems it can silently reach. Teams need to map that blast radius before they can govern it.

Standing trust in third-party integrations is the broken assumption this incident exposes. OAuth approval was designed for a world where access could be reviewed, explained, and revoked before misuse accumulated. That assumption fails when the integration becomes a persistent machine identity with broad reach across development and production workflows. The implication is that review cadences alone are not enough if the trust relationship itself is never forced back through reauthorisation.

Human-centric monitoring leaves the NHI layer effectively invisible. The article’s emphasis on NHI behaviour is important because service accounts and automated workflows do not produce the same evidence trail as employees. A SIEM tuned for user logins may miss the access pattern entirely, which means detection has to move closer to entitlement scope, resource targeting, and integration provenance. Practitioners should assume machine access will be the first place attackers hide.

Third-party app compromise is becoming a supply-chain pattern for identity abuse. This is not a one-off Vercel problem, but a repeatable way to pivot from one compromised integration into many connected tenants. The governance lesson is that vendor risk and identity risk now overlap at the point where OAuth consent, platform permissions, and unmanaged NHI inventories intersect. Security teams should evaluate supplier access as a living trust relationship, not a static approval record.

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.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Delegated access blast radius: OAuth consent creates a trust relationship that can reach far beyond the original app, so security teams need to measure how much downstream authority each integration can actually exercise.

The operating model has to shift from isolated app review to continuous NHI lifecycle governance. If service accounts, tokens, and automation workflows are only checked at install time, the organisation will discover the real risk after compromise instead of before it.

The scale problem is not trivial: 92% of organisations expose NHIs to third parties, according to the Ultimate Guide to NHIs. That makes third-party integration review a core control, not a niche exception.

For practitioners

• Inventory every OAuth-connected integration Build a platform-by-platform list of OAuth apps, service accounts, tokens, and automation workflows across GitHub, Google Workspace, Slack, Chrome, Microsoft 365, Jira, and similar systems.
• Classify integrations by effective blast radius Rank each connected app by the resources it can reach, the data it can read or write, and whether it can touch production, source code, or deployment systems.
• Revoke unexplained delegated access Remove any integration whose purpose, owner, or approval path cannot be verified quickly, even if it was once legitimate.
• Baseline NHI behaviour separately from user activity Verify that detection coverage includes source IP, target resource, and access-pattern baselines for machine identities, not only interactive logins and MFA events.
• Separate monitored from unmonitored environments Confirm that the same identity review process covers every workspace, tenant, and development environment, including those outside the primary monitoring stack.

Key takeaways

• The incident shows that a compromised OAuth app can become a trusted pivot into developer systems, source code, and deployment data.
• The governance failure is delegated NHI access that persists after the original approval context has been lost.
• The most effective control is not just inventory, but scope-based review and rapid revocation of unexplained integrations.

Key terms

• OAuth App Token: An OAuth app token is a credential issued after a user or system grants consent to an application through OAuth. It can allow the app to act on behalf of the granting identity, sometimes across multiple repositories or resources. If over-permissioned, it becomes a high-value target for abuse.
• 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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Privileged NHI Inventory: A current record of non-human identities that hold elevated access or can reach high-value systems. This inventory is only useful when it is accurate, owned, and continuously updated, because stale records create a false sense of control and hide the identities most likely to expand attack impact.

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.