Salesloft OAuth compromise exposes NHI governance debt in SaaS

At a glance

What this is: This analysis says the Salesloft Drift compromise was an OAuth token abuse case, not a Salesforce or Google Workspace platform flaw, and that stolen app credentials let the attacker move across SaaS environments.

Why it matters: It matters because IAM teams need to govern connected apps, service accounts, and token lifecycles as first-class identities, or one stolen grant can become repeatable SaaS access.

Context

OAuth tokens let applications authenticate to other services without a user MFA prompt each time. When those tokens are stolen, the application identity itself becomes the access path, which means user-centric controls can be bypassed even when the target platforms are behaving as designed.

This campaign exposed a governance gap in SaaS environments: connected apps often persist longer than the people who approve them, with scopes, owners, and rotation rules drifting out of sync. For NHI programmes, that creates an access path that looks legitimate to the receiving platform but is weakly governed across the lifecycle.

The article treats Salesloft, Salesforce, Google Workspace, and the Drift integrations as one chained trust problem rather than separate incidents. That is the right lens, because token reuse, app-to-app delegation, and uneven revocation make the blast radius a governance issue, not a single-product failure.

Key questions

Q: What breaks when OAuth tokens are compromised in connected SaaS environments?

A: When OAuth tokens are compromised, attackers can inherit delegated access without defeating passwords or MFA. In connected SaaS environments, that access can spread into multiple applications, cached data sets, and embedded records. The failure is not only token theft, but the assumption that one app boundary contains the blast radius. That assumption rarely holds once integrations are chained.

Q: Why do compromised SaaS integration tokens create such a large downstream risk for identity and data access?

A: Compromised integration tokens are dangerous because they inherit trust from the connected application and can bypass normal user interaction. If an attacker obtains OAuth or refresh tokens, they may query data, access email, and harvest additional credentials without triggering obvious login failures. The risk compounds when the integration is broadly scoped and connected to multiple business systems.

Q: What are the signs that OAuth-based NHI governance is failing?

A: Look for unclear app ownership, stale scopes, rare but powerful integrations, inconsistent token rotation, and app activity that looks routine while the data accessed is not. When integration logs and identity logs do not line up, teams lose the ability to tell whether the app is acting normally or abusively. That is a control gap, not just noise.

Q: Should teams revoke tokens first or investigate exposure first after an OAuth compromise?

A: Containment should come first, but only after you preserve enough telemetry to understand the blast radius and secret-harvest path. Revoke the compromised grants, then inspect exports, logs, and integration records for embedded credentials and secondary access paths. If the same app reaches several SaaS systems, treat the incident as multi-plane until proven otherwise.

Technical breakdown

How stolen OAuth tokens become application identity

OAuth is an authorisation framework, not a user login ceremony. In this campaign, the stolen token let the attacker present as the Drift application and authenticate directly to customer SaaS tenants, which is why MFA and human risk checks did not interrupt access. The critical technical point is that the receiving service trusts the token, not the person behind it, so the token inherits the app’s permissions and context until it is revoked or expires. Once that trust is in place, bulk queries and export-style access look like ordinary integration activity unless the organisation monitors app-level behaviour.

Practical implication: monitor OAuth usage as an NHI authentication channel, not as a user-session event.

Why a connected app creates multi-SaaS blast radius

A connected app often sits between multiple SaaS systems, identity planes, and admin consoles. In this case, token theft was not limited to one platform because the compromised grant could be replayed across the integration path and adjacent services. That is the classic SaaS-to-SaaS risk: one app-level credential can carry enough authority to move from CRM data into mail, workspace, and downstream exports. The architecture is especially fragile when the same integration is trusted in multiple tenants but revoked unevenly across them.

Practical implication: map every connected app to every tenant, scope, and downstream system before you assume revocation is complete.

Credential harvesting turns exfiltration into follow-on access

The article describes a credential-harvest loop, where data extraction was not the end state but the method for finding secrets that could unlock later access. That pattern matters because CRM exports, message content, and support data frequently contain embedded credentials, keys, or login clues. Once the attacker can mine those artefacts, the compromise expands from an OAuth incident into a broader identity supply chain problem. This is why the impact persisted beyond the initial token theft and why app monitoring has to include content-aware detection of secret markers.

Practical implication: inspect high-value SaaS exports for embedded secrets and treat those findings as live identity exposures.

Threat narrative

Attacker objective: The attacker’s objective was to turn one stolen SaaS integration token into repeatable access, secret discovery, and broader cross-platform exposure.

1. Entry occurred when UNC6395 used stolen OAuth tokens from Salesloft Drift integrations to authenticate as the application into customer SaaS environments.
2. Escalation followed as the actor used that app-level access to run bulk queries and exfiltrate data from Salesforce and Google Workspace-linked systems.
3. Impact expanded when the actor mined the extracted data for secrets that could support follow-on access into other cloud and data platforms.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Ownership debt is the governance failure that makes SaaS token theft durable: if nobody can name the accountable owner of a connected app, revocation becomes a coordination problem instead of a control. The article shows that token theft was amplified by unclear ownership, stale integrations, and inconsistent lifecycle discipline. That is not an implementation bug; it is a structural governance gap that identity teams must treat as part of NHI management, not platform administration.

Identity-centric monitoring is now the baseline for SaaS trust chains: user-focused controls are too late when the authentication event is the app itself. NHI governance has to watch token use, unusual query patterns, and cross-tenant behaviour at the integration layer, because that is where abuse becomes visible. Practitioners should read this as a validation of NHI-first detection models for SaaS environments.

Token governance debt is the right name for this class of exposure: grants accumulate, scopes drift, and rotation rarely keeps pace with business use. That debt compounds when integrations span Salesforce, Google Workspace, and other SaaS systems because revocation is no longer single-plane. The implication is that lifecycle governance must cover connected apps with the same seriousness as privileged human or server-side access.

Credential harvest loops turn exfiltration into an identity problem, not just a data problem: the breach did not stop at reading records because the data itself was a source of further secrets. That means data handling, secret discovery, and NHI monitoring now intersect in the same control plane. Practitioners should assume that any high-value SaaS repository may contain the next access credential unless content-aware scanning is in place.

Salesforce and Google Workspace were not the root cause, but they were the control surface: the campaign succeeded because the integrations were trusted more than the governance around them. That distinction matters for security architecture, because the decision point is no longer just who can log in, but which applications are allowed to act on behalf of the organisation. Teams need to re-evaluate connected app trust as a standing identity governance issue.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.

What this signals

OAuth token governance debt is now a board-level identity issue: the failure mode is not just stolen access, but access that remains valid across SaaS boundaries long enough to be reused. Programmes that still treat connected apps as a side concern will keep missing the real control point, which is lifecycle ownership of the token itself.

Identity-first monitoring has to move closer to the integration layer: a stolen app token can look like legitimate traffic unless teams compare query shape, timing, geography, and downstream data movement. That means detection logic should be written for non-human access paths, not adapted from user-session heuristics.

Credential harvest loops make data protection and NHI governance inseparable: once exports or support records can leak keys, the next compromise is already sitting inside the last incident. Practitioners should assume every high-value SaaS repository can become a secret source unless they actively scan for embedded credentials and govern who can act on what is discovered.

For practitioners

• Map every connected app to an accountable owner Build a current inventory of SaaS integrations, service accounts, token issuers, and downstream tenants. Require a named owner who can approve revocation, rotation, and exception handling when an app is used across multiple platforms.
• Inspect OAuth activity as an identity signal Review token usage, unexpected geographies, abnormal query volumes, and off-hours app activity as indicators of compromise. Correlate identity-provider logs with SaaS audit trails so app authentication is visible as a distinct control event.
• Search exports for embedded credentials Scan CRM records, file exports, support cases, and message content for secret markers such as API keys, refresh tokens, private key headers, and cloud login URLs. Treat any match as both a data exposure and an NHI exposure requiring immediate review.
• Enforce rotation with rollback guardrails Use a change-safe workflow for token revocation and connected-app credential rotation, including approvals, test windows, owner notifications, and rollback steps. That reduces the chance that incident response gets delayed because teams fear breaking production integrations.
• Reduce standing trust in SaaS integration paths Where possible, replace long-lived connected credentials with shorter-lived federated trust or tighter scope boundaries. Re-check every integration that can reach both SaaS data and downstream productivity systems, because those are the paths most likely to widen the blast radius.

Key takeaways

• The compromise shows how stolen OAuth tokens can turn a connected app into a durable non-human access path across SaaS systems.
• The article ties the campaign to bulk queries, data exfiltration, and secret harvesting, which is why the blast radius extended beyond the first target.
• The limiting control is not a user login fix, but accountable ownership, token lifecycle governance, and app-level monitoring for NHIs.

Key terms

• Connected App: A connected app is a third-party integration that is granted access to a SaaS platform through APIs and OAuth permissions. From a governance perspective, it is an identity-bearing access path that needs ownership, scoping, and periodic review like any other non-human identity.
• OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
• Token governance: Token governance is the control of credential lifecycle, scope, and runtime use for non-human identities. It combines inventory, issuance policy, behavioral monitoring, and revocation so that access remains limited, visible, and accountable across dynamic environments.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.