Shadow AI Part 1: The Vercel 2026 Breach and the Rise of Shadow AI

Introduction

The Vercel breach of April 2026 did not begin with a zero-day, a misconfigured S3 bucket, or a sophisticated nation-state implant. It began when an unreviewed AI tool became a trusted connection without normal security review.

At first glance, the incident looked like another third-party compromise. Context.ai was breached, one employee’s account was impacted, and the attacker moved downstream into a larger technology company. But the deeper lesson is more important: the breached tool – Context.ai, was not part of a formal enterprise deployment. It was not a governed SaaS relationship, and it was not an approved corporate platform with a mature procurement, security review, or lifecycle process behind it. This resulted in a scenario where the attackers got inside Vercel’s internal systems, enumerating customer environment variables, exfiltrating an internal database, and demanding a $2 million ransom that ultimately surfaced for sale on BreachForums.

The Context.ai connection was self-adopted by an employee. It was a consumer-grade AI Office Suite product, not a Vercel enterprise deployment. Context.ai stated that Vercel was not one of its enterprise customers, but at least one Vercel employee used a Vercel corporate Google Workspace account to sign up and grant broad permissions.

This post is a technical autopsy of how that happened including the attack chain, the MITRE ATT&CK mapping, and the defensive posture it demands. But the autopsy is in service of a larger argument: that the OAuth grant in the Vercel chain was a textbook instance of shadow AI, and that the security industry’s traditional tooling was structurally blind to it. Part 2 picks up exactly where this post ends — covers how the chain could have been broken at its origin, before a corporate identity was ever delegated to an unvetted AI tool. 

The Rise of Shadow AI

Shadow IT is not a new problem. It refers to technology adopted by employees without formal visibility, approval, or management by IT and security teams. For years, security teams have fought against this phenomenon. Surveys routinely put the share of unauthorized SaaS in the enterprise at well over half of all apps in use.

Shadow AI is a narrower category, and it is the newest and fastest-growing version of this problem. It has two distinct forms.

The first is AI applications: tools that employees adopt to move faster such as AI meeting note-takers, AI document builders/summarizer, AI coding assistants, AI email assistants, or AI agents connected to Google Workspace, Microsoft 365, Slack, Github or CRM platforms.

The second is LLMs / AI engines and assistants: general-purpose AI platforms such as ChatGPT, Gemini, Claude, or Perplexity.

•       These may begin as simple chat interfaces, but they become a security concern when employees connect them to corporate identities, files, browsers, APIs, MCPs, or enterprise applications.
•       They create data-exposure risk when employees paste sensitive code, or internal documents into the model.
•       They create indirect prompt-injection risk when malicious content inside emails, files, or web pages manipulates a connected AI assistant into taking unintended actions.
•       Once connected, the AI system is no longer just answering prompts, it may be acting through identities, integrations, and permissions security teams never reviewed.

The risk is not that these tools are “AI” by nature. The risk is that useful AI tools often request broad access to corporate data. To summarize meetings, they need calendar and transcript access. To draft emails, they need mailbox access. To generate documents, they need Drive or SharePoint access. In Google Workspace, this can mean OAuth scopes for Gmail, Calendar, Drive, and offline access. In Microsoft 365 environments, equivalent Microsoft Graph permissions may include scopes such as Mail.Read, Calendars.Read, Files.Read.All, Sites.Read.All, or even highly sensitive application-management permissions such as Application.ReadWrite.All. Once granted, these permissions turn the AI tool from a simple productivity app into a delegated access path into corporate data. In the Vercel incident, the employee reportedly granted “Accept All” permissions to Context.ai using their corporate Google Workspace account.

MITRE ATT&CK Mapping

Anatomy of the breach

Vercel is a cloud platform for building and deploying front-end applications, widely used by developers to host and scale sites and serverless functions. Context.ai is a small AI tooling company. In June 2025 it launched a self-serve, consumer-grade product called Context AI Office Suite, an agentic assistant that connects to a user’s Google Workspace and automates actions across it.

The product at the center of the breach was the consumer Context AI Office Suite, not an enterprise deployment. Vercel was not a registered customer of Context.ai at all, thus the Context.ai connection was self-adopted without security review. A single Vercel employee had trialed the consumer tool and, in doing so, granted it OAuth access to their Vercel-issued Google Workspace account.

Initial Compromise

The attack’s origin was an infostealer infection (T1204.002) on a Context.ai employee’s machine. Public reporting states that the employee downloaded Roblox game-exploit scripts, which delivered Lumma Stealer. The malware harvested what infostealers harvest: corporate credentials (T1555), live session tokens (T1539), and OAuth tokens resident on the device.

The important point is that tokens can be more valuable than passwords. A password may still require MFA, but a valid session or OAuth token can already represent an authenticated identity until it expires or is revoked.

The employee granted broad Google Workspace permissions “Allow All” to Context.ai. Technically, this means the employee authorized an OAuth client to access Google APIs on behalf of the user. OAuth access tokens are bearer-style credentials: whoever controls the token can call the authorized APIs within the token’s permission boundaries. 

This makes detection harder because:

• the app appears legitimate because the user approved it, 
• API activity comes from an authorized OAuth client, 
• MFA may not trigger because there is no new interactive login,  
• access remains valid until the token expires or is revoked.

This is where shadow AI becomes a supply-chain pivot (T1199). The Vercel employee’s trial of Context AI Office Suite had created a durable OAuth grant from the consumer tool into their corporate Google Workspace. So, the attacker would simply get the stolen OAuth token and use it to authenticate directly into the Vercel employee’s Google Workspace account (T1528, T1550.001).

Lateral Movement and Internal Reconnaissance

The compromised account did not belong to a low-privilege user. It belonged to a highly privileged developer account (T1078.004). Through the Workspace identity and what it federated to, the attacker reached internal dashboards, employee records, and a lot of API keys, NPM tokens, and GitHub tokens (T1580).

Inside Vercel’s platform, the attacker enumerated customer environment variables. This is where a platform design choice amplified the blast radius: in Vercel’s model, environment variables are treated as non-sensitive by default, and in that default state they are not encrypted at rest. The attacker was able to enumerate and read them (T1552.001).

Exfiltration and Monetization

The endgame was data theft and extortion (T1567): an internal database was exfiltrated, and the attackers demanded a $2 million ransom from Vercel. The stolen data subsequently appeared for sale on BreachForums under the famous ShinyHunters group (T1657). Vercel disclosed the incident on April 19, 2026, and engaged Google Mandiant and others in the response.

Conclusion

The Vercel 2026 breach is one of the clearest examples of Shadow AI becoming a supply-chain pivot. A single employee connected an unmanaged AI tool through an OAuth consent screen. The tool was not officially contracted, reviewed, or governed by security. Once attackers stole tokens from that tool’s vendor, they were able to use that trusted connection to reach the employee’s Google Workspace account and move further into Vercel’s internal systems and secrets. There was no zero-day, no direct phishing of Vercel, and no password to crack – only delegated trust that no one was controlling. 

The Context.ai compromise became a path into Vercel because the AI tool already held a trusted OAuth connection to a Vercel employee’s corporate Google Workspace account.

The main lesson is that the security perimeter has moved to the OAuth grant. Shadow IT is no longer just about employees using unapproved software. It is now about employees granting unapproved permissions to tools that can access corporate data. Traditional controls like Google Workspace settings, OAuth audits, least privilege, token hygiene, and endpoint security are still important. But they mostly help after the risk already exists. The better place to stop the attack is earlier, when the tool is first adopted and the identity bridge is first created.

In Part 2 – Closing the Gap with Unixi Lifecycle Management, we move from breach analysis to prevention. We will look at how Shadow AI can be brought under IT and security governance at that origin point: discovered when employees start using it, gated before corporate identity is delegated, and managed across its lifecycle so that the next Context.ai never becomes the next bridge.