By Rajan Kapoor, VP Security, Material Security

Over the past two months, I've written about the Vercel breach and the Composio breach separately. Both offer lessons to learn on their own. But reading them together, I keep coming back to the same observation: these aren't isolated incidents

They're the same attack, run twice, against different targets, where email was not the entry point into the workspace. And once you see the pattern clearly, it changes what you think you need to defend.

It also raises an uncomfortable question that I've been sitting with. The pattern I'm describing, where an OAuth grant is used to access an account, read sensitive data from email and Drive, and use that access to move past the workspace, doesn't only describe what attackers do. It increasingly describes what AI agents do, by design, every day.

Before jumping into that discussion, let’s take a moment to map out the workspace attack chain.

The old mental model: email is where the danger lies

For most of the last decade, the dominant mental model for workspace security looked something like this: email is the dangerous channel, and everything else in Google Workspace is relatively safe.

That model made sense when attackers were primarily trying to steal credentials through phishing. It doesn't hold anymore because attackers have learned to chain their way through the workspace, not just get in via an inbox.

The model most security teams are familiar with looks something like this:

• Email is the entry point: A malicious email (a phishing link, a weaponized attachment, a convincing pretext, a prompt intended to misdirect an AI agent) is how most attacks begin.
• A credential is stolen: The attack results in a valid credential being stolen and an account takeover happening.
• Sensitive data is accessed in Gmail and Drive: Once the takeover happens, the attacker easily jumps to connected apps within Google Workspace.
• Lateral pivots: An attacker inside an inbox can reset passwords and get into additional apps via magic links.
• Establish persistence: Attackers can sit undetected within accounts for days, weeks, or months, quietly exfiltrating data across systems.

Taken together, this is the nightmare scenario that is widely recognized as the account takeover (ATO). The workspace attack chain begins with an identity compromise via email and expands from there.

The evolving attack chain: OAuth is the entry point

The elements of the workspace attack chain attack haven’t changed, but the order in which the attacks unfold has evolved. The sequence I've now watched play out across Vercel, Composio, and a growing number of incidents we're tracking doesn’t start with email at all.

Instead, the script gets flipped and an OAuth token becomes the entryway into email, not the other way around.

Here’s what these attacks looked like:

• OAuth is the entry point: These attacks started by establishing persistence through a stolen OAuth token. These tokens survive password resets, don’t expire, and are hard to observe. They are invisible to users and largely invisible to security teams who aren’t monitoring app behavior. Even scarier, the stolen token is a supply chain attack. A supplier is compromised and the result is access into your environment.
• Sensitive data is accessed: Using the stolen token, the attacker was able to get into data stored in Gmail and Drive.
• Email accounts are taken over: The ATO is initially executed using OAuth, not email. The access to email converts a compromised inbox into a much broader incident.
• Lateral pivots: Using a combination of credentials stored in Drive and password resets or magic links via email,the attacker can then move laterally across connected systems.

We can anticipate that the building blocks of the workspace attack chain will remain consistent, but that attackers – equipped with AI tools to sniff out vulnerabilities and scale their efforts – will continue to find ways to recombine them.

These OAuth-centric attacks are only one example of this evolution.

The same chains, a different actor

Now let’s shift our thinking, while keeping those four-step sequences I just described in our minds.

Your employees are connecting AI agents to Google Workspace right now. Those agents are authorized. They're using legitimate OAuth grants. They're reading email, searching Drive, operating on behalf of real users to do real work. In most organizations, this is happening faster than security teams can track it.

When an AI agent behaves unexpectedly — because its instructions were ambiguous, because it followed a chain of reasoning its developers didn't anticipate, because it was fed a prompt through content it encountered in the environment — it can walk the same path as an attacker:

• It accesses an inbox or Drive folder it wasn't explicitly intended to reach, because its scope was broader than its task required.
• It reads sensitive content like credentials in email threads or confidential documents in shared drives and makes use of that information.
• It takes an action downstream from that access: sending a message, following a link, making a request to another service.
• It moves laterally across applications and sensitive information winds up getting exfiltrated to a third party.

No malicious actor. No compromised credential. Just an agent doing something its operator didn't intend, in an environment that didn't have the controls to stop it.

Why this matters for how you think about defense

Most conversations about AI agent security are framed around preventing prompt injection, red-teaming agent behavior, or reviewing what apps your employees are connecting. Those are real problems and worth solving.

But the threat I'm describing isn't about an agent being weaponized. It's about an agent operating exactly as it was built to operate, in an environment where the guardrails weren't designed with that kind of actor in mind.

A human operator acting in an environment where they’ve been overpermissioned will generally know how to navigate this situation using a combination of common sense and understanding of company norms and policies.

OAuth tokens granted to an AI agent carry the same access as tokens granted to a person, but the agent won’t understand that it’s been overpermissioned before it acts. It will simply do what it needs to do in order to execute the task.

The controls that matter here aren't controls on the agent. They're controls on the environment the agent operates in.

If you know where sensitive data lives across email and Drive, you can enforce policies that restrict access to it before an agent (or an attacker) gets there. If you're investigating OAuth grants, you can understand and limit exposure to the prying eyes of an attacker or an errant agent.

If you can redact password reset links and require step-up verification before sensitive inbox content is readable, it doesn't matter whether the entity trying to access that content is an attacker or an agent acting outside its intended scope.

The same coverage that defends against the modern attack chain also defends against the modern agent risk. They're the same problem, wearing different hats.

What defense looks like across the full chain

I don't think the answer is to add more point solutions to each stage of this chain. I think the answer is coverage that understands the chain as a chain, that can see what's happening across email, OAuth, Drive, and account behavior, and connect the dots before things go wrong at step three or four.

That's what we've built at Material. Here's how our coverage maps to each step:

Blocking the initial email payload. Our email security is designed to catch what native controls miss: sophisticated phishing, payloads that bypass reputation-based filters, attacker-in-the-middle techniques. Stopping the most common attack method before it starts remains the highest-leverage intervention for the malicious threat.

Detecting suspicious OAuth behavior. Material goes beyond cataloging what apps exist and what scopes they hold.

The platform watches what apps actually do: what they read, when they read it, how that behavior changes over time. Whether an OAuth token is being used by an attacker or an AI agent operating outside its intended parameters, anomalous behavior at the activity layer surfaces the danger.

Detecting and protecting sensitive data at rest. You can't protect what you can't see, and you can't design a policy around access you don't know exists.

Material's file security gives teams visibility into where sensitive data lives across email and Drive: which shared drives carry broad access, which email threads contain credentials or PII, which Drive folders are exposed beyond their intended audience. This is the foundation for enforcing least-privilege access against any actor, human or automated.

Blocking lateral movement via password resets. Material can redact sensitive message content, including password reset links, and require step-up verification before that content becomes accessible.

An attacker with inbox access can't use it as a pivot point if the reset links aren't available in plaintext. An AI agent reaching the inbox looking for something to act on encounters the same restriction.

The pattern is going to repeat

Vercel. Composio. I expect this list will keep growing, and I expect the next entries on it won't always fit neatly into the category of "external attacker."

Some of them will involve AI agents doing something unexpected. Some will involve overpermissioned integrations that reach data they were never supposed to see. The mechanism will look familiar even when the story around it doesn't.

The right response isn't to be alarmed about AI agents or to slow down adoption. Agents are genuinely useful and the productivity case for them is real.

The right response is to recognize that the workspace those agents operate in needs controls that are appropriate for a world where OAuth-authenticated software (authorized or not) is a first-class actor in your environment.

If your Google Workspace security strategy ends at the inbox, it has a gap. That gap is exactly where the modern attack chain runs, and it's exactly where an AI agent operating outside its intended scope will run too.

If you want to talk through what full-chain workspace coverage looks like for your environment, reach out to us at Material Security.

Sponsored and written by Material Security.