A Vercel employee connected an AI office tool to their corporate Google account. Two months later an infostealer at that vendor turned the OAuth grant into a bypass of Vercel's MFA

One "Allow All" Click, Two Companies Breached

🔴 REAL INCIDENT: Vercel / Context.ai — OAuth supply chain compromise via AI SaaS vendor (February – April 2026)

What Happened

In February 2026, an employee at Context.ai — a third-party AI productivity platform — was infected with Lumma Stealer, a commodity infostealer that has been sold on criminal forums for years. It is not sophisticated. It is not novel. It harvests credentials from a compromised machine and sends them somewhere.

Among what it harvested were the authentication credentials belonging to Context.ai's application itself.

That should have been a bad day for Context.ai and a non-event for everyone else. It was not, because of something that had happened earlier at an entirely different company.

At some point before the infection, at least one Vercel employee had signed up for Context.ai's AI Office Suite using their Vercel enterprise account — and, at the consent screen, granted the application "Allow All" permissions. Vercel's internal OAuth configuration permitted that grant to attach broad access to the company's enterprise Google Workspace.

So when the attacker took possession of Context.ai's application credentials, they took possession of every OAuth token those credentials could exercise. Including the one pointing at Vercel.

The attacker used it. They accessed the Vercel employee's Google Workspace account directly — with no password and no MFA challenge, because an OAuth token that has already been issued does not re-authenticate. Multi-factor authentication is a control on the login event. There was no login event.

From there the attacker moved into Vercel's internal systems and reached the platform's environment variable store, where they were able to enumerate and decrypt variables — including API keys and database credentials belonging to Vercel customers.

On or around April 19, 2026, a threat actor operating under the ShinyHunters brand posted to BreachForums claiming to have breached Vercel and offering the dataset for $2 million. Vercel disclosed the incident the same day, confirming unauthorized access to internal systems and a limited subset of customer credentials. On April 20 the company reported it had worked with Microsoft, GitHub, npm, and Socket and found no evidence that its npm packages had been compromised — a meaningful check, given what a poisoned Vercel package would have reached.

Two companies breached. The entry point was a consent screen.

The Technical Breakdown

OAuth tokens are a permanent, MFA-immune credential, and almost nobody treats them like one. This is the central lesson and it deserves stating plainly. Enterprises have spent a decade hardening authentication: phishing-resistant MFA, conditional access, device trust, impossible-travel detection. All of that governs how a session begins. An OAuth refresh token is a durable grant that begins nothing — it simply continues to be valid, silently, until someone explicitly revokes it. The attacker in this incident never authenticated as the Vercel employee. They presented a token that Vercel had already agreed to honor.

"Allow All" is a permission decision made by whoever is least equipped to make it. The employee who connected the AI Office Suite was not performing a security review. They were trying a tool. The consent screen asked for broad Workspace access, and the obvious action to get the tool working was to approve it. That single click granted a third party — whose security posture nobody at Vercel had assessed — durable programmatic access to a corporate identity. In most enterprises, granting an outside vendor that level of access requires a procurement process, a security questionnaire, and a signed agreement. Through OAuth, it requires a button.

The vendor's blast radius was never scoped, because the vendor was never onboarded. Context.ai was not a Vercel supplier in any process sense. There was no DPA, no vendor risk assessment, no offboarding path. It was shadow IT that happened to hold enterprise credentials. The attacker's lateral movement did not defeat a control; it traversed a relationship that no control knew existed.

Plaintext-recoverable environment variables turned a Workspace compromise into a customer-data compromise. Reaching an employee's Google account is serious. Reaching a store of customer API keys and database credentials that can be enumerated and decrypted is a different magnitude of event, because those secrets authenticate against other people's infrastructure. The blast radius extended past Vercel to every customer whose credentials sat in that store — the classic platform amplification problem, where one provider compromise fans out across a customer base.

The initial vector was entirely unremarkable. No zero-day. No AI-specific exploit. No prompt injection. Commodity infostealer malware on one employee laptop at a vendor most Vercel staff had never heard of. The AI angle is not that AI was attacked — it is that a fast-moving category of AI SaaS tools has been adopted across enterprises through consent screens rather than procurement, creating a dense mesh of unreviewed OAuth grants between companies with wildly different security maturity.

The Broader Pattern

The Cloud Security Alliance's research note on this incident frames it as an AI SaaS supply chain attack, and that framing is the right one. The novelty is not the technique — OAuth token abuse and infostealer-to-lateral-movement chains are well documented. The novelty is the topology.

AI productivity tools have been adopted faster, and with less governance, than any previous software category. They are individually trialed, they integrate by OAuth because that is the frictionless path, and they request broad scopes because broad scopes are what makes an "AI assistant for your whole workspace" work. The value proposition of the category is literally give me access to everything so I can be useful across everything. That proposition, granted at an individual's discretion, to a startup whose security program is eighteen months old, is the structural condition this incident exploited.

It connects directly to the McKinsey Lilli agent hack and the Meta rogue agent SEV1: in each case the technical failure was in an authorization model, not a model's behavior. It is also the identity-layer counterpart to the LiteLLM PyPI backdoor — same supply chain logic, except the poisoned artifact is an OAuth grant rather than a package version. Saviynt's 2026 CISO AI Risk Report found 86% of organizations do not enforce access policies for AI identities and only 5% are confident they could detect or contain a compromised agent. An OAuth grant to an AI vendor is an AI identity in your tenant, and it is the least-monitored one you have.

The 2026 incident data points the same way: autonomous agents and AI integrations now account for more than one in eight reported AI breaches, while only about a fifth of executives claim full visibility into agent permissions. You cannot revoke what you have not enumerated.

How It Could Have Been Prevented

Disable user-consented OAuth grants for third-party apps in your enterprise tenant. Google Workspace, Microsoft 365, and Okta all support admin-consent-only configurations for apps requesting sensitive scopes. This is a single policy change and it is the control that would have stopped this incident at the consent screen. It is disabled by default in most tenants because enabling it creates friction — which is the entire point.

Maintain a live inventory of every OAuth grant against corporate identities, and review it on a schedule. You cannot revoke grants you do not know about. Most enterprises running this audit for the first time find dozens of applications holding active tokens, including from vendors that no longer exist.

Set maximum token lifetimes and force periodic re-consent. A grant that expires in ninety days limits an attacker to a ninety-day window rather than an indefinite one. Durable refresh tokens are convenient precisely because they never make anyone re-decide anything.

Put AI SaaS tools through vendor risk review before they touch a corporate identity — not after they become load-bearing. The speed of AI tool adoption is exactly why this matters. A lightweight, fast review that actually runs beats a thorough review that teams route around via a consent screen.

Encrypt secrets so that platform-level access does not yield plaintext. Customer environment variables that can be enumerated and decrypted from an internal compromise convert one incident into hundreds. Envelope encryption with keys the application tier cannot unilaterally retrieve raises the cost of this step substantially.

Monitor for OAuth-authenticated access that never produced a login event. Access to a Workspace account with no corresponding authentication is anomalous by construction. Most SIEM deployments alert on failed logins and impossible travel, and are silent about token-based access that skipped login entirely.

Have a revocation runbook that assumes vendor compromise. When an AI vendor is breached, the question "which of our identities hold active grants to them, and how fast can we kill all of them?" should have a rehearsed answer measured in minutes.

The Lesson

There is a version of this incident that reads as a Vercel failure, and a version that reads as a Context.ai failure. Both are too narrow.

The actual failure is that the modern enterprise has two entirely separate paths by which an outside company can obtain access to its data. The first is procurement: contracts, security review, DPAs, an offboarding process, an owner. The second is an employee clicking "Allow All" on a consent screen at 3pm on a Tuesday. The second path grants comparable access, leaves no contractual trail, has no owner, and is invisible to the teams responsible for the first path.

AI tooling has made the second path enormously more trafficked, because the whole category is built on broad workspace access and instant self-serve integration. Every one of those grants is a durable, MFA-immune credential held by a third party, living in your tenant, surviving password rotations and device changes and, in many cases, the employee's departure.

Vercel's response was fast and transparent, and the npm verification work was the right instinct — they went looking for the worst downstream case rather than waiting to be told about it. None of that changes the shape of the exposure. The breach did not begin with an attack on Vercel. It began with a routine productivity decision that no security process was positioned to see.

Open your Google Workspace or Microsoft 365 admin console and pull the list of third-party applications holding active OAuth grants against your domain. Count the ones you recognize. Count the ones that were reviewed by anyone. Now count the ones with broad scopes. Every entry in that last group is a company whose worst day becomes your worst day.

Sources

Vercel Knowledge Base — "Vercel April 2026 security incident," April 19–20, 2026
The Hacker News — "Vercel Breach Tied to Context AI Hack Exposes Limited Customer Credentials," April 2026
Cloud Security Alliance Labs — "AI SaaS as Enterprise Attack Vector: The Vercel–Context.ai Breach," 2026
Dark Reading — "Vercel Employee's AI Tool Access Led to Data Breach," April 2026
Trend Micro — "The Vercel Breach: OAuth Supply Chain Exposes the Hidden Risk in Platform Environment Variables," April 2026