The 'Allow All' Button That Breached Vercel
In February, a Context.ai employee downloaded a Roblox exploit script. By April 19, that chain of events had placed Vercel's customer environment variables in front of a $2 million ransom demand. Here's the exact chain — and why it will happen again.
On February 4, 2026, a Context.ai employee downloaded what they believed was a Roblox exploit script. Seventy-four days later, a threat actor was sitting on Vercel's internal environment variables and demanding $2 million to stay quiet.
That's the compressed version. The full version is more uncomfortable, because nothing in it required sophistication. Every piece of this attack has a commodity name and a commodity price on a Telegram channel.
The Chain
Here's what actually happened, in order:
February 2026: A Context.ai employee's machine is infected with Lumma Stealer. Lumma Stealer is an infostealer-as-a-service tool — you can rent it for roughly $250 a month. It targets browser credential stores, saved passwords, and live OAuth session tokens. The delivery mechanism was a file presenting itself as a Roblox exploit script, which is a reliable social engineering hook in the developer-adjacent gaming community. Lumma harvests what it finds and calls home. Among what it found: authentication material for the infected employee's accounts.
March 2026: Context.ai identified unauthorized access to its AWS environment. The attacker had used credentials or tokens from the February infection to establish a foothold in Context.ai's infrastructure. What they found there was the actual prize.
Context.ai makes a product called the AI Office Suite. The pitch is straightforward: connect it to your Google Workspace, your Notion, your Slack, your GitHub, and the AI agents handle work tasks across all of them — scheduling, document creation, email triage. To do that, the product needs OAuth tokens. It collects them from users at sign-up, stores them centrally, and routes agent actions through them.
At least one Vercel employee had signed into Context.ai's AI Office Suite using their Vercel enterprise Google account. During setup, they were shown a permissions dialog. They selected "Allow All."
April 19, 2026: Using the compromised OAuth token from the Vercel employee's Google account, the attacker authenticated as that employee and gained access to Vercel's internal systems. They accessed environment variables — specifically those not marked as "sensitive" in Vercel's configuration. Vercel uses encryption for environment variables explicitly flagged as sensitive; the unflagged ones are accessible to anyone with sufficient account permissions.
The same day, a threat actor identifying themselves as ShinyHunters contacted Vercel demanding $2 million. They claimed to have access keys, source code, database contents, and internal deployment configurations. Vercel disclosed the breach publicly on April 19, contacted affected customers, and initiated credential rotation.
Google Threat Intelligence assessed the ShinyHunters attribution as likely impersonation — the actual ShinyHunters group typically operates differently. Whether it's the real group or someone using the name for pressure, the breach is real and the extortion demand is real.
How "Allow All" Becomes a Security Problem
"Allow All" is not a bug or a manipulative dark pattern in this context. It's the honest permissions request for what the product actually does.
Context.ai's AI Office Suite is designed to let AI agents act on your behalf across your connected tools. That requires access to those tools. A user who selects narrow permissions gets a significantly degraded product — the agents can't do what they're sold to do. The product needs broad OAuth access to function as advertised, and the "Allow All" button reflects that honestly.
The problem is the security model underneath it. When you grant an AI productivity tool broad OAuth access to your work accounts, you're placing those tokens somewhere beyond your control. Context.ai stored those tokens in its own infrastructure. That infrastructure was compromised. The tokens went with it.
This is the trust chain that the AI Office Suite category is built on: trust that the AI product itself is secure, indefinitely, at least as secure as the accounts it holds keys to. When that product has a bad day — a vendor employee gets infected with commodity malware, a cloud environment is misconfigured, a token store isn't isolated — every enterprise account that granted broad permissions is now exposed through no action of their own.
There are roughly 4,000 AI productivity tools on Product Hunt with some variant of this OAuth aggregation model. Not all of them store tokens with enterprise-grade security controls. Some are three-person startups whose AWS IAM policies were written by the same founder who was simultaneously pitching investors and shipping features.
Three Parties, Three Failures
The Register noted that three separate organizations made mistakes here, and that's accurate. None of them would have been sufficient alone.
Context.ai failed to adequately isolate and protect the OAuth tokens it held on behalf of enterprise customers. A user granting "Allow All" permissions to an AI productivity product is implicitly trusting that those tokens are stored with commensurate security — not in a position to be lifted by anyone who can pivot through an AWS compromise stemming from one employee's compromised workstation.
CrowdStrike was brought in to investigate the Context.ai incident. Their investigation scope apparently didn't surface the OAuth token exposure before Vercel was notified by the attacker. This is the kind of gap that happens when incident response is scoped too narrowly. "Find out how the attacker accessed our AWS environment" is a different question than "find out everything an attacker with our AWS environment could have done."
Vercel failed to configure Google Workspace protections that would have limited what a compromised employee account could accomplish. Google Workspace administrators can restrict which third-party apps employees can grant OAuth access to, require additional verification for sensitive scopes, and set session length limits that would have invalidated old tokens sooner. None of those controls were in place for this employee's account.
I want to be careful about apportioning blame here, because the third-party failure is the one that matters most for what happens next. Context.ai being compromised is a fact. The breach propagating to Vercel's customers was a consequence of Context.ai's security posture not matching the sensitivity of the data it was holding. That's the structural problem.
The Part No One Is Writing About
There's a downstream credential problem that isn't getting enough attention in coverage of this breach.
Vercel contacted affected customers and initiated credential rotation. That's the right response. But environment variables in Vercel deployments are rarely just Vercel-scoped credentials. They're often API keys for AWS IAM roles, GitHub Actions tokens with write access to production repositories, Stripe secret keys, database connection strings for production databases, third-party SaaS credentials with their own access controls.
Rotating the Vercel-level credential doesn't automatically rotate any of the downstream credentials in those environment variables — assuming the attacker accessed and exfiltrated them before the breach was discovered on April 19. Some of those downstream credentials may still be valid in attacker hands.
If you're an affected Vercel customer, the question isn't "did I rotate my Vercel credentials." The question is: what was in those environment variables specifically, and has each of those external systems' credentials also been independently rotated in the external systems themselves?
Every live production key that appeared in those environment variables is now in scope for that question, not just the Vercel account password.
What To Do
1. Audit your OAuth grants immediately. For Google accounts: myaccount.google.com/permissions lists every application with access to your account and the specific scopes granted. Look for anything you don't recognize, anything with broad Workspace access, and anything from AI productivity tools you're no longer actively using. Revoke what you don't need.
2. Do the same for Microsoft 365. If your organization uses Microsoft 365, myapplications.microsoft.com shows connected apps and their permission scopes. The same principle applies — revoke broad grants to tools you're not actively using, especially AI tools that may hold tokens centrally.
3. Be skeptical of "Allow All" dialogs on AI productivity tools. When an AI tool presents a permissions dialog, read it. If a writing assistant is requesting access to your production GitHub repositories and your AWS management console, that's a mismatch worth pausing on. Grant only the scopes the specific use case genuinely requires.
4. Enterprise admins: implement third-party app policies. Both Google Workspace and Microsoft 365 allow admins to control which third-party applications employees can grant OAuth access to. A policy requiring admin approval for new OAuth grants to external applications would have prevented the token collection that made this breach possible. This control exists; it's worth deploying.
5. Mark sensitive environment variables as sensitive in Vercel. Vercel's "sensitive" flag encrypts variables at rest and restricts access in ways that protected them in this breach — the attacker accessed unflagged variables, not encrypted ones. Any live production credential should be marked sensitive. This is a meaningful control for future exposure, not a remediation for what already happened.
6. If you're an affected customer, go wider in your credential rotation. Inventory every environment variable in every affected Vercel deployment. Identify which values are live credentials for external systems. Rotate those credentials in the external systems, not just in Vercel. Then check access logs in those external systems for anomalous API calls since late March 2026, which is when Context.ai's AWS environment was compromised and the attacker may have first had access to the tokens.
7. Ask your AI productivity vendors direct security questions. "Where are our OAuth tokens stored, and what access controls exist on that storage?" is a fair question to send to any AI Office Suite vendor you use. "What does your incident response look like for a breach of your token storage?" is another one. Vendors who can't answer those questions clearly are telling you something about the care they've given the problem.
What This Actually Proves
The framing I keep seeing in coverage of this breach is some version of "just the kind of risk infosec experts warned about." That's accurate but undersells what's been demonstrated here.
What infosec experts warned about, in general terms, is that agentic AI tools with broad OAuth permissions create a new attack surface by aggregating credentials that would otherwise be isolated. What this breach proves specifically is that the attack chain from "commodity infostealer infects a third-party vendor's employee" to "enterprise customer's production environment variables are in attacker hands" is not theoretical. It ran. It took 74 days from initial infection to breach disclosure. The technical sophistication required was: a $250/month malware subscription, basic AWS lateral movement, and a working understanding of how OAuth tokens can be presented to Google's authentication system.
That's not a novel APT technique. It's commodity tooling applied to a structural weakness that the AI Office Suite category created — and will keep creating, at scale, as more companies adopt these products.
Vercel hasn't published a full post-mortem yet. Some of the details in current reporting will likely be revised. But the core chain — Lumma Stealer to Context.ai's AWS to Vercel OAuth token to Vercel environments — is established, and it's going to be instructive for a long time.
The question worth sitting with is how many other companies have employees who signed into an AI Office Suite product with their enterprise Google account and clicked "Allow All." The answer is a lot. Most of them haven't had their OAuth tokens stolen from the AI product's infrastructure yet. That's not the same as those tokens being safe.
Sources: The Hacker News, The Register, BleepingComputer