“80% of security leaders consider unmanaged OAuth grants a critical or significant risk.”
Drift, UNC6395, and weaponized refresh tokens
The abstract threat described in vendor blogs became a concrete attack in the Drift incident. Drift — a sales engagement platform acquired by Salesloft — maintained OAuth integrations with Salesforce instances across hundreds of customer organizations. Palo Alto Unit 42 tracked a threat actor labeled UNC6395 who obtained valid OAuth refresh tokens, likely through prior phishing campaigns, and used them to access Salesforce environments belonging to more than 700 organizations.
From the attackers’ perspective the tokens were legitimate and the integration was legitimate. Because the actor presented valid tokens rather than logging in interactively, perimeter controls and multifactor authentication were bypassed. Once inside, UNC6395 exported data and searched for credentials such as AWS access keys, Snowflake tokens, and passwords. Cloudflare, PagerDuty, and dozens of others were affected; the full scope was still being assessed in the reporting.
Persistent OAuth tokens: a technical design that becomes an enterprise blind spot
Every AI tool, workflow automation, and productivity app employees connect to Google or Microsoft leaves behind a persistent OAuth token, the reporting says. These tokens commonly have no expiration date, no automatic cleanup, and in most organizations no one watching them. OAuth grants don’t expire when employees leave, and they don’t reset when passwords change.
The coverage stresses that this isn’t merely a misconfiguration but how OAuth is designed to work. That design choice made sense when a small number of IT‑approved apps required calendar access; it struggles when every employee independently wires new AI and automation tools into the corporate workspace. The gap, according to the source, is that most security programs were not built to account for OAuth at scale.
Why point‑in‑time app vetting misses the critical failure mode
Current OAuth security tooling typically evaluates risk only at installation: vendor reputation checks and permission‑scope reviews. Those controls matter, but they miss a key scenario the Drift case illustrates — a legitimate app whose credentials are later stolen and weaponized.
Point‑in‑time vetting cannot detect a token that was valid at installation but subsequently abused. The article emphasizes that behavioral monitoring — what an app actually does after grant — is essential. Examples of the detectable anomalies include sudden spikes in data access, queries for unusual data types, and access at unexpected hours. Without continuous monitoring and visibility into the accounts tied to the grant, defenders remain “half‑blind,” since the potential impact depends on who the user is and what they can access.
Material Security’s OAuth Threat Remediation Agent: three signals and automated response
Material Security positions its OAuth Threat Remediation Agent as a response to the gap between awareness and operational capability. The agent runs continuously across an organization’s Google Workspace environment and evaluates each connected app using three inputs:
- Vendor trust and scope analysis — the baseline checks performed at installation.
- Behavioral monitoring of actual API calls over time — surfacing anomalies against expected behavior.
- Blast radius assessment — calculating exposure based on the access levels and data exposure of the accounts the app is connected to.
Those inputs combine into a risk signal that reflects both probability and potential impact. When the agent identifies a high‑risk grant, it can revoke the token immediately. For lower‑certainty situations involving mission‑critical integrations, the agent surfaces the finding with context — what the app is, what it has been doing, what it can access, and the risk score — so security teams retain control. Organizations configure thresholds for automated remediation versus human review.
What this means for CISOs, security teams, and end users
- CISOs: The reporting notes that CISOs recognize the problem — yet many programs lack the operational tools to act. The statistics cited show the gap: 80% view the risk as critical or significant, but 45% are doing nothing to monitor grants at scale.
- Security teams: Many teams rely on manual processes — spreadsheets, ad hoc reviews, or employee flags. The source calls spreadsheets “not a threat response capability,” characterizing them instead as records of unknown exposure. The recommended shift is toward continuous behavioral monitoring, blast‑radius risk scoring, and graduated automated responses.
- End users and procurement leaders: Telling employees they cannot use AI tools is not presented as a viable posture. Instead, the piece argues for better visibility and operational controls that allow tools to be used while monitoring and limiting the damage if a token is abused.
The Drift case crystallizes the weakness: a trusted integration, legitimate tokens, and no automatic expiration create a back door that perimeter tools and MFA will not close. The remedy described is not blanket restriction of OAuth grants but continuous visibility, contextual risk scoring that accounts for who an app is connected to, and the ability to revoke or escalate with speed. For organizations still tracking OAuth grants in spreadsheets, the question is starkly practical — not whether OAuth is useful, but whether their controls can detect and stop the moment a valid token is turned into an attacker’s passkey.
