Taming OAuth Sprawl: What the Vercel Breach Should Teach Every Security Team

Last week, I co-hosted a webinar with my friend and fellow security engineer Frank Wang on a topic that's been keeping me up at night: OAuth sprawl and what I believe has been one of the most overlooked attack surfaces in enterprise security today. The timing felt urgent because Vercel had just disclosed a breach over the weekend that put OAuth squarely in the spotlight. I wanted to share the key takeaways from that conversation.

A Live Demo Is Worth More Than a Thousand Slides

To open the session, I did something a little unusual: I built a malicious OAuth app and demonstrated it live. Using completely free infrastructure from Cloudflare and Google, I created a fake productivity tool called "Workspace Pilot" that promised to AI-triage your inbox.

The demo was sobering. Within moments of a user connecting the app:

• Data exfiltration: All emails from the mailbox were silently exfiltrated to an attacker-controlled Google Sheet within seconds
• Command and control: Files from shared drives (even ones not owned by the user) were searchable and downloadable
• BEC: The attacker could send emails on the victim's behalf and delete messages

And none of it was visible to the end user. Their inbox looked completely normal.

I built this to illustrate the fact that OAuth is a powerful, nearly invisible doorway into accounts. And right now, most organizations aren't watching it.

Breaking Down the Vercel Breach

The Vercel incident is a textbook example of how OAuth attacks unfold. Based on statements from both Vercel and Context (the third-party vendor involved), here's what we know:

1. Context's production infrastructure was breached — we don't know exactly how, and Context hasn't confirmed the specifics.
2. OAuth tokens were stolen — these refresh tokens are persistent keys. Unlike a session cookie, they don't expire easily and can be used from anywhere.
3. Attackers used those tokens to access a Vercel employee's Google Workspace account — legitimate, authorized access, repurposed for unauthorized use.
4. Customer data was reached — our best guess is that attackers found credentials, API keys, or tokens stored inside that workspace account that allowed them to pivot into production systems.

Frank put it well: the vast majority of attacks still involve stolen credentials at some point in the chain. What's notable here is that this attack against Vercel didn't start with a phished username and password. OAuth access was the entry point and credentials inside the mailbox or Drive were the bridge to production.

Why OAuth Is the New Attack Vector

Frank and I talked at length about why attackers are increasingly turning to OAuth. The answer is simple: it's emerging as the path of least resistance.

We've made enormous strides on credential theft. Passkeys, hardware security keys, and phishing-resistant MFA are genuinely effective controls and a near perfect end-user experience. My own parents set up passkeys on their Target account without my help. That's how far we've come.

So attackers pivot and this time, OAuth is the pivot. It’s important to recognize that OAuth was never designed as a security mechanism. It was designed to connect apps without sharing passwords, scoring a huge functional win. But it was never built around least-privilege principles. Imagine an app that’s used to scan inboxes for receipts. When that app asks for the mail.google.com scope, it gets everything. There's no way to say "read only emails with the label 'receipt.'" You either grant full mailbox access or you don't use the app.

As Frank noted, apps are often designed to request maximum permissions upfront. This future-proofs their product roadmap at the expense of your account’s security.

The Management Problem Is Real

Here's the part that should concern every CISO: 45% of security teams are not actively managing OAuth risk, according to our own research at Material. That's not a critique, it's a reflection of reality.

When I talk to security teams, I hear the same things:

• "We turned on allow-listing, but now we're drowning in app review requests."
• "We did a one-time review when we onboarded Notion. Now it has email and calendar features we never approved."
• "The CEO says we can't slow down AI adoption."

Frank walked through what it's actually like to implement allow-listing at a startup. By the time you arrive, there's already a backlog of connected apps. You have to audit history and manage stakeholders, all while new AI productivity tools are being connected daily by employees who just want to make work easier and faster.

And once something is in your environment, the monitoring problem kicks in. Even if you catch that something looks wrong, the data may already be gone. I showed in the demo how quickly a mailbox can be fully exfiltrated. Detection after the fact doesn't help you.

Why DIY Isn't the Answer

A common reaction is: "Let's just build something internally to handle this." Frank and I spent time pushing back on that instinct.

OAuth risk management is a high-ambiguity problem. It requires understanding app behavior in context, tracking how that behavior changes over time, ingesting enormous amounts of telemetry, and making judgment calls that vary by company. That's not a problem that an internal LLM wrapper handles well.

You might save time on initial reviews, but then you become the product manager for a fragile system that breaks on edge cases in a domain where edge cases have real security consequences. Security teams are already stretched thin. Building here is not an investment that will provide leverage for your team.

What Good Looks Like

The cloud office — Google Workspace, Microsoft 365 — deserves the same detection and response investment we give to endpoints and cloud workloads. Just as CrowdStrike watches your endpoints and Wiz watches your cloud infrastructure, we need purpose-built tooling watching what happens inside your productivity environment.

What does that look like in practice? Here's a workflow I described in the webinar:

1. An employee requests a new app.
2. An agent picks up the request, gathers context, and checks against your existing approved inventory.
3. With new apps, the agent reviews the app's privacy policy, SOC 2 status, and permission scope against your risk tolerance.
4. A decision is made and documented.
5. If the app is malicious or overpermissioned, tokens are rejected and the OAuth app grant is removed.

And on the response side. detection alone isn't enough. You need an automated response that doesn't require waking up an on-call engineer at 2am to revoke a token.

The Audience Weighed In

At the end of the session, I ran a quick poll: "Do you feel like you have OAuth under control in your environment?"

The result was almost exactly 50/50.

That's the problem in a single data point. Half the security professionals on that call weren’t confident they had this under control. And as Frank noted, that 50% who think they're covered may be more confident than they should be.

Attackers know this. When they find a blind spot, they exploit it, methodically, patiently, and at scale.

Final Thought

OAuth isn't going away. OAuth 3.0 isn't even a spec — the last mentions stopped around 2012. The protocol we have is the protocol we'll be defending against for the foreseeable future. The AI wave is accelerating the problem, not creating it.

The question isn't whether this is a risk worth managing. It clearly is. The question is whether your team has the visibility, tooling, and automation to do it without burning out.

If you want to talk through what that looks like for your environment, reach out to us at Material Security. And if you want a different perspective on the build-vs-buy question and other security topics, check out Frank Wang's newsletter, Frankly Speaking, on Substack.