Thousands of OAuth-connected apps in a Google Workspace dataset retained access long after use stopped, exposing a growing identity blind spot as employees connect AI tools on their own.
An analysis of 22,332 OAuth-connected applications across 21 enterprise environments found that nearly half had recorded no active use in at least 90 days, according to a Material Security report published Wednesday. Nearly one in four held restricted Google scopes and granted access to high-value Workspace data.
[See Related: The OAuth Access was Approved. But the AI Agent Chaos was Not]
Forgotten Google Workspace OAuth permissions can let old apps become springboards for hackers to access email, files and calendars. These are the same OAuth-abuse patterns seen in the Salesloft Drift, Midnight Blizzard and Klue/LastPass data-theft campaigns.
Material Security says its report shows that rapid AI adoption has turned Google Workspace OAuth token growth into a persistent, poorly governed enterprise access layer.
“These are zombie connections — technically authorized, practically abandoned, and invisible to most of the controls we rely on,” said Chaim Sanders, CISO of Lyft, quoted in the report titled OAuth & Google Workspace Risk Report.
OAuth sprawl is not a niche problem inside Google Workspace. The platform reaches more than 3 billion users and over 11 million paying customers, according to Google.
To be clear, the report’s warning is not that AI apps are inherently malicious. It is that AI adoption is moving faster than OAuth governance.
AI accelerates, exacerbates and complicates
Material does not blame OAuth sprawl on AI alone. It says AI has accelerated it.
In the Google Workspace environments Material studied, 91% of public AI and automation apps appeared within a 16-month window.
[See Related: The App You Forgot About Is Still Reading Your Email]
OAuth tokens are digital permission slips. They let a third-party app access parts of a user’s account without knowing the user’s password. In Google Workspace, that might mean permission to read Gmail, manage Calendar, or access Drive files.
The risk is that these tokens can keep working after the user stops using the app. Unless the user or an administrator revokes the grant, the app may still hold access.
AI raises the stakes because these are no longer just passive apps with access; they are often agents and automations that can read, write, send, schedule and modify data inside the permissions they were granted.
“A passive tool 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. An OAuth grant to an agent is not access to data. It is operational authority,” wrote Material Security.
In Google’s defense
The report does not include a response from Google. Google’s own documentation, however, points to Workspace controls that allow administrators to review third-party and internal apps, see which users have accessed them, inspect requested OAuth scopes and set app access as trusted, limited, restricted to specific Google data, or blocked.
Google has also tightened those controls. In December 2024, the company said Workspace admins could limit third-party apps to selected OAuth scopes, including Gmail and Drive scopes, to prevent apps from gaining additional access without admin consent.
Material’s report does not argue that Google lacks controls. It argues that many organizations have not turned OAuth access into a governed lifecycle: app approval, ownership, dormancy review and revocation.
As with similar platforms, AI app adoption has moved fast inside Google Workspace. Material found 356 public AI and automation apps in the environments it studied, and 325 appeared within a 16-month window.
Many were not low-risk experiments. More than half had sensitive or restricted Google permissions, and 42% had been connected for more than a year.
“The risk is the accumulation of perfectly reasonable authorizations that have fallen by the wayside,” Abhishek Agrawal, CEO of Material Security, said in a company statement.
Gmail and Drive are the big-ticket scopes
Material said 5,461 apps, or 24.5% of the dataset, held at least one active restricted Google scope. Gmail and Drive were the most common, often together.
A broadly permissioned app may be able to read email, send messages, access attachments and reach files shared across the organization.
Google classifies some Workspace API permissions as restricted when they provide broad access to user data, including Gmail and Drive content or metadata. Material said many of those apps are legitimate business tools. The problem is that they were often approved once by an employee and never governed as lasting enterprise access.
Frank Wang, a security engineer at Surge AI and author of Frankly Speaking, said in the report that OAuth has become the “path of least resistance” for app login, which is why it is so commonly abused. Security teams, he said, are often “choosing between friction and blind spots.”
Internal apps may be the bigger unknown
Material also flagged a second blind spot, internal apps.
The report said 17,262 internal applications were excluded from parts of its comparative analysis because they lacked the verifiable external identity used for benchmarking. That bucket includes custom scripts, internal automation, service accounts and legacy pipelines.
That does not mean they are safe. Internal apps can hold the same Gmail, Drive and admin scopes as third-party tools. They can also become dormant, orphaned or poorly documented. For CISOs, the larger lesson is that OAuth risk is not only a vendor problem. It is an inventory, ownership and lifecycle problem.
The cleanup starts with offboarding
Material’s advice is to revoke OAuth grants during offboarding, put AI app approvals on a lightweight review path, and set a dormancy limit.
Ninety days is a reasonable starting point. If an app has gone quiet, confirm whether it still has an owner and business purpose. If not, revoke it.
Google Workspace admins can also use app access controls to review third-party app requests, limit approved apps to specific data, or block unapproved apps.
