Summary: We analyzed 22,000+ OAuth apps in the wild and found AI adoption bypassing security and IT, thousands of zombie tokens still active, and lots of restricted scopes.
TL;DR: Material analyzed 22,332 OAuth-connected applications across 21 enterprise Google Workspace environments. Nearly half haven't been used in 90 days. Over a thousand still hold live tokens for users who no longer exist. 91% of AI and automation apps appeared in the last 16 months, most without any formal approval. The report is out today — here's a summary of what the data shows. Check out the full report here.
When someone connects a third-party app to their Google Workspace account, it’s an intentionally low-friction process. They see a dialog box, they click Allow, and the app gets access. Gmail, Drive, Calendar — whatever it asked for. The authorization is immediate and, in most cases, permanent. The app holds a token that refreshes indefinitely.
What doesn't happen: any notification to IT, any review of the permissions being granted, any process for what to do when the employee eventually leaves or stops using the tool.
That's the gap. It isn't a configuration failure or a vendor problem. It is how OAuth was designed. The mechanism works exactly as intended. The governance just never caught up.
Material looked into nearly a hundred thousand OAuth connections, spanning 22,332 unique applications across an anonymized subset of our customer Google Workspace environments. The findings document what that governance gap looks like at scale — and at this point it's significant.
AI adoption is outrunning oversight
The report analyzed 356 unique public applications classified in the AI and Automation category. Of those, 325 were first observed in the environments analyzed on or after January 1, 2024. That means 91% of the AI application population appeared within a 16-month window.
This is not a coordinated IT rollout. There is no project plan behind a 91% surge. It's individual employees connecting tools on their own: developers linking coding assistants, sales teams connecting AI drafting tools, HR teams authorizing scheduling agents. Each authorization is made independently, often without IT awareness. The average AI-connected app in the dataset has been running for 9 months. Four in ten have been connected for over a year, spanning multiple budget cycles, team changes, and security reviews, with no formal record of approval.
For AI tools that read and write data passively, the risk is real but bounded. For AI agents, it's different. Agents are built to act autonomously within whatever permissions they hold. An AI assistant that can access your mailbox can see your email. An agent with the same scope can read it, respond to it, and forward it, with no human approving each step. The permission model is identical. The behavior is not.
Of the 181 AI applications in the dataset holding sensitive or restricted scopes, most are doing exactly what they were connected to do. The problem is not the functionality. It is the absence of any record that the access was deliberately approved, and no process for revisiting it as those tools evolve.
Nearly half of all apps are dormant. Their access is not.
Of the 22,332 applications identified, 47.2% have not recorded active usage in the past 90 days. A quarter of all applications, 5,752 in total, have not been used in 180 days or more. In every one of these cases, the OAuth authorization is still intact. The application retains whatever permissions it was originally granted.
OAuth tokens do not expire when an employee stops using an app. They expire only when the user manually revokes access, when an administrator removes the authorization, or when the account behind the token goes inactive. In practice, revocation requires a deliberate action that most organizations never take.
Consider what this means in practice. Clockwise was a well-regarded AI calendar assistant acquired by Salesforce and subsequently wound down. The service went dark. Active development stopped. At some point Clockwise ceased to exist as an independent product.
The OAuth grants didn't get the memo. Across several environments in this assessment, Clockwise still appeared in connected app inventories with active grants, including read and write access to calendar and email. The vendor is gone. The security team maintaining it is gone. The access remains.
A decommissioned app doesn't have an incident response process. It doesn't have someone patching vulnerabilities or responding to abuse reports. Regular access reviews surface this. Without them, old grants accumulate indefinitely.
Over a thousand apps hold live tokens for users who are no longer there
A sharper version of the dormancy problem: 1,064 unique applications in the dataset show zero current active users alongside positive historical usage. These are applications connected by employees who have since left, changed roles, or simply stopped using the tool. In each case, the application continues to hold a valid credential issued by that user's account.
Of those 1,064 applications, 463 hold permissions classified as sensitive or restricted, including full Gmail access, full Drive access, and in some cases broader Google Workspace administrative permissions. These are not low-stakes credentials. They are, in several instances, the most restricted permissions available in the Google Workspace framework, now attached to accounts that no active employee is monitoring.
An OAuth token issued by a former employee does not become invalid when that employee leaves. It remains valid until it is explicitly revoked. Standard account suspension does not revoke third-party OAuth grants. That step must be done separately, and most organizations skip it.
"One of the less obvious risks with OAuth is what happens after the fact," said Chaim Sanders, CISO at Lyft. "When you revoke a user's access or offboard a vendor, you're thinking about accounts and credentials. But OAuth grants operate on a different lifecycle. The approved app holds a token that can be refreshed indefinitely, which means processes can keep running long after the user has been suspended or the vendor relationship has ended. These are zombie connections — technically authorized, practically abandoned, and invisible to most of the controls we rely on."
One in four apps holds restricted Google scopes
Across the 22,332 applications in the dataset, 5,461 hold at least one active restricted scope type. That's 24.5% of all applications analyzed, and the threshold being applied here isn't a third-party risk model or an opinion. It is Google's own classification of permissions that carry sufficient sensitivity to require enhanced review before an application can request them in production.
Gmail and Drive are the most common restricted scopes, and they frequently appear together. An application holding both has the ability to read all of an employee's email, send messages on their behalf, and access every file in their Google Drive, including files shared from other parts of the organization. Among the public, externally verifiable applications in the dataset, 53.4% hold sensitive or restricted scopes.
The finding does not say that 5,461 applications are malicious. Many are legitimate, widely-used business tools that require these permissions to function. What it says is that one in four applications holds permissions that Google itself designates as requiring special handling, and in most cases that special handling was never applied.
There is also a more direct threat in this category. During this research, an application named "gamma.com.ai" appeared across multiple client environments. Gamma is a widely-used AI presentation tool. The name was close enough that users connected it without a second look. But it wasn't Gamma — it was a separate app registered by a Chinese developer, packaged to resemble the legitimate service (gamma.app), and requesting OAuth access to Google Workspace accounts. No phishing email required. No MFA bypass. Just a name that looked familiar, a click on Allow, and a live token to email and Drive.
This is OAuth impersonation. The attack surface is entirely human, and it's available to anyone willing to register a plausible-looking app name.
Where to start
The findings in this report describe authorized access, not compromise. None of these applications is necessarily malicious. The risk is the gap between what organizations have authorized and what they can actively monitor — a gap that grows every time an employee connects a new tool and never revisits it.
Three actions close most of it:
- Connect OAuth revocation to employee offboarding. Suspending an account does not revoke third-party grants. Adding an explicit revocation step to the offboarding workflow closes the zombie token problem directly. This is the highest-return governance action available with no additional tooling required.
- Build a lightweight approval process for AI tool connections. Employees are going to connect AI tools. A registration step that captures a business owner, a stated purpose, and an acknowledgment of the permissions being granted converts unmanaged individual connections into documented, reviewable assets. It doesn't stop adoption. It makes adoption auditable.
- Set a dormancy threshold and act on it. Ninety days is a reasonable starting point. For each application that crosses it, answer one question: does the business still need this connection? If yes, document it and assign an owner. If no, revoke it.
For organizations that want to move faster than a manual process allows, Material's OAuth Remediation Agent provides continuously-updated OAuth inventory with real-time detection and response for suspicious, dormant, and malicious grants.
