The Vercel Breach: A Failure of Identity, Not Code
The Vercel breach epitomizes why zero-trust and governed OAuth are so vital for protecting today's software supply chain.
The recent Vercel breach surprised the engineering world. In April 2026, Vercel, a platform for deploying and hosting web applications, had its internal systems breached and sensitive customer data stolen.
The breach involved a compromised OAuth token, leaked API keys, and unauthorized access via an untrusted third-party SaaS application. It marks one of the most high-profile security incidents involving Vercel to date.
What's surprising is that the Vercel breach wasn't a code vulnerability at all. It was primarily an access and identity issue stemming from an insecure third-party integration. In other words, this was not a breach of infrastructure: It was a breach of identity boundaries.
While Curity was in no way affected, it's an unfortunate story we've witnessed multiple times, and one we feel strongly about given the strategies to prevent these sorts of exploits are readily available.
What Happened?
According to Vercel's statement issued on April 19th, the breach began with an OAuth integration. A Vercel employee connected Context.ai, a small third-party AI tool, to their Google account.
Eventually, Context.ai became compromised. Using this entry point, a hacker was able to access a Vercel employee’s Google Workspace account to gain unauthorized access to internal Vercel systems, which was then used to leak unencrypted secrets such as customer credentials and API keys.
Vercel now reports that these variables, including API keys, tokens, database credentials, signing keys, should all be considered as exposed. TechCrunch reports the hacker group is actively selling this information on the dark web.
What Could Have Prevented It?
It's easy to call foul in hindsight. However, this breach has many of the hallmarks of poor identity and access management, a lack of technology governance, and over-permissioning.
Not treating OAuth integrations as implicitly trusted Just because you set up an OAuth integration does not mean the external party should be trusted with long-lived access or many permissions. OAuth connections should be well-scoped with fine-grained access, and tokens should be cycled often. In the case of Vercel, doing so would have limited the blast radius significantly.
Context-dependent authentication mechanisms The bulk of API breaches occur via authenticated access, and this breach was no different. If access decisions had incorporated context, such as IP, device, or anomalous behavior, the lateral movement from the compromised OAuth session could have been flagged and prevented.
Better governance of third-party applications Compromised third-party SaaS can be highly damaging. Notably, Vercel's architecture allowed for a single employee to compromise the organization with a single third-party connection. If there were more oversight on tooling use, security teams could have caught the defects inherent in the external platform.
Safeguarding all credentials and API keys The onus is on customers as well. In this breach, the real risk for Vercel customers had to do with any credentials that were not encrypted using Vercel's "sensitive" feature. So, there is an argument to be made for using your platform's native security features.
AI Amplifies The Need For Zero-Trust
The Vercel breach is a classic case of shadow tech. An employee integrates a third-party application, likely without considering the security consequences of their actions, and the connection comes back to haunt them.
The compromise also highlights a weak chain in today's heterogeneous enterprise systems: Even valid, OAuth-compliant integrations can shelter malicious access to internal systems.
Responding to this reality will require a zero-trust approach, founded upon intelligent token-handling practices, and a careful identity and access management architecture bolstered by continuous verification.
Unfortunately, the string of supply chain attacks will likely continue. And as organizations increasingly connect third-party tools via OAuth, especially AI-driven assistants, the attack surface is expanding.
As such, a new form of Access Intelligence is required to cater to just-in-time access and real-time authorization decision-making in the age of non-human identities.
How Access Intelligence Helps
Access Intelligence has two important principles:
Access requests are evaluated at runtime.
Access tokens convey just enough privileges and just-in-time access.
By continuously evaluating access requests at runtime, it is possible to evaluate the context and any required data before granting access. It allows organizations to adapt the process such as enforcing additional factors or approvals when deemed required. The decision is then reflected in the access token that carries the minimum information in the form of scopes and claims for APIs to grant or deny a request.
Just-enough privileges and just-in-time access are key characteristics for access tokens to mitigate risks associated with token leakage or privilege escalation. Instead of giving an AI agent full permissions all the time, they only receive the permissions needed for the current task and as long as needed.
Just-in-time access removes standing privileges and expires any access after a given time period. Agents have to request new access tokens which restarts the evaluation and issuing process. The result is a re-evaluated set of permissions ensuring an AI agent can only access what’s needed, for as long as necessary, which limits what a rogue agent or attacker can do with the access token.
The Takeaway: Continuously Protect All Integrations
The Vercel hack is a wake up call for how brittle the modern software supply chain actually is. These sorts of sophisticated, targeted supply chain attacks continue to occur, and they can have a very broad exposure field.
Given that today's enterprise landscape is so highly interconnected and reliant upon API-based connections, a breach within a single external dependency can have a cascading effect across many internal components. Access Intelligence limits the impact by continuously evaluating access and by only granting what’s needed for a given purpose in the first place.
Just because you add an application via OAuth doesn't mean it's secure. OAuth must be governed with the proper scopes, token lifetime, and trust decisions to protect its use. Modern enterprises should treat all their connections and integrations with the care and rigor they deserve.
Preventing these sorts of breaches and customer leakages will hinge on treating every integration as untrusted by default, and continuously verifying access.
