On April 2026, Vercel published a security bulletin disclosing unauthorized access to internal systems. Since then, Vercel’s CEO has shared more detail on the attack chain, and it’s worth walking through. The story isn’t really about Vercel. It’s about the shape of every modern SaaS breach.
What actually happened
Per Vercel’s follow-up communication, the chain looked like this.
First, Context.ai was breached. A third-party AI product that a Vercel employee was using got popped. Whatever Context.ai could see and do via its Google Workspace OAuth grant, the attacker could now do too. From there, the employee’s Workspace account was compromised, and that foothold was used to escalate into Vercel’s internal environments.
Inside Vercel, the attacker enumerated customer environment variables. All values are encrypted at rest, but Vercel has a “sensitive” flag that adds an additional protection layer. Values marked sensitive were not accessed. Non-sensitive values should be considered exposed.
Vercel’s CEO also notes that the attackers moved “with surprising velocity and in-depth understanding of Vercel” and that the operation was almost certainly AI-accelerated. That tracks with what defenders are seeing across the industry. Attackers compound just like we do.
To Vercel’s credit, they are working with Mandiant and law enforcement, they have already shipped an env var overview page and a cleaner UI for sensitive env vars, and the CEO’s public communication has been unusually direct.
The lesson hiding in the attack chain
Zoom out and look at the path: SaaS product, then OAuth grant, then employee Workspace, then corporate infrastructure, then customer data.
There is no zero-day here. No kernel exploit. No exotic supply chain compromise of npm or Go modules. It is the standard, ordinary flow every company now runs on. Your team uses an AI or analytics or productivity tool, that tool has OAuth into your Google Workspace, and the blast radius of any one of those vendors getting compromised is everything that Workspace account can reach.
For most companies, that is a lot.
The part that should scare you
Vercel’s own bulletin contains one line every engineering leader needs to internalize:
Environment variables marked as “sensitive” were protected. Non-sensitive variables containing API keys, tokens, database credentials, or signing keys should be considered potentially exposed.
The thing that determined whether your production database credentials walked out the door was whether someone on your team remembered to tick a checkbox when they added the variable.
That is the whole story. A checkbox.
The simplest rule: always use sensitive
The easiest and highest-leverage change you can make today does not require switching vendors, migrating secrets, or rolling out a new client library. It is a rule: every secret is sensitive. Every time.
Full disclosure, I run Unkey, and our own hosting product, Unkey Deploy, includes built-in secret storage. Even there, the same rule applies. Any hosting platform that offers a sensitive or equivalent protection flag should be treated as a binary choice. If the value is a credential of any kind, flag it. If it’s a feature toggle, a public URL, or a display string, don’t. There is no middle category.
The Vercel incident is the cleanest possible illustration of why. Same platform, same database, same customer accounts. The only thing separating “safe” from “exposed” was one UI toggle. That is not a judgment call worth making per-variable.
If you take nothing else from this post, take that.
Why env vars in the UI alone were never enough
The standard pattern of dropping secrets into a platform’s env var UI and referencing them at build and runtime was always a compromise. You get secrets sitting at rest in a vendor’s control plane, no meaningful access control beyond “can log into the dashboard,” no rotation story, no audit trail of which deploy or human or integration touched what, and an attack surface that grows every time you connect a third-party tool to your workspace.
That compromise was tolerable when the blast radius was small. It isn’t anymore. Every team now connects half a dozen AI assistants, preview tools, and CI helpers via OAuth. Each one is a path into your secrets store.
A “sensitive” flag is a meaningful mitigation, and in this incident it clearly saved customers. It is not, by itself, a complete strategy. It lives inside the same tenant as everything else, and when the platform itself is the target, you want depth on top.
Prevent the attack chain: protect the org first
The env var conversation is downstream. The upstream fix is not letting a random SaaS OAuth grant become a foothold into your corporate identity provider in the first place. If you run on Google Workspace, go do this today.
Navigate to Admin Console, then Security, then Access and data control, then API controls, then Settings.
Under “Unconfigured third-party apps,” change the default from “Allow users to access any third-party apps” to “Allow users to access third-party apps that only request basic info needed for Sign in with Google.” If your team can handle the friction, go one step further and choose “Don’t allow users to access any third-party apps.”
The default posture lets any user in your org grant any OAuth app unrestricted access to their Google data. The locked-down posture means every app your team uses has to be explicitly reviewed and approved before it gets a scope beyond name and email. That is the single highest-leverage config change most Workspace admins have never flipped.
While you’re in there, do a few more things. Audit the list of currently connected OAuth apps and revoke anything unused. For the apps that remain, scope them to the specific OUs that actually need them. Require admin approval for any app requesting restricted or sensitive scopes like Gmail, Drive, Calendar, or Admin. Turn on alerting for new third-party app grants, because you want to know the moment something new shows up.
Do the equivalent in every identity provider and source-of-truth system you run. GitHub org, Microsoft 365, Okta, Slack. The generalized rule is that no OAuth grant should be possible without review.
This is the control that would have short-circuited the Vercel chain before it ever touched a Vercel system.
What a dedicated secret manager adds on top
Assume some vendor will eventually get breached despite all of the above. Depth matters.
If your sensitive use case warrants more than the sensitive flag, for example production credentials for financial data, healthcare, or anything with meaningful regulatory exposure, a dedicated secret manager is the right tool. Infisical, Doppler, HashiCorp Vault, AWS Secrets Manager, and 1Password Secrets Automation all solve this well.
A dedicated secret manager gives you things your hosting platform fundamentally cannot. You get separation of concerns, so a compromise of your deploy platform does not equal a compromise of your secrets, because they live in a different tenant with a different auth boundary and a different attack surface. You get short-lived credentials, fetched at runtime, cached briefly, and rotated aggressively, so the window a leaked secret is useful shrinks from months to minutes. You get real RBAC at the per-environment, per-project, and per-service level, so your frontend never sees your Stripe secret key and your CI never sees your production database password. You get audit logs that matter, telling you who read which secret, when, and from where. You get rotation as a primitive rather than a scary manual project. You get drift detection and policy enforcement, with alerts when secrets appear where they shouldn’t.
For most teams, the realistic sequence is sensitive-flag-everything first, then migrate the highest-value secrets behind a dedicated manager as you grow.
The pragmatic move for most teams
You don’t need to rip everything out tomorrow. A sensible path looks like this.
Today, lock down third-party OAuth access in your Google Workspace or equivalent identity provider, audit current grants, and revoke anything unused. Then audit every env var across every project you run. Anything that is not flagged sensitive and not genuinely public, treat as exposed and rotate.
This week, inventory every OAuth integration connected to Google Workspace, GitHub, Slack, and your deploy platforms. Revoke liberally. Require admin approval on new grants going forward.
This month, decide whether your highest-value secrets belong behind a dedicated secret manager. For most teams, database passwords, signing keys, and payment-provider credentials are the obvious first candidates to move.
Ongoing, maintain rotation schedules, use short-lived credentials wherever your stack supports them, review who and what can read what, and alert on new OAuth grants at the org level.
The real takeaway
Every cloud platform is one compromised vendor OAuth grant away from being in Vercel’s position this month. Vercel handled the response about as well as you can once an attacker is already inside. Fast communication, encryption at rest, a sensitive flag that meaningfully bounded the damage, Mandiant engaged, UX improvements shipped within days. That is the bar.
The attack never needed to get that far, though. It started with a vendor breach turning into a Workspace compromise turning into a corporate foothold. That first hop is the one most orgs don’t defend against, and it is defendable with a config change.
Three things to do this week.
First, lock down third-party OAuth in your identity provider. Second, mark every secret in your hosting platform as sensitive, whether that platform is Vercel, Unkey Deploy, or anyone else offering the flag. Third, for the highest-value credentials, move them behind a dedicated secret manager.
If the only thing standing between your production database credentials and an attacker is a checkbox that may or may not have been ticked, and a default-permissive Workspace config, you don’t have a security posture. You have a hope.
Fix that this week.
Discussion // 0 comments
sort: oldest ↓