April 21, 2026
Posted by Refael Angel
On April 19, 2026, Vercel disclosed a security incident. By any modern measure, they handled the disclosure well: it was fast, factual, and actionable. The details of what happened, however, are worth every security and platform team reading in full, because this breach is a near-perfect illustration of where supply-chain attacks are heading in a world of SaaS sprawl and AI agents.
The short version: the attacker didn’t break into Vercel. They logged in, using an OAuth token a Vercel employee had granted months earlier to a third-party AI tool.
TL;DR
- The initial compromise happened at Context.ai, not at Vercel.
- An employee’s OAuth grant to Context.ai carried broad Google Workspace permissions.
- The attacker used that token to access the employee’s Workspace account, then pivoted into internal Vercel systems.
- Customer environment variables — API keys, DB credentials, deployment secrets — were exposed for a limited subset of customers.
- Threat actors linked to the ShinyHunters group later posted sample data and attempted to sell stolen records, including internal metadata.
- The breach is a static-secrets and OAuth-scope problem, not a code vulnerability.
The Timeline
February 2026: A Context.ai employee is infected with Lumma Stealer, an information-stealing malware family sold as a service. Credentials and session tokens are exfiltrated.
March 2026: Context.ai detects and blocks unauthorized access to its AWS environment. In the process, it becomes clear that OAuth tokens belonging to some of its customers may also have been compromised.
April 19–20, 2026: Vercel publishes its security bulletin. A subset of customers is notified and asked to rotate credentials. Threat actors begin advertising stolen data on BreachForums.
The Attack Chain
1. A Vercel employee signed up for Context.ai using their Vercel enterprise Google Workspace account. They granted “Allow All” OAuth permissions, a scope that is both easy to click and difficult to audit after the fact.
2. Context.ai’s own environment was compromised via the stolen credentials noted above. The attacker gained access to OAuth tokens issued to Context.ai’s customers.
3. Using the Vercel employee’s token, the attacker accessed that employee’s Google Workspace — bypassing password and MFA challenges, because a valid OAuth token doesn’t trigger them.
4. From inside the Workspace, the attacker enumerated and pivoted to internal Vercel systems, ultimately reaching customer environment variables.
5. Vercel has confirmed that environment variables marked as “sensitive” were protected differently and not part of the exposed set. Services remained operational throughout.
What Vercel Got Right
Before the analysis, credit where it’s due. Vercel disclosed quickly. They named the third-party vector publicly rather than deflect. They published indicators of compromise. They protected customers whose secrets were marked sensitive. Not every company handles a breach this cleanly, and the security industry is better off when disclosure is the default.
The Structural Problem
Here’s the part that matters beyond Vercel.
Every company today runs an unseen, undocumented identity supply chain. It doesn’t live in package-lock.json. It lives in the OAuth consent screens your employees clicked through the first time they tried a new SaaS tool, and in the long-lived API keys sitting in environment variables, Kubernetes secrets, and CI/CD config files.
Two assumptions the industry has been taking for granted are now breaking:
Assumption 1: OAuth tokens are safe because the user approved them.
Reality: The user approved the vendor, once, months or years ago. The token is now a password with no expiration and no review.
Assumption 2: Environment variables are safe because they’re not in the code.
Reality: They’re just as static, just as long-lived, and just as valuable to an attacker as credentials committed to a repo — arguably more, because they’re production.
What to Do This Week
- Audit every OAuth app with “Allow All” or broad Workspace scopes. Revoke anything unused or over-scoped.
- Inventory every static API key older than 90 days. Treat them as already-compromised until rotated.
- Separate sensitive from non-sensitive environment variables explicitly. If your platform supports it, move anything that grants production access to dedicated sensitive handling.
- Reduce lifetimes. Anywhere you can swap a static key for a dynamic, just-in-time credential, do it.
- Put AI-agent identities on the same footing as service accounts. They need issuance, rotation, and revocation like any other non-human identity.
- Review logs, deployments, and access paths associated with affected systems.
All of this is necessary, although it doesn’t change the underlying problem: the credentials themselves still live too long.
Why Ephemeral Secrets Change the Outcome
As the Vercel breach makes clear, the initial compromise is rarely the story, the real issue is what the attacker finds.
A static secret is a promise: “This key will keep working.” An ephemeral secret is a limited transaction: “This credential exists for the next 15 minutes, for this one workload, for this one purpose.”
Attackers want the promise; they can’t monetize the transaction.
How Just-in-Time Secrets Work
A just-in-time (JIT) secret is generated at the moment a workload or user needs access, valid only for that session, and destroyed automatically when the session ends. Instead of an application reading a long-lived API key out of an environment variable, it requests a credential from a secrets platform, uses it, and lets it expire.
The implementation details vary, but the principle is consistent: credentials are created on demand, scoped to a specific task, and automatically expire without requiring manual rotation.
Blast-Radius Math
That shift changes the math of a breach. A static API key with no rotation policy has a useful lifetime, from an attacker’s perspective, of approximately “forever, or until someone notices.” Real-world disclosures routinely reveal keys that were stolen months before being used.
Contrast this with a JIT credential with a 15-minute TTL. From an attacker’s perspective, it has a useful lifetime of at most 15 minutes. And crucially, that window starts when the credential was legitimately issued, not when it’s stolen. A credential stolen 20 minutes after issuance is already dead.
This matters for incident response too. When the Vercel breach hit, a significant number of companies spent the weekend rotating credentials by hand across every affected system. With JIT credentials, there is no “rotation event,” every new session is already a new credential. The incident response for the same class of breach collapses from a multi-day fire drill to a targeted, minutes-long review.
This Isn’t Just a Vault Problem
Isn’t this just a vault? No, and the distinction matters. A vault protects a secret at rest. It encrypts it, controls who can read it, and logs access. These are necessary properties, but they do not change the nature of the secret itself. A stolen, long-lived secret retrieved through legitimate vault access still works wherever it works.
An ephemeral-secrets architecture changes the nature of the secret. It moves the security property from “hard to read” to “useless if stolen.” Those two properties compose; modern platforms offer both.
What This Looks Like in Practice With Akeyless
If you take that model seriously, you need infrastructure that can actually issue, scope, and remove credentials continuously. This is where Akeyless comes in.
Akeyless is a SaaS secrets-management platform built around three architectural commitments that speak directly to the Vercel class of breach:
- Dynamic, just-in-time secrets across databases, cloud providers, SSH, and AI agents, so the credentials in your runtime environment don’t outlive the session that needs them.
- Distributed Fragments Cryptography™ (DFC™) — encryption-key fragments are distributed and constantly refreshed, so secrets can’t be decrypted outside your environment, even by us.
- Unified visibility across every cloud, SaaS, and AI system in your stack, so OAuth sprawl and secret sprawl become measurable rather than theoretical.
In practice, this model shows up differently depending on the system:
- For databases, Akeyless generates a temporary user with a scoped role at request time, and deletes it when the session ends.
- For cloud providers, Akeyless federates with IAM to issue short-lived tokens instead of distributing long-lived access keys.
- For SSH, Akeyless issues signed certificates that expire in minutes, eliminating the need to distribute static private keys.
- For AI agents, Akeyless allows agents to retrieve credentials on demand without ever storing them locally — which matters because agents introduce entirely new paths for secret exposure.
The common thread is simple: there is nothing persistent left behind for an attacker to reuse.
What This Doesn’t Solve
To be clear: ephemeral secrets don’t prevent the initial OAuth compromise in a Context.ai-style incident. No secrets platform does. What they change is the value of what the attacker finds when they pivot. A compromised employee account that enumerates internal systems and finds only short-lived, scoped credentials is a much less productive breach than one that finds static API keys.
The right mental model is defense in depth for identity:
- OAuth hygiene, least-privilege scopes, and consent review at the edge
- Ephemeral, scoped credentials everywhere underneath
Next Steps
The Vercel breach will not be the last of its kind. OAuth sprawl is going to keep growing. AI agents acting on behalf of employees will keep accumulating scopes. Static secrets will keep aging in environment variables until someone finds them.
We already laid out what steps to take this week but those don’t change the underlying model that made the breach valuable in the first place. The durable answer isn’t a better vault. It’s a different kind of secret: one that is generated on demand, scoped to a single session, and destroyed automatically when the session ends.
To see what that looks like in your own environment, request a secrets architecture review and demo with the Akeyless team.
