Learn
Security
Every week, someone on your team clicks "Sign in with Google" on an app you've never heard of. A note-taker that joins meetings. An AI assistant that reads inboxes. A free PDF tool that wants access to Drive. Each click hands a third-party app a standing key to your company data — and most of those keys never get taken back.
This is the quiet risk inside every Google Workspace tenant: not the apps you approved, but the hundreds you didn't. For teams without a dedicated IT function, it usually goes unmanaged until something breaks. App blocking is how you take that control back.
What "app blocking" actually means in Google Workspace
When an employee connects a third-party app via OAuth, they grant it scopes — permission to read email, manage calendars, access Drive files, see the company directory. The app receives a token and keeps using it in the background, with no further prompts, until the token is explicitly revoked.
App blocking is the practice of deciding which third-party apps are allowed to hold those tokens, and removing the ones that shouldn't. Done properly, it covers two things:
Prevention — stopping a risky app from being connected in the first place.
Revocation — pulling access from an app that's already connected, across everyone who connected it.
Most teams only think about the first one. The second is where the real exposure lives.
Why this is a bigger problem than it looks
Three things make OAuth app sprawl uniquely dangerous for growing companies:
1. Tokens outlive intentions. An employee tries a tool once, forgets it, and moves on. The token stays live. It survives password changes and, in many configurations, even survives the employee leaving — until someone revokes it directly.
2. The blast radius is the data, not the device. A blocked app isn't a blocked laptop. These apps reach straight into Gmail, Drive, and Calendar through the API. A single over-permissioned app, breached on the vendor's side, can expose data across your whole tenant.
3. You can't fix what you can't see. Native Google Workspace admin tools will show you connected apps, but the workflow to audit them, decide, and revoke at scale is manual and slow. Without a clear list and a one-click action, "we'll clean it up later" becomes "we never cleaned it up."
This is the textbook shape of shadow IT: well-meaning employees adopting tools faster than anyone can review them.
The native way — and where it falls short
Google Workspace does give admins control over third-party app access. From the Admin console you can mark individual apps as Trusted, Limited, or Blocked, and you can restrict access to specific OAuth scopes. For a deliberate, planned policy, these controls are genuinely useful.
Where they fall short is the day-to-day reality:
Finding the app you're worried about means digging through API access reports.
Blocking and revoking are separate mental steps — it's easy to block future connections while leaving existing tokens live.
There's no fast, shared workspace for a small team to see "what's connected, what's risky, what did we decide" at a glance.
In other words: the capability exists, but the workflow assumes you have IT staff with time to run it. Most companies under a few hundred people don't.
How app blocking works in ShiftControl
This is the gap we built ShiftControl's App Blocking for. It turns third-party app control into something a founder or ops lead can run in minutes, not an afternoon-long audit.
A single Blocked Apps list. Every app you've blocked lives in one place, under Apps → Blocked Apps, right alongside your installed apps. App name and Client ID, searchable, with the Client ID safely truncated and one-click copyable when you need it.
Block by picker or by Client ID. Add an app two ways: pick it straight from your organization's real OAuth activity — so you're blocking apps your team actually connected, not guessing — or paste a specific Client ID and name it yourself when you already know the target.
Block straight from where you spot the risk. When you're reviewing permissions or your OAuth dashboard and something looks wrong, a Block action opens a pre-filled modal on the spot. See it, block it, done — no copying IDs between screens.
Revoke across every user, automatically. This is the part that matters most. When you block an app, ShiftControl doesn't just prevent future connections — it revokes the existing OAuth grant for all current users of that app. Before it does, you get a clear confirmation that all existing users will be revoked, so the consequence is never a surprise.
Pause when you need to. Blocking isn't always permanent. Need to temporarily restore an app — to test something, or because a team genuinely needs it back for a day? Pause and unpause a block without deleting and rebuilding it.
The result is the thing native tooling doesn't give you: see a risky app, block it, and know it's gone for everyone — in one move.
A practical checklist for controlling third-party apps
Whether you use ShiftControl or not, the discipline is the same. Work through this:
Inventory first. Pull the list of every third-party app currently connected to your Workspace. You'll almost certainly be surprised by the count.
Sort by scope, not by name. An unknown app with Drive and Gmail read access is a bigger problem than a well-known app with calendar-only access. Prioritize by what the app can reach.
Block and revoke together. Blocking future access without revoking existing tokens leaves the door open. Treat them as one action.
Make it routine. New apps get connected every week. A five-minute review on a regular cadence beats an annual panic.
Keep a record of decisions. A shared, visible blocked-apps list means the next person doesn't re-litigate what you already decided.
The takeaway
Third-party app risk isn't a one-time cleanup — it's a steady leak that grows with every new tool your team tries. The companies that stay ahead of it aren't the ones with the biggest security budgets. They're the ones who made blocking and revoking a risky app fast enough to actually do.
That's the whole idea behind ShiftControl: give teams without a dedicated IT department the controls that used to require one.
