One Engineer Clicked "Allow All." Attackers Read Production Secrets Three Hops Later.

The Vercel breach did not begin with a vulnerability. It began with an onboarding screen.

In April 2026, Vercel disclosed that attackers had reached its internal systems and read customer environment variables: API keys, database credentials, signing secrets. No exploit was involved. The entry point was an AI productivity tool that one employee had connected to their corporate Google account.

The chain that made this possible is now the most reproducible attack pattern in enterprise AI. It needs no novel technique, no zero-day, no model jailbreak. It needs only that somebody in your organization approved an AI tool with more access than it required.

The Attack Chain Nobody Modeled

Vercel's security bulletin, last updated April 24, 2026, traces the incident to a compromise at Context.ai, a third-party AI agent platform used by a Vercel employee. Reconstructed alongside the Cloud Security Alliance's analysis of April 20, the escalation ran in three distinct hops.

1. Endpoint compromise at the AI vendor. In February 2026, a Context.ai employee was infected with Lumma Stealer, a commodity infostealer. It harvested credentials for Google Workspace and internal systems, including the vendor's OAuth application management environment.
2. OAuth token compromise. By March 2026, the attacker had reached Context.ai's AWS environment and the OAuth tokens of the tool's users. Controlling the authorization infrastructure meant valid tokens could be minted for any user who had ever consented.
3. Lateral movement into Vercel. A Vercel employee had connected their enterprise Google Workspace identity to Context.ai. The stolen token unlocked that identity, which unlocked their Vercel account, which led to the environment variable interface.

Vercel assessed the attacker as highly sophisticated, citing their operational velocity and their grasp of the platform's API surface. That is worth noting, because everything up to the final hop required no sophistication at all.

The AI Tool Was Working Exactly As Designed

Context.ai was not misconfigured in some exotic way. It was doing the thing the product exists to do. An AI tool that summarizes your documents has to read your documents. An AI tool that drafts on-brand content has to see the brand material.

Broad, persistent access is not a bug in this product category. It is the product category. Context.ai's own marketing described integration with more than forty enterprise tools.

The OAuth consent screen is where your vendor risk assessment quietly gets overruled.

That produces a trust relationship no conventional vendor holds:

The Secrets Were Readable Because Nobody Marked Them Otherwise

The second failure was quieter. Vercel offers a sensitive designation for environment variables that encrypts values so they cannot be read back through the interface. It is opt-in. The default stores values in a form readable by anyone holding project-level access.

So the attacker never needed to break encryption. They needed a session. Vercel confirmed that variables marked sensitive showed no evidence of access.

• Readable defaults become exposed the moment any identity with project access is compromised.
• Opt-in controls protect only the teams who already knew to go looking for them.
• Vercel has since shipped a team-wide policy forcing new production and preview variables to default to sensitive. That closes the gap going forward, not retroactively.

Your Vendor Questionnaire Never Saw This Coming

Most vendor risk programs were built for point integrations reviewed once, at procurement. They ask about SOC 2, data residency, breach notification windows. They do not ask which OAuth scopes an employee will be shown during signup, or whether that employee has any authority to grant them.

The Vercel employee who connected Context.ai almost certainly held no mandate to extend corporate identity to a third party. The consent screen never framed it that way. It framed it as a checkbox on the road to a working tool.

The pattern itself is not new. The 2024 Snowflake campaign followed structurally identical logic: infostealer-sourced credentials, then broad downstream compromise across an ecosystem of customers. What changed is the density of high-privilege AI integrations now sitting in the middle of it.

What to Audit This Week

Treat this as a template rather than an anomaly. In priority order:

1. Pull the OAuth grant list for your Google Workspace or Microsoft 365 tenant. Filter for third-party AI tools holding drive, mail, or directory scopes. Vercel published the compromised client ID so administrators can check their own tenants directly.
2. Separate employee-authorized grants from IT-provisioned ones. The first category is where over-scoped access hides.
3. Rotate anything that was readable during the exposure window. Evidence of access is not the bar. Reachability is.
4. Switch on encrypted-by-default secrets in every platform that offers the setting, then verify it applied to existing values, which it usually does not.
5. Put AI integrations on a recurring review cycle. A grant approved once persists until somebody revokes it.

None of this requires new tooling. It requires somebody to own the question, which in most organizations nobody currently does.

The Uncomfortable Version

The reflex after an incident like this is to ask whether the AI tool was safe. That is the wrong question. Context.ai's security posture was one variable in a chain that also included a personal malware infection, a default storage setting, and an approval nobody reviewed. Break any single link and the attack stops.

Which means the audit that catches this is neither an AI audit nor a cloud audit. It is a question about identity: who is permitted to extend your organization's access to software you never evaluated, and how would you find out.