OAuth consent has emerged as a critical security vulnerability that bypasses traditional authentication like MFA and passwords, granting attackers persistent, automated access that survives even password resets and account offboarding.
TL;DR: In a live demo on a recent Dark Reading webinar, it took Material's Rajan Kapoor less than a minute to go from a phishing email to a fully exfiltrated mailbox, a command-and-control console into Google Drive, and an attempted pivot into Slack. No password. No MFA prompt. Just one click on "Allow."
The mechanics are almost insultingly simple. A phishing email leads to a familiar-looking OAuth consent screen for what looks like a legitimate productivity or AI app. One click to connect an account, one click to accept the scopes, one click to continue. From there, everything runs on its own: every email in the account gets copied out in bulk, a command-and-control view opens into Drive and Gmail, and the attacker can search for sensitive files, send mail as the victim, and quietly cover their tracks. Rajan Kapoor, Material's VP of Security, described the moment he built the demo app this way: "I just woke up and chose violence one morning."
No credentials were phished. No endpoint was touched. The victim clicked one button, and everything else happened on infrastructure the attacker controlled. That's the argument at the center of a recent Dark Reading webinar featuring Kapoor and Gabe Bello, Staff Security Engineer at Twilio: consent is the new vulnerability. Every dollar an organization has spent hardening passwords, deploying MFA, and locking down endpoints does nothing to stop an attacker who gets a user to authorize the wrong app.
Why consent bypasses everything you've already built
OAuth is an authorization protocol, not an authentication one. It was built to let apps keep working without a user handing over a password, and it was built, deliberately, so that access survives a password reset. Nobody wanted a password change to break every connected app. That design choice, reasonable enough a decade ago, is now a feature attackers rely on: reset the password, revoke nothing, and the token keeps working.
The same is true of offboarding. Suspend an account, even delete it, and the OAuth tokens issued to that account often remain valid until someone explicitly revokes them. Most organizations don't have that step in their offboarding checklist. The identity is gone, but the access isn't.
This is why OAuth doesn't show up in the controls most security teams already trust. It doesn't need MFA. It doesn't need a password. Once an app is authorized, it walks past every identity control built in the last two decades because it was never asked to use them again.
This isn't theoretical anymore
Several recent breaches follow this exact playbook, two stand out. In the Vercel incident, an AI productivity app called Context.ai was compromised and its OAuth tokens stolen. Attackers used those tokens to reach a Vercel account, found a secret sitting in Drive or a mailbox, and pivoted onto systems holding customer data. Material has written separately about the Composio breach, where a single compromised Gmail token led to a magic link, a corporate account, and access to more than 10,000 customer credentials.
Neither breach required a phished password. Both started with a token nobody was watching.
The governance gap is wide, and it isn't closing
Material surveyed security leaders on OAuth governance, and the numbers explain why these breaches keep happening. Eighty percent said automating OAuth lifecycle management is a critical priority, but half said they have no structured governance program at all. Of the half who do have some governance in place, a third rely entirely on manual review: an access request comes in, an analyst investigates, someone signs off. And even among organizations that have already bought a dedicated OAuth tool, 67 percent still report elevated concern. Buying a tool didn't make the worry go away, because most of what's on the market inventories grants at a point in time. It doesn't watch what happens after.
Security teams already know OAuth is a risk, so the gap isn’t a knowledge problem. It's a capacity problem, and it's getting worse. AI adoption is increasing the number of connected apps that hold sensitive or restricted scopes, compounding exposure and ramping up the risk if a token is stolen.
Connecting a static tool like DocuSign allows a small number of predictable things to happen. But agents respond to prompts, and what they do in response to those prompts isn't fully knowable in advance. Securing that requires the same continuous monitoring as securing against an attacker, because from a monitoring standpoint, the two problems look remarkably similar.
Meanwhile, security headcount didn't move at all.
The case against building this yourself
For years, security teams that wanted real OAuth governance had to build it themselves, because nothing on the market did the job. That calculus has changed. Building now means taking on a permanent product commitment, not a side project: someone has to own it, iterate on it, and keep pace with every new attack pattern, indefinitely. Twilio's own experience building this kind of tooling internally is a useful data point, not because building was the wrong call years ago, but because the market has caught up to what most teams actually need.
Securing OAuth, sensibly
With all this in mind, three things become clear:
- You can't secure what you don't manage.
- Manual review doesn't scale, and security headcount never grows as fast as the business does.
- And attackers aren't the only thing accelerating this problem: AI agents are too.
Because OAuth grants are persistent, none of this is solved by a better password policy. It's solved by treating every OAuth grant as something to watch, not just something to approve once.
For a team with no governance in place today, the fastest first step to a fix isn't pulling resources to build bespoke tooling. It's turning on allowlisting immediately. That won't undo what's already been granted, but it stops new risk from walking in the front door while the rest gets sorted out.
Solutions like Material’s OAuth Remediation Agent are designed to help lean teams scale their OAuth security initiatives. The agent scales your team’s ability to respond to risk and active threats in your environment, while Material’s other features protect the information accessed by these apps, reducing the blast radius and creating guardrails for AI agents.
Watch the full webinar on demand to see the complete attack demo, plus the Q&A on exactly what an attacker keeps after a password reset, what offboarding actually needs to revoke, and where a small security team should start on Monday morning.
