One Checkbox Away: The Vercel Breach and the Case for Zero Standing Privileges

There’s never a good time to disclose a breach, but days before your IPO has to rank near the bottom of the list. That was the backdrop to the Vercel breach.

On Sunday the 19th, the company confirmed that attackers had walked into parts of its internal environment and walked back out with customer API keys.

Early reporting focused on the flashy parts: an attacker claiming ties to ShinyHunters, a $2 million BreachForums demand, crypto teams rotating credentials with the IPO roadshow in full swing. But trace the incident back to its origin and it doesn’t start with a zero-day. It starts with a checkbox.

A Vercel employee signed up for Context.ai, a third-party “AI Office Suite,” using their enterprise Google Workspace account. The OAuth consent screen asked for access, and the employee clicked Allow All.

Months later, Context.ai itself got hit by infostealer malware. The attackers walked into its internal systems, found every OAuth grant the company held on behalf of its customers, and used the Vercel employee’s grant to take over their Workspace account and pivot into Vercel’s internal environment.

That single click is really the whole story, because everything that followed traces back to one identity holding more standing access than it should have, and one OAuth token quietly inheriting all of it.

The Vulnerability Wasn’t the AI Tool

It’s tempting to frame this as “Context.ai got breached, therefore third-party AI is dangerous,” and while that’s true, it isn’t the useful lesson here.

The real story is that Vercel’s own access posture decided how bad Context.ai’s breach could get. A vendor’s incident became Vercel’s incident because the trust between them was static, broad, and permanent.

“Allow All” meant an OAuth token, held indefinitely by a third party, could act as the employee inside Workspace. It survived weekends, vacations, and stretches where nobody even used the product.

When it eventually got stolen, it was still valid, still broadly scoped, and still invisible to security.

Vercel’s guidance afterward was to flag more environment variables as sensitive. That’s useful tactical advice, but it treats a symptom, because any privilege left standing is a privilege available to whoever steals the identity that holds it.

The harder fix, and the real one, is to stop leaving privileges standing at all.

How Zero Standing Privileges Could Have Changed the Vercel Breach

That’s the gap Zero Standing Privileges (ZSP) is built to close. The premise is simple: no identity, whether human, service, or agent, holds permanent access to privileged resources. Access is requested when needed, granted Just-in-Time at Just-Enough scope, and revoked automatically when the task is done or the timer expires.

Apply that model to each hop of the Vercel chain and the blast radius collapses at three clear points:

• At the OAuth hop: “Allow All” becomes a scoped, time-bound request that runs through policy.
  
  • The AI tool gets only what it actually needs for the hour, not the whole Workspace forever
  • By the time Context.ai’s token is stolen, it’s already expired or scoped down to nearly nothing
• At the Workspace hop: The employee’s account doesn’t carry standing access to Vercel’s internal infrastructure.
  
  • Compromising the Workspace account gets you into that account, and nothing more
  • Production is a separate, time-bound request with its own approval path, so the lateral movement never happens
• At the environment-variable hop: Nobody holds a persistent right to enumerate those variables in the first place.
  
  • The “sensitive” versus “non-sensitive” label stops being load-bearing
  • Exposed API keys stay behind a control the attacker has to actively request, which is both harder and more visible

None of these are speculative controls. This is how modern privileged access management is supposed to work, and the tooling to do it already exists.

What’s missing in most organizations is the operational commitment to stop treating OAuth consent, SaaS account access, and cloud IAM roles as set-and-forget.

Governing OAuth Itself

Most identity programs stop at the front door. They know who logs in, from where, and with what factor.

What they don’t govern is what third-party apps those users authorize once inside. That’s the exact gap this breach exploited.

OAuth grants deserve to be treated as privileged access in their own right: discoverable, reviewable, and time-bound wherever possible.

Your people should be able to try a new AI tool without handing it a permanent backstage pass to Workspace. Your platform team should know which vendors hold tokens and which have gone idle long enough to revoke.

Agents, copilots, and SaaS-to-SaaS integrations all consume OAuth now. The shadow identity sprawl inside Workspace and Microsoft 365 is where the next breach is already forming.

The Agentic Era Raises the Stakes

OAuth tokens aren’t mostly issued to humans anymore. They’re increasingly issued to AI agents, copilots, and SaaS integrations that act on behalf of humans.

Every one of those is an identity that can be compromised somewhere up the supply chain. Everyone benefits enormously from the lazy convenience of “Allow All.”

Keep giving agents the same blank-check access we used to give humans, and the identity surface grows faster than anyone can audit. ZSP is how it stays manageable, and how a vendor’s bad day stops being your bad day.

The lesson worth taking away

The Vercel breach isn’t really a story about Context.ai, Lumma Stealer, ShinyHunters, or even AI. It’s a story about what happens when standing privileges meet a determined attacker.

The mechanism changes every cycle, but the underlying exposure never does.

If your organization still lets employees grant enterprise-wide OAuth scopes with a single click, still issues production credentials that live forever, still treats access as something you configure once and forget, you are one stolen token away from the same headline.

The fix isn’t to panic about AI tools. It’s to make every privileged access grant temporary, scoped, and approved by default.

That’s what Zero Standing Privileges means in practice, and the bar every security program should now be building toward.

If this is the week your team starts rethinking standing access, our 2026 Buyer’s Guide to Privileged Access Management Platforms is a useful next step. It walks through what modern Cloud PAM actually looks like and gives you a framework for comparing it to what you have in place today.