- Book: AI Agents Pocket Guide
- Also by me: LLM Observability Pocket Guide
- My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
- Me: xgabriel.com | GitHub
On April 19, 2026, Vercel published a security bulletin describing an incident that did not start at Vercel. According to Vercel's own knowledge-base disclosure and Context.ai's security update, the chain looked like this. A Context.ai employee's machine was compromised by infostealer malware. Trend Micro's analysis identified the family as Lumma Stealer, and Reco's writeup dates the initial foothold to February 2026. That foothold gave the attacker access to OAuth tokens belonging to Context.ai's AI Office Suite users. One of those tokens belonged to a Vercel employee who had granted Context.ai broad Google Workspace scopes from their Vercel-managed Google account. The attacker used the token to take over that Workspace identity, pivoted into Vercel's environment, and ultimately accessed a subset of non-sensitive customer environment variables. Vercel reached out to a small number of affected customers and told them to rotate.
TechCrunch and Help Net Security covered the disclosure within a day. Trend Micro framed the incident as an OAuth supply-chain attack, which is the label that matters.
Two things are worth saying up front. First, by Vercel's account the data exposure was bounded — non-sensitive environment variables for a small number of customers. Second, the structural lesson is not the malware at Context.ai. It is that a third-party AI tool, granted workspace-wide OAuth scopes by one employee, was a viable pivot into a major platform's production. The pattern generalizes far beyond Vercel.
The shape of the new attack surface
Most engineering orgs in 2026 have somewhere between 30 and 200 AI tools wired into their workspace. A partial inventory looks like this:
- Coding assistants with repo and PR scopes.
- Note-taking and meeting-summary bots with calendar and Drive read scopes.
- Sales-intelligence and CRM enrichment with Gmail read scopes.
- Customer-support copilots with helpdesk and shared-inbox scopes.
- MCP servers granted org-account access to internal SaaS.
- Browser-automation extensions with cookie access.
- "Personal productivity" agents wired to a workspace identity.
Each of those tools is a small SaaS company. Each has employees. Each can be infected with infostealer malware. And each, if granted broad OAuth scopes from a workspace identity that also has access to production, is a viable lateral path.
The attacker's path of least resistance has shifted. Phishing the Vercel employee directly would have to get past 2FA, anomalous-login detection, and a security team that is paid to be paranoid. Phishing the Context.ai employee, then walking through the OAuth grant they handed out, bypasses every one of those controls. The grant was issued voluntarily, the tokens are valid, the API calls look normal.
This is not a Vercel problem. It is the predictable outcome of letting AI-tool sprawl outpace OAuth-scope governance.
What goes on the new audit checklist
Five questions worth asking about every AI tool, MCP server, or agent integration with workspace or org-account access:
1. What scopes did it actually request, and what did the employee grant? OAuth consent screens default to all-or-nothing for many SaaS tools. Vercel's bulletin indicates that broad Google Workspace scopes were granted in this case. Audit what was actually granted. In most consent flows that equals what was requested, but verify rather than assume.
2. Whose identity does it run under? A workspace-wide grant from an admin account is a different blast radius than a grant from an individual contributor. Both exist. Both should be inventoried.
3. Where does its egress go? The vendor is named. The vendor's subprocessors are usually not. A model gateway sitting in front of a third-party LLM provider sitting in front of an analytics processor is a three-link chain, and a compromise at any link is a compromise of your data.
4. How are its tokens stored, rotated, and revoked? The Context.ai incident shows that token theft is the realistic compromise mode. Tokens with long-lived refresh capability and broad scopes are the asset. Short TTLs and scope minimization shrink the asset.
5. What does it touch that it should not? A meeting-summary bot does not need Drive write. A coding assistant does not need calendar. The principle is old. The discipline is new.
The useful question is not whether you trust the vendor. Vendors say the right things by default. What matters is the blast radius the day they are compromised. The Vercel incident is the worked example.
A 30-line auditor for Google Workspace OAuth grants
Below is a script that pulls every OAuth grant in a Google Workspace domain via the Admin SDK and flags any AI-shaped tool with workspace-wide read scopes. It assumes a service account with admin.directory.user.security and admin.directory.user scopes, delegated domain-wide. Source for the API surface: Google's Directory API tokens docs.
from googleapiclient.discovery import build
from google.oauth2 import service_account
SCOPES = [
"https://www.googleapis.com/auth/admin.directory.user.security",
"https://www.googleapis.com/auth/admin.directory.user.readonly",
]
AI_HINTS = (
"ai", "gpt", "llm", "agent", "copilot",
"context", "claude", "openai", "anthropic",
)
BROAD_SCOPES = (
"drive", "gmail.readonly", "gmail.modify",
"calendar", "spreadsheets", "documents",
)
The two tuples above are the entire policy surface of this audit. AI_HINTS is the heuristic for "does this app look like an AI tool"; replace it with your IT-managed allowlist if you have one. BROAD_SCOPES is the list of scope substrings that map to data-exfiltration risk. Both are intentionally short; the point is to fit the rule on one screen and let you change it without reading the rest of the script.
The rest is a per-user, per-token walk over tokens.list from the Admin SDK:
def audit(domain, sa_file, admin_email):
creds = service_account.Credentials.from_service_account_file(
sa_file, scopes=SCOPES
).with_subject(admin_email)
directory = build("admin", "directory_v1", credentials=creds)
users = directory.users().list(
domain=domain, maxResults=500
).execute().get("users", [])
for u in users:
email = u["primaryEmail"]
tokens = directory.tokens().list(
userKey=email
).execute().get("items", [])
for t in tokens:
name = (t.get("displayText") or "").lower()
scopes = t.get("scopes", [])
ai_match = any(h in name for h in AI_HINTS)
broad = [s for s in scopes if any(b in s for b in BROAD_SCOPES)]
if ai_match and broad:
print(f"{email} | {name} | {len(broad)} broad scopes")
for s in broad:
print(f" - {s}")
Two things this script does on purpose:
It is name-based. The string match against AI_HINTS will miss tools that do not advertise themselves as AI in their app display name. For a real audit, replace that heuristic with your IT-managed allowlist of approved AI vendors and treat anything outside it as a hit.
It only flags read-side scopes that map to data exfiltration risk. For full coverage, expand BROAD_SCOPES to include write scopes (drive.file, gmail.send) and admin-flavored scopes (admin.directory.*).
The output is a per-user, per-tool list of grants worth a conversation with the employee who granted them. The conversation is short: "Did this tool need full Drive read? If yes, why? If no, revoke and we will see if anyone notices."
Continuous monitoring, not one-time audit
A run of this script catches the snapshot. A breach happens between snapshots. Three pieces of continuous instrumentation worth wiring up:
- Alert on new OAuth grants to non-allowlisted apps. The Admin SDK's audit log surfaces token grants. Stream them to your SIEM and route any non-allowlisted display name to the security channel.
- Anomaly-detect on third-party API egress. Per-app, per-day token-bytes-out from each major SaaS. A vendor doubling its read volume is a signal.
- Watch for first-time geographies. Geolocation and device-fingerprint deltas on AI-tool-issued sessions are cheap to compute and high signal — first-time geographies on a session minted via a third-party OAuth grant deserve a look.
None of this is novel. All of it is underused for AI-tool integrations specifically because the tools are new, the procurement path is informal ("a developer signed up with their work email"), and the OAuth consent screen is a spot where security teams have not historically had eyes.
What changes from here
The honest framing of the Vercel-Context.ai incident is that it is the first widely-reported example of a category, not a one-off. AI tools are SaaS, the SaaS supply chain has been under attack for years, and adding broad workspace scopes to dozens of small AI vendors is exactly the kind of expansion the attack pattern was waiting for. The Hacker News writeup is worth reading for the timeline detail, and Reco's analysis walks the OAuth pivot step by step.
The work that pays off in the next twelve months is unglamorous: an inventory of every AI integration with workspace scope, a policy on who can grant scopes from production-adjacent identities, monitoring on the grants themselves, and a tested revocation runbook. The script above is one Sunday afternoon's worth of work to get started. The vendor list it produces is what you need to stop guessing about your AI-tool blast radius.
If this was useful
The AI Agents Pocket Guide covers the patterns for designing agent integrations that fail safely — scope minimization, token isolation, egress allowlists, the architecture choices that matter when an agent has org-account credentials. The LLM Observability Pocket Guide is the companion on the monitoring side: how to instrument agent egress, OAuth-grant changes, and per-tool data flows so a Context.ai-shaped incident lights up before the news cycle does.
Top comments (0)