What Vendor Risk Teams Can Learn from the Vercel Breach

What happened

In April 2026, Vercel confirmed a security breach that exposed internal systems and customer environment variables. The root cause wasn't a sophisticated zero-day exploit. It was a single employee using a self-serve AI tool, Context AI, with broad OAuth permissions on their work account. An attacker breached Context AI's AWS environment, stole OAuth tokens, and used them to access Vercel's internal Google Workspace. For the full details, see Vercel's official bulletin: vercel.com/kb/bulletin/vercel-april-2026-security-incident

Vercel wasn't a formal Context AI customer. The employee had signed up personally for Context's self-serve consumer product using their work account.

What we can learn

1. Blast radius: same incident, different exposure

Every Vercel customer read the same bulletin. Very few face the same risk.

One company uses Vercel for a static marketing site. Another has wired it into their production pipeline, with source code and environment variables in scope. Same incident, completely different exposure.

The blast radius is the actual reach a third party has into your business, and what breaks if they're compromised. Mapping it before an incident means that when a bulletin drops, "what does this mean for us?" is already answered.

As an example, Lema flagged Vercel as high inherent risk for one of our customers based on code access granted as part of their deployment setup.

2. Shadow IT: Context AI was never in Vercel's vendor inventory

Context AI was never approved, procured, or inventoried by Vercel's security team. It was a consumer product one employee chose to use with their work account.

This is shadow IT in its most literal form, and it's where most TPRM programs have no visibility. Vendor inventories capture what procurement approves. They don't capture what employees adopt on their own.

Monitoring identity and access integrations across tools like Google Workspace can surface exactly this: OAuth apps connected to your environment that your security team never sanctioned. In Vercel's case, that signal existed. It just wasn't being watched.

3. OAuth access and scope drift: one click is all it takes

A single employee clicking through an OAuth consent screen gave Context AI enough access to their work Google Workspace to turn a breach of Context AI into a breach of Vercel. No admin approval, no security review, no procurement. Just a consent prompt.

That's the shape of the risk, and it's not a one-time event. OAuth apps can enter your environment with narrow, seemingly harmless permissions, and expand over time through new consent prompts, added scopes, or configuration changes. A tool that was low risk at assessment can quietly accumulate access afterward. This is scope drift — and point-in-time reviews can't catch it, because the review was fine. The exposure is built after.

Monitoring OAuth apps connected to your environment, and tracking how their permissions change over time, is how this kind of exposure gets caught before the next breach turns into yours.

4. Fourth-party risk: your vendors have vendors too

Even if Vercel had a mature third-party risk program, Context AI likely wouldn't have appeared on it, because Vercel wasn't a customer. There was no formal relationship to review.

But fourth-party exposure doesn't require a formal relationship to create real risk. Any vendor your vendors are connected to, through OAuth, API integrations, or shared infrastructure, is part of your extended attack surface. And the data you share with your vendors can flow to their vendors too, often without your knowledge or explicit consent.

If you're a Vercel customer, Context AI wasn't on your radar — and it shouldn't have needed to be. You vetted Vercel. The breach reached your environment variables anyway, through a tool one Vercel employee signed up for on a Tuesday afternoon.

That's the fourth-party gap. Deeper questionnaires won't close it. The only real way to monitor fourth-party risk is to make sure your most critical vendors operate as Risk Engineers themselves, catching unsanctioned third parties and OAuth apps in their own environment before those become your incident.