A Vercel employee trialled a deprecated consumer‑grade "AI Office Suite" from Context.ai and granted it Google Workspace access via OAuth — a self‑service connection that persisted long enough for attackers, after breaching Context.ai, to pivot into Vercel's environment.
The Vercel–Context.ai chain: OAuth grants as persistent bridges
The incident with Vercel is a clear, step‑by‑step illustration of a common failure mode. An employee connected Context.ai to their Google Workspace tenant during a trial. Vercel was not a registered Context.ai customer, but that did not prevent a self‑service OAuth grant from creating a durable, programmatic bridge between the two environments.
When Context.ai was compromised — reportedly following an infostealer infection tied to an employee searching for Roblox cheats — attackers used OAuth tokens stored in Context.ai's environment to pivot downstream. In Vercel's case the affected Google Workspace account had broad permissions, including access to dashboards, employee records, API keys, NPM tokens, and GitHub tokens, any of which can materially expand an attacker's foothold.
OAuth attack patterns: supply‑chain abuse and device‑code phishing
OAuth exploitation is not unique to AI apps. The report cites large, OAuth‑driven supply‑chain intrusions in 2025 after breaches at Salesloft (specifically the Salesloft Drift platform) and Gainsight. Those incidents affected more than 1,000 organizations — including Google, Cloudflare, Rubrik, Elastic, Proofpoint, JFrog, Zscaler, Tenable, Palo Alto Networks, CyberArk, BeyondTrust, and Qualys — and resulted in over 1.5 billion records stolen.
Attackers have also shifted to OAuth‑focused phishing fronts. A recent Salesforce campaign began with device‑code phishing that tricked victims into registering attacker‑controlled apps with full API access. The piece notes a 37× increase in device code phishing attacks this year and more than a dozen criminal PhaaS kits in circulation, underscoring how rapidly these techniques are scaling.
Shadow AI, shadow tenants, extensions, and integrations: the taxonomy of sprawl
The report lays out four distinct flavours of shadow risk that multiply OAuth exposure:
- Shadow apps — employee‑adopted apps used for business purposes without approval, whether under corporate or personal accounts.
- Shadow tenants — personal accounts creating tenant‑level isolation from corporate control even when the app itself might be sanctioned.
- Shadow extensions — browser extensions or AI app extensions that expose browser activity and create additional visibility and attack vectors.
- Shadow integrations — undocumented or unmanaged OAuth connections between apps, which may be the riskiest because they put sensitive data and functionality on the line.
The Vercel event is described explicitly as a shadow integration problem, but the report cautions that all four categories compound enterprise risk as AI tools proliferate.
Controls, limits, and the gaps beyond Google and Microsoft
Google Workspace and Microsoft 365 provide admin controls to audit and restrict OAuth consent; in theory, a toggle could have blocked the Vercel employee from adding new OAuth integrations without admin approval. The report stresses that while locking down consent in primary enterprise clouds is necessary, it is not sufficient.
Across hundreds of SaaS products the challenge is different: you must maintain a comprehensive, up‑to‑date app inventory, hold app admin privileges across those services, and rely on each app to support tenant‑level controls for removing or restricting OAuth grants. Many self‑adopted apps and tenant‑separate integrations lack those centralized controls, leaving SaaS‑to‑SaaS connections less visible and harder to govern.
What this means for security teams, procurement leaders, and end users
- Security teams: Adopt a default‑deny posture for OAuth consent in primary enterprise apps, routinely audit existing OAuth integrations, and expand visibility to SaaS‑to‑SaaS grants rather than focusing only on M365 or Google Workspace.
- Procurement and app owners: Build and maintain a complete inventory of apps and insist on app‑level controls that allow admins to remove or restrict OAuth grants on behalf of users; treat self‑service AI trials as formal procurement events when they touch enterprise accounts.
- End users: Recognize that self‑service trials and browser extensions can create persistent, organization‑wide trust relationships; those connections do not vanish when an individual stops using an app.
Browser‑level detection and the role Push Security says it fills
The report profiles Push Security's browser‑based product as a tool that observes every web login, tracks OAuth integrations, and can block OAuth connection requests as they traverse the browser. Push claims the platform analyzes every web page in every browser session and tab in real time, and that it can detect and block browser‑based threats — AiTM phishing, device code phishing, ClickFix, malicious extensions, session hijacking, and infostealer delivery vectors — while providing a unified view to manage and remove OAuth grants across apps.
The Vercel incident is not an isolated anecdote. It is an operational lesson: a single, employee‑initiated OAuth grant can make an organization dependent on a third party's security posture, and when that third party is breached the path into your systems can already be laid out. The practical steps invoked in the report — default‑deny consent, routine audits, and broader visibility into SaaS‑to‑SaaS connections — are specific actions enterprises can take now to reduce the likelihood of replaying the same chain.
