What the Vercel / Context.ai Incident Means for You

What Happened

On April 19, Vercel disclosed a security incident in which an attacker gained access to certain internal Vercel systems. The entry point was not Vercel itself,  it was a third-party AI tool called Context.ai, specifically its now-deprecated "AI Office Suite" consumer product. A Vercel employee had connected that tool to their Google Workspace account and, during sign-in, granted it the full set of Google Workspace OAuth permissions it requested.

Here's the mechanic that matters: when a user authorizes an OAuth app, Google issues access and refresh tokens scoped to that app's client ID, and the app stores those tokens server-side so it can call Google APIs on the user's behalf. Context.ai stored its users' tokens in its AWS environment. When that AWS environment was compromised, the attacker exfiltrated the stored tokens,  including the one belonging to the Vercel employee, and used it to act as that employee against Google's APIs, pivoting into Vercel's Google Workspace and ultimately accessing non-sensitive environment variables belonging to a subset of Vercel customers.

This pattern behind the attack, a third-party OAuth app with broad permissions becoming the doorway into an enterprise, is one of the most common and under-monitored risks in SaaS today. We want to help you check your own environment.

Why This Matters Beyond Vercel

OAuth-based SaaS integrations are genuinely useful. But the reason this pattern is so dangerous isn't the sophistication of the attack. It's how normalized broad OAuth consent has become. A few specifics worth internalizing:

• An OAuth grant is a persistent key, not a one-time login. Once a user clicks "Allow," the app holds a refresh token that works silently in the background, often until someone explicitly revokes it.
• Broad scopes like Drive, Gmail, and Calendar create enormous attack surfaces. Granting https://www.googleapis.com/auth/drive means the app can read, modify, and delete every file in that user's Drive  including anything shared with them across your organization. For an employee at a tech company, that can include source code, credentials in .env files, architecture documents, customer data, and more.
• The risk compounds when a single employee can grant consent for themselves. If your Google Workspace defaults allow users to authorize any third-party app, one person's bad click becomes the whole organization's incident.
• The attacker doesn't need to compromise you, only a vendor you trusted. That vendor may be small, deprecated, or acquired. The token outlives the relationship. Teams often don't actively track their OAuth grants, what scopes they hold, or when they were last used.

This is why a breach at a small, deprecated AI tool became a breach at Vercel  and why the same pattern is worth checking for in your own environment.

What We Recommend

1. Check For the Specific Indicator of Compromise (IOC)

Vercel has published the OAuth client ID associated with the compromised Context.ai app:

110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com

Google Workspace administrators should check this immediately:

1. Go to Google Admin Console → Security → Access and data control → API controls
2. Under App access control, click Manage Third-Party App Access → View list (for both Configured apps and Accessed apps)
3. Use the ID filter and paste the client ID above
4. If it appears, identify which users authorized it, revoke access, and begin incident response for those accounts, rotate credentials they held, review their activity logs, and check for anomalous Drive, Gmail, and Calendar activity.
5. Map what was exposed, before your rotate credentials. Understand what systems and services did the attacker access. Rotation closes the door. It doesn’t tell you how far someone moved while it was open. 

2. Audit All Third-Party OAuth Apps, Not Just This One

The Context.ai app is the known IOC, but the same pattern applies to every OAuth integration in your tenant. In the Admin Console's Configured apps and Accessed apps lists, export the CSV (the download option at the top of the list includes user counts and the full set of requested scopes, which the on-screen view often hides).

For each app, ask:

• Do we still use it? Is the vendor still in business?
• How many users have granted it access?
• What scopes does it hold? Pay particular attention to the high-risk ones below.
• Is it marked as Trusted, or is it relying on the default "unconfigured" state?

Revoke anything that fails these checks.

3. Know Which Scopes Are "Crown Jewels"

Not all OAuth scopes are equal. These are the ones that give an attacker the most leverage and deserve the highest scrutiny:

If an app holds drive or mail.google.com and it's not on your explicit trusted list, treat that as a finding.

4. Tighten Your Defaults So This Doesn’t Happen To You

This is the single biggest lever. By default, many Google Workspace tenants allow users to install any third-party OAuth app and consent to any scope. Change that:

• Admin Console → Security → Access and data control → API controls → Settings
• For Unconfigured third-party apps, choose Don't allow users to access any third-party apps. This forces users to request admin approval for anything new, which appears in the Apps pending review queue for you to evaluate.

• Review and configure any app you do want to allow, explicitly setting it to Trusted, Limited, or Specific Google data with the minimum scopes required.
• Enable the user message feature so users see a clear explanation when they try to install a blocked app.

This one change would have prevented the Vercel incident's initial authorization step entirely.

A Note on The "Allow All" Pattern

According to Context.ai's own disclosure, the Vercel employee "enabled 'allow all' on all requested Google Workspace permissions" during the consent flow. This is worth pausing on.

Modern OAuth consent screens often present scopes as a list of checkboxes, and it is genuinely easy for a user,  especially one trying to get an AI tool working quickly, to tick every box without carefully reading what "See, edit, create, and delete all of your Google Drive files" actually means. This is not a failure of any one employee; it is a failure of defaults. Removing the ability for users to grant these scopes at all (Step 4 above) is how you take this decision out of the hands of someone who is just trying to get their work done.