The OAuth grant is the front door now, and Workspace controls are still watching email

Rajan Kapoor, VP Security at Material Security, has published an argument in BleepingComputer that the Vercel and Composio breaches were not two separate incidents but the same attack run twice against different targets, with email absent from the entry point ^[1][2][3]. If that reading is right, the control set most teams built for Google Workspace is guarding a door the attacker no longer uses.

The familiar chain is well worn: a malicious email lands, a credential is stolen, an account takeover follows, the attacker reads Gmail and Drive, pivots through password resets and magic links, and sits undetected for days, weeks or months ^[6]. That model was built for a period when attackers were mainly after credentials via phishing, and Kapoor's contention is that it no longer holds because attackers chain through the workspace rather than merely getting in through an inbox ^[5]. The unstated assumption underneath it was that email is the dangerous channel and the rest of Workspace is comparatively safe ^[4].

In the sequence Kapoor describes, the building blocks are the same but the order is inverted. Persistence comes first, through a stolen OAuth token ^[7]. The token is then used to reach data in Gmail and Drive ^[10]. The account takeover is executed via OAuth rather than email, and it is the resulting email access that turns a single compromised account into a broader incident ^[11]. Only then come the lateral pivots, using credentials found in Drive together with password resets and magic links sent to the inbox ^[12]. Put plainly, what was step one in the old model has become step three ^[18].

The properties of the token are the reason this matters operationally. According to Kapoor, OAuth tokens survive password resets, do not expire, are invisible to users and largely invisible to security teams that are not monitoring app behaviour ^[8]. He also frames the stolen token as a supply chain problem: a supplier is compromised, and the outcome is access into your environment ^[9]. A forced password reset and an MFA re-enrolment, the standard account takeover playbook, do not touch any of that.

Then the uncomfortable part. The pattern Kapoor sets out, an OAuth grant used to read email and Drive and then to move past the workspace, is also a description of how AI agents behave by design, every day, as employees connect them to Google Workspace ^[13][14]. Detection that keys on the shape of the behaviour will fire on the sanctioned integrations too.

Two caveats on provenance. This is a vendor byline: Kapoor's employer sells a product that connects email, OAuth and Drive security, and the article carries a request-a-demo call to action ^[1][16]. And the evidence is his own, drawn from Vercel, Composio and a growing number of incidents his company says it is tracking ^[15]. The piece supplies no dates, no token scopes, no victim counts and no attribution for either named breach, so the pattern claim cannot be checked against the underlying incidents from this material alone ^[17].

What to watch: whether your OAuth grant inventory is reviewed on the same cadence as your password policy, whether token revocation is part of offboarding and incident response rather than an afterthought, and whether anything in your tooling can tell an attacker's grant from an agent's grant when both read Gmail and Drive at scale. Kapoor's own expectation is that the building blocks stay constant while attackers, using AI tooling to find and scale, keep recombining them ^[19].