Security1 publisher2 min readPublished
Stolen OAuth tokens opened Gmail and Drive in both the Vercel and Composio breaches
A Help Net Security column reads the two intrusions as one sequence run twice, with the token first and the inbox second. It says the same four steps describe what an authorized AI agent does in Google Workspace every day.
The Watch · Security desk
What happened
- In the sequence it describes, the stolen OAuth token comes first, Gmail and Drive data second, and the takeover of the email account third, executed through OAuth.
- The column says those tokens survive password resets, do not expire and are hard to observe, so persistence is established at the first step of the chain instead of the last.
- It frames the stolen token as a supply chain attack, in which a supplier is compromised and the result is access into the customer's environment.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure The path starts at a supplier, so a customer's Gmail and Drive become reachable without anyone inside the customer's organization clicking anything.
- decision Response that ends with a password reset and MFA re-enrollment leaves the access in place, so containment has to include revoking the app grant.
- constraint Approving or blocking at the grant level cannot tell a stolen token from a sanctioned agent. Detection then falls to per-app behavior baselines nobody has budgeted for.
The column's claim is that the building blocks of the workspace attack chain have not changed and the sequence has [13]. In the old model, the first artifact is an email: a phishing link, a weaponized attachment, a pretext [3]. In the OAuth-first order there is no mail artifact at the front. The tokens are invisible to users and largely invisible to security teams that are not monitoring app behavior, according to the column [5]. The first thing a defender can see moves from the mail gateway to third-party app activity [1].
Once the token is in hand, the pivot runs on the workspace's own conveniences. The column describes credentials stored in Drive, plus password resets and magic links delivered to the mailbox the token already reads [8]. Access to email is what converts a compromised inbox into a much broader incident, it says [7].
The record here is one practitioner's reading of two named incidents. The piece calls Vercel and Composio "the same attack, run twice, against different targets, where email was not the entry point into the workspace" [1]. It groups them with a growing number of other incidents it says it is tracking [10]. It does not identify a threat actor, date either intrusion, or say how the tokens were obtained [11].
The second half of the argument is about software the company approved. An OAuth grant used to reach an account, read sensitive data from email and Drive, and move past the workspace [2] "doesn't only describe what attackers do. It increasingly describes what AI agents do, by design, every day," the author wrote [12]. Employees are connecting those agents now, with legitimate grants, operating on behalf of real users [9].
A stolen token and an employee's agent therefore present the same way in the authorization record: a third-party app reading Gmail and searching Drive for a user [2]. Allow-listing the grant covers both. Behavior is what's left: which mailboxes a grant touches, how much it reads, at what hour, and what the account does next.
What to watch
- Named, dated incidents from a second publisher with the same OAuth-first order would move this from one analyst's pattern to a tracked campaign.
- Any Vercel or Composio technical write-up explaining how the OAuth tokens were obtained.
- A Workspace admin control that expires or narrows third-party grants by default would undercut the persistence step.