Vercel’s April 23 follow-up changed the incident from a clean AI supply-chain story into something more useful and more uncomfortable: OAuth grants have become build secrets, and account compromises can hide in the same access graph long enough to look like separate events.
This is a revisit. I already wrote about the initial disclosure in “The Vercel Breach Wasn’t a Zero-Day. It Was an AI Supply Chain Attack.”. The new development is Vercel’s continued investigation: additional April victims, separate customer accounts with evidence of earlier compromise, and a public debate around why readable environment variables and broad OAuth grants are still treated as normal developer convenience instead of privileged production material.
The interesting part is no longer just that a cloud platform got breached, or that an employee used a third-party AI tool, or that attackers chased credentials. The interesting part is the shape of the path: a consumer AI workspace, a broad Google Workspace authorization, a Vercel account, internal systems, and environment variables that could still decrypt to plaintext. That is not a weird edge case anymore. That is the default failure mode for developer infrastructure that lets every productivity tool become a soft side door into the build system.
Vercel’s own bulletin, updated after the first disclosure, says the incident originated with a compromise of Context.ai, a third-party AI tool used by a Vercel employee. The attacker used that access to take over the employee’s Vercel Google Workspace account, gained access to the employee’s Vercel account, pivoted into a Vercel environment, then enumerated and decrypted non-sensitive environment variables. Vercel says sensitive environment variables and npm packages published by Vercel were not shown to be compromised, and that it worked with GitHub, Microsoft, npm, and Socket to validate the supply chain.
That supply-chain reassurance matters. It is also no longer the central lesson.
The central lesson is that the chain did not need a compiler backdoor, an npm typosquat, a zero-day in Next.js, or a miracle exploit. It used delegated access. The boundary was not code execution. The boundary was authorization sprawl.
The access graph was the exploit surface
Context.ai’s incident statement fills in the part that makes this more than another vendor-blames-vendor breach note. Context says it had identified and stopped unauthorized access to its AWS environment the previous month. Later, based on information from Vercel and additional investigation, it concluded that the actor likely compromised OAuth tokens for some consumer users. It also says Vercel was not a Context customer, but at least one Vercel employee signed up for Context AI Office Suite using a Vercel enterprise account and granted “Allow All” permissions.
That sentence should make every security team uncomfortable. Not because the phrase “AI Office Suite” is magic. Because the same pattern applies to browser extensions, meeting bots, note takers, analytics overlays, AI inboxes, calendar assistants, and every small SaaS tool that wants to “connect your workspace” before it has earned the right to touch anything.
The old model treated production secrets as the obvious danger. API keys, database URLs, signing keys, deploy tokens, package publisher credentials. Put them in a vault, rotate them, scope them, do not paste them into Slack. Fine. But OAuth grants now sit one layer above those secrets. They can read email, enumerate files, access calendars, impersonate workspace sessions, call APIs, trigger workflows, and in some cases bridge into other admin consoles because humans reuse identity across everything.
If an OAuth token can get an attacker to the place where secrets are listed, it is a secret. If it can impersonate the employee who can see the deploy project, it is a secret. If it can survive password rotation, it is worse than a password.
That is why the Vercel incident lands differently from a normal breach notice. It shows a modern access graph where the interesting object is not a file on disk. It is the graph edge between a user, a workspace, an OAuth app, and an internal SaaS surface.
”Non-sensitive” is doing too much work
The other ugly detail is Vercel’s distinction between sensitive and non-sensitive environment variables. In the bulletin, Vercel says the attacker enumerated and decrypted non-sensitive environment variables, meaning values stored on Vercel that decrypt to plaintext. Environment variables marked sensitive are stored so they cannot be read back, according to Vercel’s statement.
On paper, that is a useful feature split. In practice, it creates a dangerous default question: which values did teams remember to classify correctly?
The Hacker News discussion focused hard on this point, and for once the bikeshedding had a real security center. Commenters asked why readable environment variables exist as the default shape at all, and why the unsafe mode is not explicit. They also pointed out that integrations can create or manage variables on behalf of users, which means the sensitivity decision is not always made by the person who understands the blast radius.
The industry has been here before. We learned that public S3 buckets were not just a user education problem. We learned that permissive CI tokens were not just a documentation problem. We learned that browser extension permissions were not just a consent-screen problem. Defaults are architecture. If a platform stores a database URL in a readable slot, the fact that it also offers an unreadable slot does not fully absolve the platform or the team using it.
A readable environment variable is not automatically harmless because a UI labels it non-sensitive. Database URLs, API keys, webhook secrets, analytics tokens, preview deployment credentials, private backend endpoints, and signing material often arrive in environment-variable form. The label is metadata. The value is reality.
Vercel told affected customers to rotate credentials, and TechCrunch reported that Vercel later identified a small number of additional accounts compromised as part of the April incident, plus a small number of customer accounts with evidence of prior compromise that Vercel says appeared independent of the April breach. TechCrunch also quoted Guillermo Rauch describing rapid and comprehensive API usage focused on enumerating non-sensitive environment variables once attackers had keys.
That detail matters because it is not random rummaging. It is a playbook. Get durable identity material, use APIs fast, enumerate configuration, extract what is readable, and move before anyone understands which trust edge failed.
AI tools make the sprawl faster, not different
There is a cheap version of this story that says “AI tools are dangerous” and stops there. That is too lazy. AI tools are not uniquely cursed. They are currently where the sprawl is fastest.
A new AI workspace often asks for exactly the scary permissions because its product promise is to act across other tools. Read docs, draft mail, create spreadsheets, summarize meetings, file issues, update CRM rows, prepare presentations, inspect repositories. The agent pitch is integration density. But integration density is also compromise density.
The Vercel incident is not a reason to ban every AI assistant. It is a reason to stop treating employee-installed AI assistants as personal productivity choices. Once a tool can obtain workspace OAuth grants, it is part of the enterprise attack surface. It needs allowlisting, scope review, token lifetime controls, audit logging, app risk review, and a fast revocation path.
The old shadow IT problem was that employees could expense a SaaS subscription. The new shadow AI problem is that employees can delegate organizational authority to a service whose whole job is to automate across other services.
That does not mean the right answer is a dead bureaucracy where nobody can try tools. It means the permission model has to match the blast radius. A consumer AI office suite should not be able to receive broad enterprise Google Workspace permissions from a production employee account without an admin control point that says, in effect, “this grant can become an incident.” If the control point is just a scary consent screen, the control point is theater.
The fix is boring, which is why it will be skipped
The uncomfortable fixes are not glamorous. They are not agentic. They are not a new benchmark. They are the things teams already know how to do and keep failing to operationalize.
Treat OAuth apps like deploy keys. Inventory them. Scope them. Review them. Expire them. Alert on new grants with high-risk scopes. Block consumer apps by default in enterprise identity providers unless explicitly approved. Separate production identity from experimentation identity. Make readable environment variables the exception, not the normal path. Rotate anything that was ever stored in a readable slot. Log environment-variable reads as first-class security events, not admin trivia.
And for platforms: stop making users discover secure storage after the fact. Sensitive should be the default for anything shaped like a secret. If a value must be readable later, the user should have to choose that weaker property deliberately, with a clear reason. The platform cannot know every variable’s semantic meaning, but it can absolutely know that making secrets easy to read back is a footgun with a polished UI.
Vercel’s bulletin says there is no evidence of npm package tampering. Good. The worse outcome would have been a poisoned framework release or package-publisher compromise. But the absence of that disaster should not make the actual incident feel small. Modern developer infrastructure is a concentration layer: source, deploys, secrets, previews, logs, teams, domains, analytics, and identity. A narrow breach of that layer can still create a wide credential-rotation event for customers.
The lesson is not “do not use Vercel” and it is not “do not use AI tools.” The lesson is that the build system no longer ends at GitHub, the runtime, and the package registry. It includes every OAuth app employees connect to the identity fabric around those systems.
OAuth used to feel like login plumbing. Now it is part of the secrets layer. Treat it that way, or the next breach will once again arrive through the side door everyone clicked through because the consent screen looked routine.