Vercel disclosed a breach on April 19, 2026. The initial reporting called it a security incident. The HN thread called it a supply chain attack. Both are accurate. The precise classification is: an AI SaaS vendor with an agentic feature got popped, a Fortune-500 dev platform engineer used their enterprise Google account to sign up for it, and the OAuth token that CrowdStrike’s March investigation didn’t find provided the keys to Vercel’s internal environments.
The attack was assessed as potentially “AI-accelerated” by Vercel CEO Guillermo Rauch. That framing is interesting. It could mean the attacker used LLMs to accelerate reconnaissance or exploit development. Or it could mean the attacker targeted AI tooling specifically because the blast radius of a successful compromise includes the OAuth grants that AI agents require to function. The second interpretation is the more important one.
The Chain
The sequence, reconstructed from Vercel’s bulletin and third-party analysis:
-
February 2026 — A Context.ai employee’s workstation is infected with Lumma-family infostealer malware, likely via a game cheat tool. This is the initial foothold. Stealing credentials from a single workstation is not sophisticated. This is how nation-state and criminal operations start: low and slow.
-
March 2026 — Attackers use the stolen credentials to compromise Context.ai’s Google Workspace OAuth application. Context.ai hires CrowdStrike for a forensic investigation. CrowdStrike concludes the investigation. The OAuth application credentials are not revoked.
-
Early April 2026 — Attacker begins exploiting the live OAuth tokens.
-
April 19, 2026 — ShinyHunters posts Vercel data for sale on BreachForums, asking $2 million. Vercel publishes an initial bulletin, engages Mandiant. Investigation traces the vector back to Context.ai.
The OAuth token that CrowdStrike missed is the entire story. Not the infostealer. Not the Vercel engineer’s decision to use an enterprise account for a third-party AI tool. The failure of the forensic investigation to identify and revoke a compromised OAuth application.
The AI Office Suite Problem
Context.ai’s AI Office Suite is described in their own documentation as offering a feature that “allowed consumer users to enable AI agents to perform actions across their external applications, facilitated via another 3rd-party service.”
Read that carefully. An AI agent that performs actions across your external applications, using OAuth. If you are an attacker and you compromise the OAuth grants for a product with that kind of access, you don’t need to find a zero-day in your target’s infrastructure. You just use the OAuth token as a trusted identity and walk in through the front door.
This is the new attack surface. It’s not a buffer overflow in V8. It’s not a misconfigured S3 bucket. It’s an AI SaaS vendor that your employees are using with broad OAuth grants to act across Google Workspace, and the vendor’s security posture is unknown and uncontrolled.
The Vercel engineer’s specific failure — using an enterprise Google account to sign up for a consumer AI tool and granting “Allow All” permissions — is the kind of thing that happens thousands of times a day in every tech company. Employees don’t think about the fact that a consumer AI tool with AI agent capabilities is a persistent OAuth grant sitting in their Google Workspace that an attacker might someday compromise. The security team doesn’t have a control that says “you cannot grant Allow All permissions to a third-party AI tool from your enterprise account” because that control didn’t exist two years ago.
Vercel’s internal OAuth configuration “appeared to have allowed this action to grant these broad permissions in Vercel’s enterprise Google Workspace.” That’s a configuration problem that most Google Workspace deployments have. The default settings permit too much.
What “Sensitive” Environment Variables Actually Did
The most technically interesting detail in Vercel’s disclosure is what did not happen. Environment variables marked as “sensitive” in Vercel are stored such that they cannot be read back via the UI or API. Vercel states there is currently no evidence those values were accessed. Only non-sensitive environment variables were enumerated.
This is a real security control with real teeth. When you mark an environment variable as sensitive, Vercel encrypts it and the decryption key is not accessible through the same code path that serves the UI or API. The runtime can still read it — process.env.VARIABLE_NAME works in the deployed function — but an attacker with a compromised internal API token cannot just GET the value from the environment variable endpoint.
The practical implication: if you were using Vercel and you marked your database passwords, API keys, and signing secrets as sensitive, there’s a meaningful chance they were not exposed in this incident. If you put them in plain environment variables because “it’s fine, nobody can access my Vercel dashboard,” they were accessed.
This is not a complete mitigation. Runtime leaks — a bug in your code that logs process.env, or a stack trace that includes environment values, or a deserialization vulnerability — can still expose sensitive variables at runtime. And Vercel acknowledges this: “sensitive vars can still be leaked via runtime or application logs.” But the difference between “attacker reads my env vars through a compromised internal API token” and “attacker needs a separate runtime exploit to get the same values” is the difference between a five-minute compromise and a week of work.
The Forensic Failure Is the Lesson
CrowdStrike investigated Context.ai in March. They found the AWS environment breach. They declared the incident closed. They did not find — or did not revoke — the compromised Google Workspace OAuth application.
This happens more often than people admit. Forensic investigations have scope. They investigate what they know to investigate. The AWS compromise was the known quantity. The OAuth application sitting in Google Workspace with live tokens was not investigated because it was not yet known to be relevant. The attackers knew this. They waited. They used the OAuth tokens that the forensic investigation didn’t revoke.
This is the “incident closed” problem in incident response. When a vendor tells you “we investigated, we remediated, the incident is closed,” what they mean is “we remediated the specific scope of the compromise we identified.” They don’t mean “we found and revoked every credential that was accessed during the window between initial access and remediation.” That window can be weeks or months.
Third-party risk is not a checkbox. It is an ongoing operational concern. The fact that Context.ai hired CrowdStrike and received a clean bill of health did not make Vercel safer. It may have made Vercel less safe, because the clean bill of health reduced urgency while the OAuth tokens continued to sit in Google’s OAuth systems, live and exploitable.
The AI Agent Attack Surface
The “AI Office Suite” feature description — “AI agents to perform actions across their external applications” — is not unique to Context.ai. This is the entire product category of AI agents: they need OAuth grants to act on your behalf across Gmail, Google Drive, Slack, GitHub, and whatever else you’ve connected. The more capable the agent, the broader the OAuth grants it requires.
Every OAuth grant is a long-lived backdoor. Revocation is the only true revocation. An OAuth token for Google Workspace, if not actively monitored and revoked on compromise indicators, stays live until it expires or is manually revoked. Most OAuth tokens for consumer applications expire in hours or days. OAuth tokens for Google Workspace, particularly for service accounts or enterprise integrations, can be long-lived.
The attack pattern here — compromise the AI SaaS vendor, steal their OAuth tokens, use those tokens to access enterprise accounts — is going to become more common. AI agents require OAuth. OAuth is persistent access. Persistent access is valuable to attackers. The security posture of AI SaaS vendors is, in most cases, not comparable to the security posture of the enterprises they serve.
What This Means For You
If you use Vercel: rotate your environment variables, mark everything sensitive, audit your recent deployments, and check your Google Workspace for the IoC App ID 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. If it’s present, revoke it immediately.
If you run a tech company: audit your Google Workspace OAuth settings. Restrict which third-party applications can be authorized with broad permissions. This is not a Vercel-specific problem. Any employee can sign up for a consumer AI tool with their enterprise Google account and grant it broad access. You need a policy and a technical control, not just a policy.
If you are an AI company: your OAuth grants are an attack surface. When you do incident response, revoke everything that was touched, not just what you identified as directly compromised. And when you build AI agent features that require OAuth across external applications, understand that you are building a persistent access mechanism that your customers’ security teams cannot see or audit through normal means.
The Vercel breach was not a failure of security technology. It was a failure of assumptions. The assumption that a third-party AI vendor’s clean bill of health meant the OAuth grants they held were safe. The assumption that “sensitive” environment variables were paranoid overengineering. The assumption that an employee’s consumer AI tool usage was a personal choice with personal consequences.
None of those assumptions were unreasonable in 2023. In 2026, with AI agents that require persistent OAuth grants across enterprise identity providers, they are all wrong.
Vercel is working with Mandiant. Context.ai’s original breach vector was a Lumma infostealer on an employee’s workstation. The data posted by ShinyHunters on BreachForums includes claims of platform-wide database access that Vercel has not confirmed. Treat all environment variables that were not marked sensitive as compromised regardless of what Vercel officially confirms.
Sources: