The Google Workspace apps you forgot about are still reading your email
Third-party integrations left connected to Workspace tenants keep their access for years, and attackers are quietly walking through the door they left open.
Key points
- Third-party apps connected to Google Workspace often keep read and send access to email, files and calendars long after staff stop using them.
- Overly permissive OAuth grants, the digital permission slips users click through at sign-in, are a growing cause of cloud breaches at fast-growing companies.
- Admins can review and revoke these connections centrally, but most tenants have never audited them.
- A BleepingComputer webinar this month walks security teams through cutting that exposure.
Most companies know who their employees are. Far fewer know which outside apps those employees connected to the company's Google Workspace two years ago and never touched again.
That blind spot is the subject of a new webinar covered by BleepingComputer, aimed at security teams at fast-growing firms where the app sprawl is worst.
The setup is familiar. A salesperson signs up for a new meeting scheduler. It asks to read their calendar and send email on their behalf. They click allow. Six months later they switch to a different tool. The old one still has the keys.
What is actually being left behind?
OAuth tokens. That is the technical name for the permission slip a user hands out when they click "Allow" on a Google sign-in screen. The token lets an outside app read email, move files in Google Drive, or send messages as the user, without asking again.
Tokens do not expire on their own in most cases. They sit in the account until someone revokes them. If the outside app is later breached, sold, or simply gets sloppy with its own security, whoever ends up with that token inherits the access.
Why is this a breach risk, not just a housekeeping problem?
Because the access is real, and it looks legitimate.
An attacker using a stolen OAuth token does not need the user's password. Multi-factor authentication, the extra code from a phone or app, does not trigger, because the user already approved the connection long ago. Logs show the third-party app doing what it was allowed to do. Detection tools built to catch stolen passwords often miss it entirely.
Several of the larger cloud incidents in the past two years have started this way: not with a hacked employee, but with a hacked integration the employee had forgotten about.
Which apps tend to be the problem?
The usual suspects are productivity add-ons. Meeting schedulers. Note-takers that join calls. AI assistants that summarise inboxes. Marketing tools that pull contact lists. CRM connectors. Anything that asked for wide read access to email or Drive on install.
| Risk factor | Why it matters |
|---|---|
| Broad scopes | App can read all mail, not just one folder |
| Long-lived tokens | Access persists after the user stops using the app |
| Vendor breach | Attacker inherits every customer's token |
| No central review | Admins cannot see what users approved |
What should admins actually do?
Google Workspace lets administrators see every third-party app connected to the tenant, and revoke any of them, from the admin console's API controls page. Most tenants have never opened that screen.
A sensible first pass:
- Pull the list of connected apps and sort by number of users and by scope.
- Revoke anything nobody has used in 90 days.
- Block new apps from requesting sensitive scopes without admin approval.
- Set a quarterly review so the list does not silently grow again.
For ordinary staff there is a self-service version. Sign in to your Google account, open Security, then Third-party apps with account access, and remove anything you do not recognise or no longer use. It takes about five minutes and closes doors you probably forgot were open.
The webinar itself is aimed at security leads, but the underlying point is not technical. Access you granted once, and forgot, is still access.
