Vercel breach shows shadow AI is a governance blind spot

At a glance

What this is: This is a breach-analysis style post about how an unapproved AI tool, broad OAuth permissions, and a stolen token combined into a real attack chain at Vercel.

Why it matters: It matters because IAM, NHI, and security teams need governance over SaaS-connected identities, not just sanctioned apps and endpoint controls.

By the numbers:

• 78% of employees use AI tools like ChatGPT and Claude.
• Only 30% of organizations have full visibility into what those tools are.

👉 Read Josys’s analysis of the Vercel breach, shadow AI, and OAuth exposure

Context

Shadow AI is what happens when employees connect unsanctioned AI tools to work accounts and data flows without identity governance. In this case, the governance gap was not a missing password policy, but the absence of control over who could grant OAuth access to third-party tools and what those tools could reach.

The Vercel breach shows how quickly a work account can become an external access path once permissions are delegated outside IT review. For identity teams, the real problem is not just software sprawl, but unmanaged permission chains that link human identity, SaaS access, and non-human tokens into one breach surface.

Key questions

Q: How should security teams govern employee-approved AI tools that request OAuth access?

A: Treat every consented AI app as a governed identity relationship, not an informal productivity choice. Review requested scopes before approval, bind each app to a business owner, and define revocation criteria up front. If the tool can reach mail, files, or directories, it should pass the same access scrutiny as any other third-party integration.

Q: Why do OAuth tokens create more risk than passwords in shadow AI incidents?

A: OAuth tokens can keep working after the original user login is gone, which makes them durable bearer credentials. If an attacker steals the token, they may bypass password resets and MFA entirely until the token expires or is revoked. That is why token lifecycle control matters as much as authentication policy.

Q: What breaks when organisations cannot see employee AI tool integrations?

A: Access governance breaks because IT cannot tell which external services have inherited enterprise identity or what data they can reach. That makes review, containment, and offboarding incomplete. In practice, teams lose the ability to trace who approved access, which scopes were granted, and whether the app still needs those permissions.

Q: Who is accountable when a shadow AI app exposes enterprise data through OAuth?

A: Accountability usually sits across the user, the business owner, and the security team, but the organisation must make one party responsible for each consented app. Without an assigned owner, revocation and review are delayed, and the access path remains active even after the tool or vendor is compromised.

Technical breakdown

OAuth consent abuse and shadow AI entry

OAuth consent is a delegated authorisation model. A user grants an application specific scopes, and the app inherits access that can outlive the moment of approval if the token remains valid. In shadow AI cases, the entry point is not malware on the endpoint alone, but a legitimate consent flow that was never reviewed by IT. That makes the identity boundary the real control plane. Once the employee approved broad permissions, the external tool could act within the trust envelope of the user account and its connected services.

Practical implication: restrict unreviewed OAuth app consent and require policy checks before third-party AI tools can inherit work-account access.

Stolen OAuth tokens and workspace persistence

An OAuth token is a bearer credential, which means possession is enough to use it until it expires or is revoked. If an attacker steals the token from a compromised endpoint, they do not need the user’s password or MFA challenge to continue the session. That changes the incident profile from authentication failure to delegated-access failure. In this breach pattern, visibility into endpoint compromise is not enough, because the durable risk sits in the token’s remaining authority across Google Workspace and downstream systems.

Practical implication: centralise token revocation and app offboarding so stolen OAuth grants can be cut off before they spread across connected systems.

Shadow AI as an identity governance problem

Shadow AI is not just an application inventory issue. It is a governance failure where users create unsanctioned identity links between enterprise accounts and external AI services. Those links can bypass normal procurement, security review, and lifecycle controls, leaving IT unable to see what permissions exist or who is accountable for them. The consequence is a hidden trust graph that can be attacked through any compromised vendor endpoint, consented app, or reused credential.

Practical implication: map every AI integration to the identity and permission chain it creates, then govern that chain as part of lifecycle management.

Threat narrative

Attacker objective: The attacker aimed to turn delegated SaaS access into internal access and monetisable stolen data.

1. Entry began when an employee connected an unapproved AI service to a work Google account and granted broad OAuth permissions.
2. Credential access followed when malware on the AI vendor’s endpoint exposed the OAuth token, giving the attacker bearer access without needing the employee’s password.
3. Impact followed as the attacker used the token to reach Google Workspace, move into internal systems, and list environment variables before the stolen data was posted for sale.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 creates an identity governance shadow zone: The breach worked because a user could bind an unapproved AI tool to a work account without lifecycle review, contract control, or consent governance. That is not an application hygiene problem, it is an identity governance gap that allows third-party access to appear legitimate while remaining outside accountability. The practitioner conclusion is that any AI integration that can inherit enterprise identity should be treated as governed access, not casual productivity software.

OAuth consent became the real privilege grant: The dangerous moment was not the later compromise, but the original “Allow All” decision that gave the external app durable access scopes. In NHI terms, the app behaved like a delegated non-human identity with standing authority, even though nobody managed it as one. Practitioners should recognise that consent screens are access provisioning events, not user convenience prompts.

Unreviewed SaaS-to-SaaS access is a standing trust problem: This incident shows that trust assumptions built around sanctioned software break once employees can create their own integrations. The approval model assumed that helpful tools would remain safe, visible, and revocable through normal IT processes, but the attacker exploited a token that stayed valid after the vendor’s own incident. That is a classic delegated-access failure: access outlives the control path that was supposed to contain it.

Visibility must extend from endpoints to permission graphs: The post’s central failure mode is not a lack of endpoint security alone, but the inability to see which work identities had created which external access paths. The named concept here is permission-chain blindness: when teams can inventory devices and apps but cannot trace how OAuth scopes, SaaS accounts, and internal data exposure connect. The practitioner conclusion is that governance must follow the chain, not the logo on the app list.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• The NHI Lifecycle Management Guide explains how to govern provisioning, rotation, and offboarding across non-human credentials.

What this signals

Shadow AI is now a lifecycle problem, not just a discovery problem. Once employees can create their own SaaS access paths, teams need a control model that joins app inventory, consent review, and revocation into one operating process, or the organisation will keep learning about risky integrations only after a breach.

With 91.6% of secrets still valid five days after notification, per our Ultimate Guide to NHIs, cleanup speed remains a weak point across credential classes. That same lag shows why token revocation, offboarding, and audit correlation must be treated as a single workflow rather than separate tasks.

For practitioners

• Inventory all third-party AI consents Identify every AI tool that has been granted access through work accounts, then map the scopes, owner, and business purpose for each consented app.
• Block broad OAuth grants by default Require risk review for high-privilege consent screens and limit approval of permissions that expose mail, drive, directory, or admin-related data.
• Treat OAuth tokens as revocable non-human credentials Add token revocation to offboarding, incident response, and vendor exit workflows so a stolen bearer token can be invalidated quickly across connected services.
• Build identity visibility across SaaS integrations Correlate Google Workspace audit logs, app consent logs, and third-party app inventory so hidden access paths can be found before an attacker uses them.
• Review every unsanctioned app as a governance event When employees adopt tools outside procurement, require a formal review that covers data access, scope limitation, accountable ownership, and removal criteria.

Key takeaways

• The breach shows that an employee-approved AI integration can become an enterprise access path without any formal governance gate.
• The attack demonstrates how a stolen OAuth token can outlast the original user action and bypass password-centric assumptions.
• The limiting control is not another policy memo, but identity visibility that tracks consent, scopes, and revocation across SaaS integrations.

Key terms

• Shadow AI: Shadow AI is the use of AI tools, agents, or services that enter an organisation without formal review or governance. In practice, it creates hidden identity and data pathways because users can connect enterprise accounts to outside services that security teams cannot reliably inventory or revoke.
• OAuth Consent: OAuth consent is the user-approved grant that lets an application access specific resources on behalf of an account. For identity teams, it is an access provisioning event that can create durable non-human access if the resulting token, scopes, and revocation path are not governed.
• Bearer Token: A bearer token is a credential that works for whoever possesses it until it expires or is revoked. In shadow AI and SaaS integration incidents, a stolen token can bypass password resets and MFA, which makes token lifecycle control a core part of identity governance.
• Permission-chain blindness: Permission-chain blindness is the inability to trace how a user grant becomes downstream access across apps, SaaS services, and internal data. It is a governance failure because teams may know an application exists, but still cannot see what it can reach or how quickly it should be revoked.

Deepen your knowledge

Shadow AI governance and OAuth token lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for employee-approved AI tools and delegated access, it is worth exploring.

This post draws on content published by Josys covering the Vercel breach: 5 Things the Vercel Breach Reveals About Shadow AI and Your Organization. Read the original.