Vercel OAuth breach shows how shadow AI turns identity into risk

At a glance

What this is: This is an analysis of the Vercel breach and its central finding: shadow AI and previously approved OAuth access created a path that perimeter tools could not distinguish from legitimate vendor activity.

Why it matters: It matters because IAM, IGA, PAM, and cloud teams now have to govern third-party AI access as live identity risk, not as static application onboarding.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.

👉 Read Oleria Security's analysis of the Vercel OAuth breach and shadow AI risk

Context

OAuth grants are a governance decision, not just an authentication event. In this case, a third-party AI integration obtained access through an employee-approved consent flow, which meant the identity team never had a complete picture of who held access, how long it remained active, or how it was later used. That is a primary identity governance failure, not a perimeter failure.

The primary lesson for NHI and IAM programmes is that approved third-party access can become attacker access without changing the credential shape. When the same OAuth token serves both the intended vendor workflow and the malicious post-compromise workflow, policy alone cannot separate benign from hostile activity. The starting position here is increasingly typical, not exceptional.

This breach also exposes the limits of treating AI vendors like ordinary SaaS applications. A vendor acting inside your environment with delegated scopes is part of your identity surface, and identity controls have to track consent, usage, scope, and offboarding together.

Key questions

Q: How should security teams govern third-party AI agents that use OAuth access?

A: Security teams should treat third-party AI agents as governed non-human identities, not informal integrations. Require inventory, named ownership, scoped OAuth permissions, periodic review, and a fast revocation path. The goal is to prevent delegated access from becoming an invisible privilege layer that can reach internal systems without clear accountability.

Q: Why do approved OAuth grants create hidden identity risk for enterprises?

A: Because the grant can be legitimate, durable, and still dangerous. If a third-party app is later breached, the attacker inherits the same token, scopes, and trust relationship as the vendor. That makes normal and malicious activity look alike unless identity teams monitor actual usage, not just permissions.

Q: What breaks when organisations rely on periodic access reviews for AI systems?

A: Periodic access reviews break when the identity scope changes between review cycles. AI-enabled workflows can create, use, and retire access faster than reviewers can validate it, so certification no longer reflects reality. That leaves stale permissions active and makes breach exposure harder to detect before it is used.

Q: Who is accountable when a misconfigured AI integration or trusted update path is exploited?

A: Accountability should sit with the control owners for identity, application delivery, and risk governance, not only with vulnerability management. If the path involved privileged credentials, build pipelines, or an AI integration, those owners must be part of the remediation and assurance model because the failure crossed multiple domains.

Technical breakdown

OAuth consent grants create durable delegated access

OAuth is an authorisation standard that lets a user grant an application limited access to resources without sharing a password. In practice, the grant can outlive the original approval moment and remain valid until revoked, which makes the consent event only the beginning of governance. If the app is later compromised, the attacker inherits the same scopes, endpoints, and trust relationship as the legitimate integration. That is why OAuth is not just an application problem. It is a delegated identity problem that needs lifecycle control, scope review, and resource-level monitoring.

Practical implication: inventory every high-value OAuth grant, tie it to a named owner, and review the actual scope before the next access review cycle.

Shadow AI expands the identity perimeter beyond procurement

Shadow AI is unmanaged or undiscovered AI tooling that receives access through ad hoc user consent, browser extensions, or personal experimentation. The security issue is not simply that the tool exists. The issue is that its identity footprint can be granted outside procurement, outside formal onboarding, and outside the visibility of identity governance tooling. Once it has access to Google Workspace, source control, cloud control planes, or collaboration systems, it becomes an identity asset with real blast radius. Traditional perimeter tools see traffic, not the legitimacy of the delegated relationship behind that traffic.

Practical implication: correlate consent records, app registrations, and usage telemetry so unmanaged AI tools can be found before they become trusted identities.

Usage context is the missing control plane for AI vendor access

The article’s core technical point is that permission visibility is not enough when approved and malicious access use the same token. Identity teams need to know who granted access, what scope was approved, which resources were touched, and whether the observed usage matches the expected integration pattern. That is a context problem, not a logging volume problem. Without contextual baselines, an attacker can operate inside the approved path and look normal to conventional controls. In other words, the real control plane is not just the grant. It is the ongoing comparison between expected and observed use.

Practical implication: build detections around abnormal resource usage, not just privilege changes, and make vendor compromise a first-class scenario in response playbooks.

Threat narrative

Attacker objective: The attacker’s objective was to turn trusted delegated access into broad internal visibility and monetisable credentials.

1. Entry occurred through a previously approved third-party OAuth grant tied to a Google Workspace account, which gave the integration delegated access inside Vercel’s environment.
2. Credential access followed when the compromised vendor relationship allowed the attacker to use the same token and scopes that the legitimate integration relied on.
3. Impact emerged through environment enumeration and reported attempts to monetise access keys, source code, NPM tokens, and GitHub tokens on a hacking forum.

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.
• 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

Approved OAuth access is now an NHI governance problem, not a convenience feature. The Vercel case shows that delegated access granted to a third-party AI tool can persist beyond the original business context and remain exploitable after the vendor is compromised. Identity teams cannot treat consent as a one-time event when the resulting token can be used to traverse internal systems. The practitioner conclusion is that consent, scope, and ongoing usage all need continuous governance.

Shadow AI is the new unmanaged service account problem, but with wider blast radius. The control failure is not limited to the vendor itself. An employee can create a trusted integration path outside procurement, and that path can later become indistinguishable from legitimate vendor behaviour. The implication is that discovery must include user-approved AI tools, not just sanctioned enterprise applications.

Permission-centric monitoring breaks when attacker and vendor share the same token. This breach worked because the approved identity and the malicious identity were operationally identical at the credential layer. That collapses the assumption that access logs alone are enough to spot misuse. Practitioners should recognise this as a usage-context gap, where the missing control is continuous validation of how delegated access is actually being exercised.

Identity context graphs are becoming a control requirement for AI-era governance. When a vendor, an employee, and an AI integration all share overlapping access paths, identity programmes need a way to correlate grantor, scope, resource, and usage in one place. The field is moving from entitlement review to relationship review. That means IAM, IGA, and NHI teams must work from the same access graph, or they will keep missing the same hidden dependencies.

Third-party AI access should be governed as lifecycle-managed NHI, not as a simple SaaS integration. The article’s real message is that vendor-managed identities can hold durable access into core systems and must be offboarded, reviewed, and monitored like any other non-human identity. The practitioner conclusion is straightforward: if the integration can act inside your environment, it belongs in your NHI governance model.

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.
• Another finding from The 2024 ESG Report: Managing Non-Human Identities shows that 72% of organisations have experienced or suspect a breach of non-human identities.
• The next control question is not whether access exists, but whether identity teams can correlate grant, usage, and ownership fast enough to contain vendor compromise.

What this signals

Shadow AI is now a governance category, not a side effect. The operational lesson for identity teams is that user-approved AI tools can bypass procurement and still hold lasting access into core systems. That means discovery programmes must extend into browser-installed tools, ad hoc integrations, and OAuth consent flows if they are to give useful coverage.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, the issue is structural. Existing IAM programmes were built to govern entitlements, not to watch how delegated access changes after approval.

Identity context graph: the practical requirement is a control model that ties consent, scope, resource usage, and owner responsibility together. Without that linkage, an AI vendor compromise becomes a visibility failure first and an incident response problem second.

For practitioners

• Inventory all delegated AI and OAuth access Create a single register of every third-party AI tool, copilot, agent platform, and extension with access to identity providers, collaboration suites, source control, and cloud control planes. Record grantor, grant date, scope, last use, and business owner so the trust chain is visible.
• Re-consent high-risk scopes and remove dormant grants Force review or re-consent for any integration with domain-wide delegation, deployment-level privileges, or write access to repositories and cloud systems. Revoke anything that cannot justify active use or whose ownership is unclear.
• Shift detections from permissions to usage Build alerting around unusual resource access, scope consumption, and changes in vendor behaviour rather than only on new grants. Compare expected integration patterns with actual query, export, and enumeration activity.
• Add vendor compromise to incident playbooks Define a response path for third-party AI vendor compromise that assumes the vendor may be the source of legitimate-looking malicious activity. Include steps for token revocation, scope review, and downstream access tracing before attackers finish enumerating resources.
• Govern AI vendors as lifecycle-managed NHIs Treat each externally delegated AI integration as a non-human identity with onboarding, periodic review, and offboarding requirements. Tie ownership to a named business sponsor and require evidence of how OAuth tokens are stored, monitored, and retired.

Key takeaways

• The breach shows that approved third-party OAuth access can become an attack path without any new vulnerability being found.
• The scale of the problem is broad, because most organisations still cannot fully see which vendors and apps hold delegated access.
• Identity teams need lifecycle governance and usage monitoring for AI integrations, or approved access and attacker access will remain indistinguishable.

Key terms

• 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.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Security Context Graph: A Security Context Graph is a relationship model that connects users, assets, identities, and behaviour so alerts can be judged against known organisational context. It helps investigators distinguish unusual activity from expected operations by adding ownership, access, and workflow information to raw telemetry.
• 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.

What's in the full article

Oleria Security's full post covers the operational detail this post intentionally leaves for the source:

• A deeper walkthrough of the Vercel access chain, including how the OAuth consent path was created and why it escaped central visibility.
• The specific telemetry and identity-context signals Oleria says are needed to distinguish normal vendor activity from attacker activity.
• A detailed breakdown of how the Identity Context Graph correlates human, non-human, and AI identities across systems.
• The vendor's recommended response sequence for third-party AI compromise and access tracing.

👉 Oleria Security's full post covers the access chain, visibility gap, and response priorities in more detail.

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 identity security programme, it is worth exploring.