The Back Door Attackers Know About — and Most Security Teams Still Haven’t Closed

🇧🇷 PT 🇺🇸 EN

2026-05-05 00:00

← Back

Executive Summary

Every AI tool, workflow automation, and productivity app your employees connected to Google or Microsoft this year left something behind: a persistent OAuth token with no expiration date, no automatic cleanup, and in most organizations, no one watching it. Your perimeter controls don't see it. Your MFA doesn't stop it. And when an attacker gets hold of one, they don't need a password. OAuth grants don't expire when employees leave. They don't reset when passwords change. And in most organizations, nobody is watching them. The model made sense when a handful of IT-approved apps needed calendar access.

It doesn't hold up when every employee is independently wiring AI tools, workflow automations, and productivity apps directly into their Google or Microsoft environment — each one receiving a persistent, scoped token with no automatic expiration and no centralized visibility. That's not a misconfiguration. It's how OAuth is designed to work. The gap is that most security programs weren't built to account for it at scale. New research from Material Securityquantifies the gap between awareness and action. 80% of security leaders consider unmanaged OAuth grants a critical or significant risk. Most have said as much for years. But awareness doesn't translate directly into capability.

A substantial portion of organizations (45%) are doing nothing to monitor OAuth grants at scale. Many of the rest (33%) are running manual processes — tracking grants in spreadsheets, reviewing...

Details

Every AI tool, workflow automation, and productivity app your employees connected to Google or Microsoft this year left something behind: a persistent OAuth token with no expiration date, no automatic cleanup, and in most organizations, no one watching it. Your perimeter controls don't see it. Your MFA doesn't stop it. And when an attacker gets hold of one, they don't need a password. OAuth grants don't expire when employees leave. They don't reset when passwords change. And in most organizations, nobody is watching them. The model made sense when a handful of IT-approved apps needed calendar access.

It doesn't hold up when every employee is independently wiring AI tools, workflow automations, and productivity apps directly into their Google or Microsoft environment — each one receiving a persistent, scoped token with no automatic expiration and no centralized visibility. That's not a misconfiguration. It's how OAuth is designed to work. The gap is that most security programs weren't built to account for it at scale. New research from Material Securityquantifies the gap between awareness and action. 80% of security leaders consider unmanaged OAuth grants a critical or significant risk. Most have said as much for years. But awareness doesn't translate directly into capability.

A substantial portion of organizations (45%) are doing nothing to monitor OAuth grants at scale. Many of the rest (33%) are running manual processes — tracking grants in spreadsheets, reviewing permissions on an ad hoc basis, relying on employees to flag unusual app behavior. Spreadsheets are not a threat response capability. They're a record of how much exposure an organization doesn't know it has. The argument for OAuth visibility often gets framed as employees piping sensitive information into third-party tools without IT visibility. That's a real problem, but it's the smaller one. The more pressing issue is that OAuth grants are an active attack vector. TheDrift incidentmakes that concrete.

Drift, a sales engagement platform acquired by Salesloft, maintained OAuth integrations with Salesforce instances across hundreds of customer organizations. A threat actor tracked by Palo Alto Unit 42 as UNC6395 obtained valid OAuth refresh tokens — likely through prior phishing campaigns — and used them to access Salesforce environments belonging to more than 700 organizations. The attack's structure is a warning: the tokens were legitimate, the integration was legitimate. From the perspective of any perimeter control, nothing was wrong. MFA was bypassed entirely because the attacker wasn't logging in — they were presenting a token that Drift had already been granted permission to use. Once inside, UNC6395 systematically exported data and combed through it for credentials: AWS access keys, Snowflake tokens, passwords. Cloudflare, PagerDuty, and dozens of others were affected. The full scope is still being assessed.

The Drift incident wasn't an attack from a suspicious, unknown app. It was an attackthrougha trusted one. The lesson isn't that organizations should restrict OAuth integrations — it's that trusting an app at the time of installation doesn't mean it stays trustworthy, and that OAuth grants need active, continuous monitoring rather than passive acceptance. The current generation of OAuth security tools addresses OAuth risk at the point of installation. They check whether a requested permission scope is excessive. They may flag apps from vendors with poor reputations. That's useful — but it's not sufficient. For the Drift scenario, a legitimate app whose credentials were later stolen and weaponized — it catches nothing.

To begin with, vendor trust levels and app scopes are important, but it only tells part of the story. Monitoring the actual behavior of the app–the API calls it makes, the actions it takes–is critical to understanding what the app isactuallydoing, not just what it could do. And even then, without deep visibility into the account(s) the app is linked to, you’re still operating half-blind. A risky app tied to an intern’s account is one thing–the same app being used by a VIP with access to countless sensitive emails, files, and systems is something else entirely. The Drift attack didn't involve a suspicious app requesting unusual permissions at installation. It involved a legitimate app whose credentials were later compromised and weaponized. A tool that only evaluates the grant at the point of creation would have seen nothing wrong. The risk materialized later — when the token was stolen and used by a different actor entirely.

Material Security'sOAuth Threat Remediation Agentis built around this more complete model of OAuth risk. The agent runs continuously across an organization's Google Workspace environment, monitoring every OAuth-connected application — not just new ones at the point of grant. For each connected app, the agent evaluates three factors together: These inputs combine into a risk signal that reflects both the probability of a problem and its potential impact. When the agent identifies a high-risk grant, it can act immediately — revoking the token before harm is done. For lower-certainty situations involving mission-critical applications, it surfaces the finding to the security team with full context: what the app is, what it's been doing, what it has access to, and what the risk score is. Organizations configure their own thresholds: how much risk triggers automated remediation, and where the line is for requiring human sign-off. The agent is designed to keep security teams in the loop for the decisions that matter, and out of the loop for the ones that don't. OAuth grants are the default way third-party apps and AI tools connect to the enterprise workspace.

That's not changing. The number of grants in most environments will continue to grow as AI adoption accelerates. Telling employees they can't use AI tools isn't a viable security posture for most organizations — and it wouldn't address the threat posed by apps that are legitimate at installation and malicious later. The answer isn't fewer OAuth grants. It's better visibility into the ones that exist, continuous monitoring of their behavior, and the operational capability to respond fast enough to matter and smart enough to avoid disrupting the integrations that keep the business running. For security teams who want visibility into what's actually connected to their environment — and the ability to respond when something changes, reach out toMaterial Securityfor a demo of theOAuth Threat Remediation Agent. Learn how to stop patient zero attacks before they bypass detection and compromise your systems at entry points. Learn how to validate real attack paths and reduce exploitable risk with continuous agentic security validation.

Get the latest news, expert insights, exclusive resources, and strategies from industry leaders, all for free.