Vercel OAuth breach shows how shadow AI turns identity into risk

At a glance

What this is: This is an analysis of how Vercel’s breach leveraged a third-party AI integration and approved OAuth access rather than a new exploit path.

Why it matters: It matters because IAM, IGA, and PAM teams need to govern third-party AI grants as active identity relationships, not static permissions, when approved access and attacker access can converge.

Context

OAuth grants let an external application act inside an organisation’s identity and resource boundaries with the scopes the user or admin approved. In this case, that control broke down because a third-party AI integration was granted access through an employee account, creating a shadow AI identity that security teams did not centrally govern.

The governance gap is not authentication at the front door. It is the lack of lifecycle control and usage visibility after consent, especially when the approved vendor account can be breached and reused with the same scopes. For identity programmes, the problem sits at the intersection of NHI governance, third-party access review, and shadow AI discovery.

Key questions

Q: What breaks when a third-party AI integration is approved but not governed as an identity?

A: The control that breaks is ownership of the delegated grant. Once a user can approve an AI tool with enterprise OAuth scopes outside central review, the organisation loses reliable inventory, lifecycle control, and behavioural context. That leaves security teams unable to distinguish a legitimate vendor from a compromised one using the same access.

Q: Why do approved OAuth scopes create risk when an AI vendor is compromised?

A: Because the attacker inherits the same delegated authority the vendor used legitimately. OAuth does not care whether the caller is the original app or a malicious actor using its token, so the permission layer alone cannot separate normal activity from abuse. Risk rises sharply when scopes are broad or long-lived.

Q: How do security teams know whether third-party apps and AI tools are operating outside their intended boundary?

A: Teams should look for unmanaged connectors, unexpected data transfers, excessive API calls, and applications that access more data than their business purpose requires. A healthy environment shows clear inventory, policy enforcement, and audit trails across connected systems. If an app cannot be tied to an approved purpose and data scope, it is operating outside control.

Q: What should organisations do when an AI vendor has already been granted access to sensitive systems?

A: Treat the grant like any other high-risk third-party identity relationship. Review scope, owner, last use, and revocation path, then re-consent or remove anything that is no longer needed. The objective is to shrink the number of live delegated paths that could be inherited by an attacker.

Technical breakdown

How approved OAuth scopes become a reusable attack path

OAuth delegated access is not the same as a password or session token tied to one person. Once a user approves scopes, the external application can call APIs and read or act on resources within that delegated boundary until the grant is revoked or expires. If the integration is a third-party AI tool, the organisation often sees only the consent event, not the operational behaviour behind it. That creates an identity blind spot: the grant may look legitimate at approval time, yet remain exploitable later if the vendor or its token handling is compromised.

Practical implication: treat OAuth consent as a governed identity event and track its scope, ownership, and revocation state continuously.

Why shadow AI makes legitimate and malicious access indistinguishable

Shadow AI appears when employees connect unmanaged AI tools to corporate systems without central review. The tool then operates under approved enterprise scopes, but the security team lacks context on its expected behaviour, usage pattern, or data footprint. When the vendor is breached, the attacker inherits those same scopes and endpoints. Because the access is technically valid, perimeter controls and permission checks often cannot tell whether a request came from the vendor’s normal workload or from an intruder using the same token.

Practical implication: baseline normal usage per integration so anomalous behaviour can be detected at the resource and activity level.

Why permission-level controls miss usage-level abuse

Traditional IAM tools are good at asking who has access, but weak at answering what that identity is doing with the access right now. For third-party AI integrations, that distinction matters because the risk is not just possession of a grant, but misuse of a valid grant in a different operational context. Identity Context Graph style visibility is aimed at correlating identity, resource, and activity signals so defenders can reconstruct who accessed what, when, and how. Without that context, an approved AI vendor and a compromised AI vendor can be operationally indistinguishable until data moves or keys are exposed.

Practical implication: build telemetry that links OAuth grants to actual resource use, not just to entitlement records.

Threat narrative

Attacker objective: The attacker’s objective was to leverage trusted third-party access to enumerate the environment and extract valuable secrets and source-code assets.

1. Entry occurred through a third-party AI integration that had already been granted OAuth scopes inside Vercel’s environment.
2. Credential and access reuse followed when the breached vendor’s existing scopes were used to enumerate internal environments.
3. Impact emerged as the attacker reportedly sought keys, source code, and tokens, turning legitimate delegated access into a data-exposure path.

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.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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

NHI Mgmt Group analysis

Shadow AI identity is a governance problem before it is a detection problem. The article shows that an employee can approve a vendor integration with enterprise scopes outside formal procurement and create a live identity relationship the organisation never inventories. That breaks the assumption that all privileged external access is centrally known. The practitioner implication is that discovery and ownership of third-party AI access must be treated as core identity governance, not optional hygiene.

Approved OAuth access becomes a shared attack surface when the vendor is breached. The same delegated scopes that let the AI vendor do legitimate work also let an intruder act with equivalent authority if the vendor is compromised. That is not a perimeter failure; it is a trust-boundary failure. The implication is that organisations must rethink third-party access as an active operational dependency, not a one-time consent record.

Usage-level visibility is the named concept this breach reinforces. Resource-level context is what separates a granted permission from an abused permission when both use the same token. The article makes clear that permission inventories alone cannot distinguish vendor activity from attacker activity. The implication is that identity programmes need behavioural context around every high-risk OAuth grant, especially for AI tools.

Third-party AI access outlives the moment of approval unless lifecycle control exists. The consent event is only the beginning of the governance problem, because access can remain in place long after the business need, the employee owner, or the vendor risk posture changes. That assumption was designed for stable vendor relationships, not fast-moving shadow AI adoption. The implication is that offboarding, review, and re-consent need to be tied to real usage, not calendar cycles.

Identity has become the control plane for AI vendor risk. The article’s central lesson is that AI vendors are not merely data processors, they are actors operating inside customer scopes. That means the security team has to evaluate who can act, under what consent, and with what observable footprint. The practitioner conclusion is that AI governance now belongs inside identity governance, not beside it.

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: NHI Lifecycle Management Guide

What this signals

Usage-level visibility is now the control boundary for shadow AI. Organisations that only track who approved a grant will miss the more important question of what the integration is actually doing with enterprise scopes. The operational shift is toward correlating OAuth consent, resource activity, and ownership in one reviewable model.

Third-party AI access should be governed as a live NHI relationship. Once an external app can act in your environment, it behaves like a machine identity with delegated authority and a lifecycle that must be owned, reviewed, and offboarded. That is why shadow AI discovery belongs in the same programme as NHI inventory and third-party access governance.

For practitioners

• Inventory all third-party AI grants Build a complete register of copilot, agent, and AI app OAuth grants across identity providers, collaboration suites, code repositories, and cloud control planes, including grantor, grant date, scopes, and last observed use.
• Flag high-risk delegated scopes Prioritise any integration with deployment-level, domain-wide, or write-level scopes for review, because those grants can expose source code, tokens, and administrative resources if misused.
• Re-consent or revoke inactive vendors Force re-consent, rotation, or revocation for AI vendors that are no longer active, or that cannot explain how their tokens are stored, rotated, and monitored on their side.
• Add vendor-compromise response paths Update incident response playbooks so a third-party AI vendor compromise can be contained from your side without waiting for vendor notification or a permission change.
• Baseline normal usage for each integration Track resource, frequency, and action patterns for every approved AI integration so abnormal behaviour stands out when the same OAuth grant is abused.

Key takeaways

• The breach shows that a legitimate third-party AI grant can become an attacker path without any new exploit being found.
• The critical failure is not the initial consent event alone, but the lack of usage context and lifecycle control after approval.
• Identity teams need inventory, behavioural baselines, and a revocation path for every external AI integration with enterprise scopes.

Key terms

• 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.
• 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.
• Usage Visibility: The ability to see how identities, credentials, and resources are actually being used across the environment. It is the evidence layer that turns access governance from assumption into decision, and it is essential for removing dormant access safely.
• Delegated access lifecycle: Delegated access lifecycle is the governance of non-human components that act on behalf of others, including onboarding, permission scoping, recertification, and offboarding. For MCP servers, it means treating the server itself as a governed identity object with a defined blast radius.

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.