All the AI tools, workflow automation, and productivity apps that employees have connected to Google and Microsoft this year have left something behind. It’s a persistent OAuth token with no expiration date, no automatic cleanup, and, in most organizations, no one to monitor it. Boundary controls don’t know about it. MFA doesn’t stop that. And if an attacker gets your password, they don’t need it.
OAuth grants do not expire when an employee leaves the company. It will not be reset even if the password is changed. And in most organizations, no one is monitoring them.
This model made sense when a small number of IT-approved apps required access to the calendar. This doesn’t work if each employee individually connects AI tools, workflow automation, and productivity apps directly into the Google or Microsoft environment. Each employee receives a persistent, scoped token with no automatic expiration or central visibility.
It’s not a configuration error. OAuth is designed that way. The gap is that most security programs are not built to handle problems at scale.
CISOs know it’s a problem. Most are not resolved.
New research in Materials Security quantifies the gap between awareness and action. 80% of security leaders believe unmanaged OAuth grants are a significant or significant risk. Most people have been saying the same thing for years.
However, consciousness is not directly linked to ability. A significant portion of organizations (45%) are not doing anything to monitor OAuth permissions at scale. Many of the remainder (33%) are performing manual processes. They track permissions in spreadsheets, check permissions on an ad hoc basis, and rely on employees to report unusual app behavior.
Spreadsheets are not a threat response. These are records of the amount of risk your organization is unaware of.
it’s not a theoretical risk
Discussions about OAuth visibility are often framed as employees piping sensitive information to third-party tools without IT visibility. It’s a real problem, but it’s a much smaller problem. A more pressing issue is that OAuth permissions are an active attack vector. The drift incident embodies this.
Drift, a sales engagement platform acquired by Salesloft, maintained OAuth integration with Salesforce instances across hundreds of customer organizations. The attacker, tracked by Palo Alto Unit 42 as UNC6395, obtained a valid OAuth refresh token, likely through a previous phishing campaign, and used it to access Salesforce environments belonging to more than 700 organizations.
The structure of the attack is a warning. The token was legitimate and so was the integration. From a boundary control perspective, there was nothing wrong with it. Since the attacker was not logged in, MFA was completely bypassed. The attacker was presenting a token that Drift was already authorized to use. Once inside, UNC6395 systematically exported data and examined credentials such as AWS access keys, Snowflake tokens, and passwords.
Cloudflare, PagerDuty, and dozens of others were affected. The full range is still under evaluation.
The Drift incident was not an attack by a suspicious and unknown app. It was an attack by someone you trusted. The lesson here is not that organizations should limit OAuth integration. Trusting an app upon installation does not guarantee that the app will remain trusted, and OAuth permissions require active, ongoing monitoring rather than passive acceptance.
What kind of monitoring is actually necessary?
Current generation OAuth security tools address OAuth risks at the point of installation. Checks whether the scope of the requested privilege is excessive. We may flag apps from vendors with bad reputations. It’s useful, but it’s not enough. In the Drift scenario, legitimate app credentials are later stolen and weaponized, but nothing is caught.
First, vendor trust level and app scope are important, but they’re only part of the picture. Monitoring the actual behavior of your app (the API calls it makes and the actions it takes) is important to understand not just what your app can do, but what it actually does. Still, if an app doesn’t have detailed visibility into the accounts it’s linked to, you’re still operating half-blind. It’s one thing to have a dangerous app tied to an intern’s account, but it’s quite another to have the same app used by a VIP with access to countless sensitive emails, files, and systems.
The Drift attack did not involve any suspicious apps that requested unusual permissions during installation. This involved a legitimate app whose credentials were later compromised and weaponized. There’s nothing wrong with a tool that just evaluates grants at the time of creation. This risk was later exposed when the token was stolen and used by an entirely different attacker.
Effective OAuth security requires:
Continuous behavioral monitoring rather than point-in-time reviews. What does an app actually do after it’s granted access? Monitoring the API calls that an OAuth-connected app makes over time will reveal anomalies that static permission reviews can’t detect, such as sudden spikes in data access, queries with unusual data types, or access at unexpected times. Blast range evaluation. An OAuth grant connected to an account with read access to thousands of sensitive documents and years of email history is critically different from the same grant to a newly provisioned account with limited exposure. The reach of a user’s account determines the potential impact of a compromised or malicious OAuth connection. Risk scoring should reflect that. A tiered response tailored to your organization’s risk tolerance. Clearly malicious apps (unknown vendors, broad permissions, unusual API behavior from day one) should not be present in the environment while tickets are being processed through the queue. It should be canceled immediately. Minor anomalies in mission-critical integrations from major vendors require human review before any action is taken. The response layer needs to be intelligent enough to tell the difference.
Material OAuth Threat Remediation Agent
Materials Security’s OAuth Threat Remediation Agent is built around this more complete model of OAuth risk. This agent runs continuously across your organization’s Google Workspace environment and monitors all OAuth-connected applications, not just new applications as they are granted.
For each connected app, the agent evaluates three factors together:
Vendor reliability and scope analysis — a standard baseline where most tools would break Behavioral monitoring of actual API calls made by the app (over time, revealing anomalies to expected behavior) Assessing the scope of explosion based on the access level and data exposure of the accounts to which the app is connected
These inputs are combined into a risk signal that reflects both the probability of the problem and its potential impact. When agents identify high-risk permissions, they act immediately and revoke tokens before any harm is done. In low-certainty situations involving mission-critical applications, findings are presented to security teams with the full context of what the app is doing, what it’s doing, its access rights, and its risk score.
Organizations set their own thresholds. That is, at what level of risk will automatic remediation be triggered? Where is the line at which human sign-off is required? The agent is designed to keep security teams informed about important decisions and blind to less important decisions.
close the back door
OAuth grants are the default way for third-party apps and AI tools to connect to enterprise workspaces. That hasn’t changed. As AI adoption accelerates, the number of grants in most settings will continue to grow. Telling employees they can’t use AI tools is not a viable security posture for most organizations. Additionally, even if an app is legitimate at the time of installation, it does not protect against threats posed by malicious apps later on.
The answer is not fewer OAuth permissions. Increased visibility into what exists and the ability to operate smart enough to continuously monitor its behavior, respond to critical issues quickly enough, and avoid disruptions to integration to keep your business running.
If you’re a security team that wants visibility into what’s actually connected to your environment and the ability to react when something changes, contact Material Security to get a demo of the OAuth Threat Remediation Agent.
Source link
