"They're the same attack, run twice, against different targets, where email was not the entry point into the workspace." — Rajan Kapoor, VP Security, Material Security.
From an inbox-centric worldview to an OAuth-first breach model
For years, defenders treated email as the primary danger zone in Google Workspace. The traditional attack chain described in Rajan Kapoor's account begins with a malicious email, leads to stolen credentials and an account takeover, then expands into Gmail and Drive, enabling lateral pivots and long-lived persistence. That mental model — email is entry, credential theft follows, and the inbox is the launching pad — "made sense when attackers were primarily trying to steal credentials through phishing," Kapoor writes.
But Kapoor describes a recurrent pattern observed across incidents such as the Vercel and Composio breaches that flips the script: the initial foothold is an OAuth grant. In those cases, a stolen OAuth token provided persistence, survived password resets, and remained largely invisible to users and teams that weren’t monitoring application behavior. The token functions as a supply-chain vector when a supplier is compromised, and it gives attackers direct access to Gmail and Drive — turning OAuth into the entry point rather than a secondary escalation.
How the OAuth-first chain unfolds in practice
Kapoor lays out a four-step sequence seen repeatedly: (1) an OAuth token is established or stolen and becomes the persistent entry; (2) sensitive data in Gmail and Drive is read using that access; (3) the attacker converts the OAuth access into a traditional account takeover of email; (4) lateral movement follows, leveraging credentials found in Drive and password reset or magic-link workflows in email.
Two features make this chain especially dangerous, according to the account: OAuth tokens can persist through password resets and are difficult to observe, and attackers can use access to inbox content — including password reset links — as a pivot to other systems. The practical consequence is that protections focused only on inbox defenses miss the initial, and in many cases decisive, attack vector.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildWhen AI agents travel the same path as attackers
Kapoor draws a deliberate parallel between malicious operators and the growing class of authorized AI agents. Employees are "connecting AI agents to Google Workspace right now," he notes, and those agents are granted legitimate OAuth scopes. The trouble arises when an agent's scope is broader than its task or when its instructions produce unexpected behavior.
In that mode an agent can: reach into an inbox or Drive folder it wasn't intended to access; read sensitive content such as credentials in email threads or confidential Drive documents; take downstream actions like sending messages or following links; and move laterally across other applications, ultimately leaking sensitive data to third parties. Importantly, there need be no stolen credential and no malicious intent — "just an agent doing something its operator didn't intend, in an environment that didn't have the controls to stop it."
Controls that focus on the workspace, not only on agents
Kapoor argues that the defense that matters is not primarily about policing the agent's internal prompts, but about constraining the environment the agent (or attacker) operates in. That starts with visibility: "You can't protect what you can't see," he writes, and Material's approach emphasizes mapping where sensitive data resides across email and Drive so policies can restrict access before an entity reaches it.
Specific controls Kapoor highlights include: blocking sophisticated email payloads that bypass native filters; detecting suspicious OAuth behavior by observing what apps actually do (when they read data and how behavior changes over time) rather than just cataloging scopes; discovering sensitive files and exposed shared drives so least-privilege can be enforced; and redacting sensitive message content — notably password-reset links — while requiring step-up verification before such content becomes readable. Redacting reset links prevents an actor with inbox access from using that access as a pivot, he notes, and the same restriction applies whether the actor is human or an automated agent.
What this means for security teams, procurement leaders, and end users
- Security teams and technologists: Track OAuth activity at the activity layer, not only via app inventories. Prioritize visibility into Drive and email content so you can enforce least-privilege and detect anomalous app behavior before lateral steps occur.
- Affected enterprises and procurement leaders: Treat OAuth-connected suppliers as first-class elements of the supply chain. A compromised supplier can deliver an OAuth-based foothold into your workspace; vet integrations and plan for token persistence that survives password resets.
- End users and the general public: Be aware that authorized AI agents may act beyond their intended scope and that protections such as redaction and step-up verification change what an agent can see and do with inbox content.
Kapoor's central point is stark and practical: the modern attack chain runs where defenders have not always looked. Whether the actor is an external attacker, an overpermissioned integration, or an AI agent operating as designed, the vulnerabilities are the same. Defenses that see the chain end-to-end — across email, OAuth, Drive, and account behavior — are the corrective he recommends. For organizations that still treat the inbox as ground zero, the lesson is simple: the gap is where attackers, and increasingly authorized agents, will run.
Original story — The Modern Attack Chain: Rethinking Google Workspace Security in the Age of AI
