A few days ago Vercel confirmed a security breach. Media coverage framed it as “an employee whose Google Workspace account was compromised”. Technically correct, though incomplete.
The real story is more interesting, and much more uncomfortable for all of us.
What actually happened
A Vercel employee signed up for Context.ai, an AI tool for teams, using their corporate account. When connecting it, they did something we’ve all done at some point: accepted the OAuth permissions without reading them too carefully. In this case, “Allow All”.
So far, nothing out of the ordinary.
What nobody knew is that months earlier, in February, a Context.ai employee had downloaded cheats for Roblox. Cheats are scripts that let you cheat in video games. Something that, at first glance, has nothing to do with a corporate security breach.
But those scripts contained Lumma Stealer, an infostealer that quietly stole the employee’s credentials. With those credentials, the attacker accessed Context.ai’s AWS environment and obtained something very valuable: their users’ OAuth tokens.
What is an OAuth token? Without getting technical, it’s a string of characters that acts as a key. It tells a system “this third party has permission to access this user’s data”. It’s not a password, but it works just as well to get in.
And the Vercel employee was one of those users.
With that token in hand, the attacker accessed Vercel’s corporate Google Workspace, and from there reached customer environments and environment variables not marked as sensitive.
Nobody hacked Vercel directly. Nobody exploited a vulnerability in their code. They walked in through the door the employee had opened themselves, with good intentions, a while ago.
And this is the critical part. I’m not talking about Vercel. I’m talking about the modus operandi.
We often believe our website, company or service is protected from external attacks, and we take care to keep it that way. But sometimes the attack vector doesn’t come from what we keep out. Sometimes it comes from what we let in.
Picture your house with a doorkeeper at the entrance. That doorkeeper has a list of authorized people: family, friends, trusted individuals. Anything not on that list doesn’t get in. The analogy seems simple. Anyone with bad intentions stays out, because the doorkeeper has strict orders.
But what happens if the problem is brought to you by someone you do trust?
That was the case.
The real problem: OAuth is invisible
OAuth has a property that makes it dangerous in corporate contexts: once set up, it disappears from the radar.
When a developer connects a tool to the company’s workspace, the flow is:
- Click “Connect with Google”
- Permissions screen (that nobody reads)
- “Accept”
- Done, it works
And there it stays. Forever. With no expiration date by default. With no periodic review. Without anyone on the security team knowing it exists.
If you go into your Google account right now and head to myaccount.google.com/connections, you’ll probably find apps you don’t even remember authorizing. Some with access to Gmail. Others to Drive. Some with read and write permissions over everything.
Each of those connections is an attack surface that isn’t on your map. And they’re connections you accepted.
That’s why it’s important to review who and what apps have access to your data. I call this a digital detox. It’s a process I try to do every year. Tedious, heavy and tiring, yes. But nothing beats the peace of mind of knowing that only who you decide gets to access your data.
The vector nobody watches: supply chain attacks
The security mental model we’ve internalized is still, though necessary, insufficient: credentials meeting a set of digits, symbols, letters, etc. that don’t repeat, including MFA (Multi-Factor Authentication), keeping our devices and systems updated. All of that is correct. And necessary. Yet it’s insufficient when the attack vector breaks every scheme anticipated so far.
OAuth breaks that model by design. The threat doesn’t come from someone guessing your password or exploiting a CVE in your infrastructure because you didn’t keep your systems updated. It comes from one of the hundreds of SaaS services your team uses suffering a breach, and that service holding valid tokens to get into your systems.
You don’t need to attack Vercel. You attack Context.ai, which has access to Vercel. That’s a supply chain attack.
Or you attack the Notion plugin the product team connected six months ago. Or the analytics tool someone tried in a proof of concept and never disconnected. Or the automation service a developer authorized from their personal work account.
The attacker doesn’t need to exploit anything sophisticated. They just need to find the weakest link in the transitive chain of trust that’s been built.
Why this is going to get worse
The adoption of AI tools in corporate environments is accelerating exactly this problem. Every new “AI for teams” tool asks for access to your calendar, your email, your documents, your Slack. And the value proposition is real: the more access it has, the more useful it is.
The Vercel employee didn’t do anything strange. They tried an AI tool that promised to be useful and connected it to their work account. That’s what everyone does. That’s what I do. Probably what you do too.
The problem isn’t individual behavior. It’s that organizations have no visibility or control over the sum of those individual behaviors.
What can be done
There’s no perfect solution, but there are concrete starting points:
Inventory of OAuth integrations. If you don’t know which apps have access to your systems, you can’t protect them. Google Workspace, Microsoft 365 and most SaaS platforms have admin consoles where you can see and revoke third-party access. Most teams never look at them.
Authorization policy. Define which apps can connect to corporate resources, with what permissions and through what approval process. Not to block everything, but to have visibility. An informal authorization is still better than none.
Principle of least privilege applied to OAuth. If a tool asks for read and write access to your entire Drive when it only needs to read a specific directory, there’s a problem right there. OAuth scopes are granular by design; you have to use them.
Tokens with expiration and periodic review. Some platforms let you configure the expiry of third-party tokens. It’s not the norm, but when it’s available, turn it on.
Monitoring of third-party access. The access logs of your Google Workspace or Microsoft 365 record which apps access which resources.
Conclusion
The Vercel incident isn’t a story about a careless employee or an insecure AI tool. It’s a story about how the attack surface of modern organizations extends far beyond their own systems.
Every OAuth integration is a trust decision. And trust decisions have consequences that aren’t always visible until someone exploits them.
The question worth asking today isn’t “are our systems patched?”. It’s: “do we know who has access to our systems through other people’s systems?”
The answer is probably no. And that’s a problem no patch can solve. But it is one you can watch, if you know where to look.
See you on the net.
Álvaro (aka. BlackSheep4)