The Modern Attack Chain: Rethinking Google Workspace Security in the Age of AI

Summary

The article argues that traditional Google Workspace security models, which focus on email as the primary attack vector, are outdated. Recent breaches at Vercel and Composio illustrate a new attack chain where stolen OAuth tokens serve as the initial entry point, granting access to sensitive data in Gmail and Drive before leading to account takeovers. This evolving threat landscape requires organizations to rethink their defenses beyond just email security.

Full text

The Modern Attack Chain: Rethinking Google Workspace Security in the Age of AI Sponsored by Material Security August 14, 2026 10:00 AM 0 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. See How Material Covers Every Step of the Attack Chain The attack chain in this article doesn't stop at the inbox, and neither should your defenses. See how Material connects email, OAuth, and Drive security to close the gaps attackers and AI agents both exploit. Book a demo for your Google Workspace. Request a Demo 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 a

Entities