Every time someone at your company clicks “Sign in with Google” to use a new app, that app is handed a standing key to part of your Google Workspace. It can keep using that key for years, long after anyone remembers granting it. Earlier this year, that exact kind of access is how Vercel got breached, and it’s worth using their incident as a prompt to check your own Workspace.
What actually happened to Vercel
Vercel’s employees used an AI tool called Context.ai. To connect it to their Google accounts, someone clicked “Sign in with Google” and approved the permissions it asked for. That’s a technology called OAuth: instead of typing a password into Context.ai, you let Google vouch for you and hand Context.ai a token, a kind of digital permission slip, for whatever access was requested.
Context.ai itself got compromised. Because its token was still valid, the attacker used it to get into a Vercel employee’s Google account, and from there into Vercel’s production systems. Vercel’s security bulletin has the full timeline. The important detail for you: the attacker didn’t need a password, a phishing email, or an MFA bypass. The front door was already open because of a permission someone had approved months earlier for an unrelated tool.
Vercel also published the specific ID of the malicious app, which security people call an indicator of compromise, or IOC:
110671459871-30f1spbu0hptbs60cb4vsmv79i7bbvqj.apps.googleusercontent.com
Check your own Workspace for it
If someone in your organization has Google Workspace admin access, this takes about five minutes:
- Sign in to admin.google.com.
- Go to Security → Access and Data Control → API Controls → Manage Third-Party App Access.
- Search the list of apps for that ID above.
If it’s there, don’t just remove the app. Treat the Google account it was connected to as possibly compromised, and start your incident response process the same way you would for a stolen password: change credentials, check for unusual sign-ins, and loop in whoever handles IT security for you.
If it’s not there, good. But the next few sections matter more than this one check, because the setting that let this happen in the first place is probably still on.
Why this is so common: the default setting allows it
Google Workspace ships with a setting that controls what happens when an employee tries to connect a new, unreviewed app to their Google account. Most organizations never touch it, which means it’s set to the most permissive option: anyone can connect anything.
That’s how an organization ends up with hundreds of these connections, most of which nobody tracked and some of which can read every email in an inbox. Someone tries a scheduling tool, a meeting notetaker, or a CRM add-on for a week and moves on, but the permission they granted doesn’t expire. It just sits there, working, until something like the Vercel incident forces someone to go look.
Keeping on the theme of unauthorized apps: it’s not a coincidence that the app in this story was an AI tool. I covered the related problem of shadow AI, employees doing company work through personal ChatGPT or Claude accounts nobody signed off on, in a recent LinkedIn post and TikTok video. Different door into the building, same root cause: nobody decided on purpose which tools get trusted with company data.
A better default: allow sign-in, block everything broader
The setting worth moving to is one that restricts unreviewed apps to basic sign-in only, usually labeled something like Sign in with Google. Employees can still use that button to log into new SaaS tools, so adoption doesn’t grind to a halt, and because the login runs through Google, whatever multi-factor authentication you’ve set up on Google accounts protects those tools too.
This is not the same as true single sign-on (SSO), where IT can centrally create accounts, cut off access the moment someone leaves, and control session timeouts. It’s a lighter-weight version of that idea. But for the long tail of tools that will never get a formal SSO setup, it’s a real improvement over a separate username and password per app, each with whatever security the vendor happened to build in.
Under this setting, anything asking for more than basic sign-in, like reading Gmail, Drive, or Calendar, gets blocked until someone reviews and approves it. That has a side benefit: the list of apps requesting that broader access becomes a running inventory of what tools your team is actually trying to use, which is useful information on its own.
Why not just block everything?
Google also offers an all-or-nothing option that blocks every unreviewed third-party app outright. It sounds like the safest choice, but it tends to backfire quietly: employees don’t stop needing the tool, they just set up a separate password for it instead, one that doesn’t benefit from your Google MFA at all. You can end up with weaker security than the middle-ground setting above.
There’s no single right answer for every organization. But if nobody can tell you which of these settings you’re on, or why, the Vercel incident is a good reason to decide on purpose instead of by default.
What to put in place, in plain terms
None of this requires buying anything new:
- Pick a setting on purpose. Decide which of the options above fits your organization, write it down, and know who owns the decision.
- Have a real approval path for bigger requests. When someone wants to connect an app that asks for Gmail or Drive access, know who looks at that request and how long it takes. If the honest answer is “a couple of weeks,” people will find a way around it.
- Check the list periodically. Once a quarter, have someone glance through the connected apps list for anything nobody recognizes or nobody uses anymore.
- Build it into offboarding and incident response. When someone leaves the company, their app connections don’t automatically disappear along with their account. Make revoking them a checklist item, and make sure whoever handles incident response knows to check this list, the same way they’d check for an IOC like Vercel’s.
If your organization runs on Microsoft 365 instead of Google, the same idea applies there under app consent policies, and the out-of-the-box default is just as permissive.
Where to start
Everything described here is a setting already sitting inside the Google Admin console. There’s nothing new to buy, and working through it deliberately is most of what a SaaS security and access assessment actually involves: the controls are usually already there, just unconfigured, in the same way phishing-resistant MFA and conditional access often are. And because this particular breach started at a vendor rather than at Vercel itself, it’s worth pointing the same kind of review outward: a vendor risk assessment looks at the tools asking for access in the first place, not just the Workspace granting it.
An unreviewed OAuth grant isn’t one of the five gates I covered in the Five Gates of SaaS Security series, but it’s the same family of problem: a standing permission nobody is actively managing. That series covers the identity side in more depth, including why SSO alone doesn’t secure a SaaS app, why standing access turns one compromised account into the whole tenant, and where network restrictions and audit logging quietly depend on your license tier.
The next incident like this will have a different company name and a different app ID. Whether it becomes a problem for you depends on a decision you can make today, before you’ve ever heard of it.