The Vercel breach is not really about Vercel

Vercel disclosed a security incident this week. Unauthorized access to internal systems, environment variables exposed, a threat actor claiming to sell stolen data for $2 million. Mandiant is involved. Law enforcement has been notified.

The coverage has focused on Vercel. The more interesting part of this story is what got the attacker in: a small AI productivity tool that one employee signed up for using their work Google account.

That detail should make a lot of engineering teams uncomfortable. Not because they use Vercel. Because they almost certainly do the same thing.

What actually happened

The attack chain here is worth walking through carefully because it is not the kind of breach most teams are designing defenses against.

Attack chain — Vercel April 2026

Context.ai employee compromised by Lumma Stealer

In February 2026, malware on a Context.ai employee's machine harvested credentials including Google Workspace logins, Supabase keys, Datadog access, and the support@context.ai account. The support account is the one that mattered.

Attacker pivots to Context.ai's OAuth infrastructure

Using the compromised support account, the attacker was able to access and likely manipulate Context.ai's OAuth tokens for consumer users of the platform.

One Vercel employee had signed up with their enterprise Google account

The employee used their Vercel enterprise Google Workspace account to sign up for Context.ai and granted "Allow All" permissions to the OAuth app. That single permission grant is the hinge point of the entire attack.

Attacker uses compromised OAuth token to access Vercel's Google Workspace

Vercel's internal OAuth configurations allowed the broad permissions that employee had granted to translate into meaningful access across the enterprise Google Workspace environment.

Environment variables not marked "sensitive" are accessed

From inside Vercel's environments, the attacker accessed environment variables stored in plaintext, meaning those not flagged as sensitive. API keys, tokens, database credentials, signing keys. Anything not explicitly protected was in scope.

The npm packages are fine. Sensitive environment variables appear to be fine. But the path from "one employee signed up for a small AI tool" to "attacker inside enterprise infrastructure" took a few months and a handful of steps that each look mundane on their own.

The part that stands out: Vercel describes the attacker as "highly sophisticated based on their operational velocity and detailed understanding of Vercel's systems." This was not opportunistic. Someone mapped Vercel's infrastructure and knew exactly where to go once they had OAuth access.

The real problem is the AI tool sprawl

Most engineering teams right now have a mix of AI tools that employees adopted individually. Productivity tools, writing assistants, coding helpers, meeting summarizers. Most of them ask for Google OAuth on sign-up. Most employees click through.

Nobody has a complete inventory of which tools have which OAuth permissions across which accounts. Security teams are not reviewing these. IT is not provisioning them. They accumulate invisibly, each one a potential pivot point if the tool itself gets compromised upstream.

Context.ai is not a rogue product. It is a legitimate AI tool. The problem is not that the tool was malicious. The problem is that a compromised support account at a vendor with OAuth access to your enterprise environment is effectively a compromised account in your enterprise environment. The perimeter dissolved the moment the employee clicked "Allow All."

The scope of the exposure: Context.ai says the incident "potentially affected hundreds of users across many organizations." Vercel published an OAuth app identifier so Google Workspace administrators across any organization can check whether that app has access to their environment. If your team uses Google Workspace, that check is worth doing today.

What you should do right now

If you are on Vercel, Vercel has been direct about the immediate steps. If you are not on Vercel, the broader lessons still apply.

Rotate environment variables not marked sensitive on Vercel Any environment variable stored in plaintext should be treated as potentially exposed. API keys, database credentials, signing keys, third-party tokens. All of them. Deleting your Vercel project is not sufficient if the credential is still valid.

✓

Audit third-party OAuth grants in Google Workspace Go to your Google Admin console and review which third-party apps have been granted access to your organization's Google Workspace. You will likely find apps that security has never reviewed. Revoke anything that should not be there.

✓

Flag the Context.ai OAuth app specifically The identifier Vercel published is 110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com. Search for it in your Google Workspace admin panel and check for usage.

✓

Enable MFA everywhere that does not have it Specifically on accounts that have access to infrastructure. Authenticator apps rather than SMS. This would not have prevented this specific attack but it raises the cost of every other attack that comes through compromised credentials.

✓

Mark environment variables as sensitive going forward Vercel has now defaulted new environment variable creation to sensitive. If you have existing variables in plaintext, review and update them. Sensitive variables are stored in a way that prevents them from being read even with internal access.

✓

Inventory the AI tools your team is actually using This is the uncomfortable one. Ask your engineers what productivity tools they have signed up for with their work accounts in the last 12 months. The answer will surprise you. Each one with OAuth access is a potential attack surface you do not control.

The broader pattern

This attack is a clean example of a category of risk that is growing fast and that most organizations are not tracking well: third-party AI tool supply chain exposure.

A year ago, the primary supply chain concern was npm packages and open source dependencies. Those are still real. But the AI tool layer is new and it has a different risk profile. These tools are often adopted by individuals rather than IT, they ask for broad OAuth permissions as part of their core functionality, and they are connected to enterprise accounts rather than isolated developer environments.

The attacker who got into Vercel did not exploit a sophisticated zero-day in Vercel's infrastructure. They found a path through a vendor that had legitimate access, elevated through a support account compromise, and used OAuth permissions that an employee had granted months earlier without thinking twice about it.

That chain is reproducible. And most organizations have more links in it than they realize.

The useful framing: Every third-party tool your employees use with enterprise OAuth credentials is a company with its own security posture that you are now implicitly trusting. You probably do not know their security posture. You probably have not asked. After this week, that is worth changing.

Our take

We build software for clients in healthcare, fintech, and HR. The teams we work with are careful about their own code. They are much less careful about the tools they give OAuth access to.

The Vercel breach is going to be remembered as a Vercel story. But the attack vector is not specific to Vercel. It is specific to the way most engineering teams operate right now: fast tool adoption, broad permissions, no inventory. If that describes your team, this week is a good time to fix it before someone runs the same playbook on you.