Salesloft Drift exposure shows OAuth tokens can widen SaaS blast radius

At a glance

What this is: This article examines how compromised OAuth tokens in Salesloft Drift expanded access into connected SaaS applications and exposed secrets-hunting risk across the integration chain.

Why it matters: It matters because IAM and NHI teams have to govern third-party access paths, not just user sign-ins, when token trust can widen blast radius across SaaS environments.

Context

OAuth token abuse becomes a governance problem when integrations can carry an attacker from one trusted SaaS app into several others without reauthentication. In this case, the exposure was not about a broken password or failed MFA prompt, but about delegated access that outlived the security assumptions behind it.

For IAM, IGA, and NHI programmes, the relevant question is whether tokens, app grants, and connected data paths are inventoried, scoped, and continuously reviewed. When third-party integrations can reach sensitive records, the security boundary shifts from login control to data and entitlement control across the SaaS estate.

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 interconnected SaaS ecosystems increase breach impact when one integration is compromised?

A: Interconnected SaaS ecosystems increase breach impact because every integration inherits trust and can extend access across downstream apps, tenants, and workflows. When one app, token, or agent is abused, attackers may pivot through authorized connections without triggering traditional perimeter controls. The risk grows when permissions drift, scopes expand, or organizations lack continuous visibility into cross-app activity.

Q: How can security teams tell whether OAuth access is too broad?

A: Look for apps that can read sensitive records, search wide data sets, or access more business functions than the integration needs. Broad scopes, stale grants, and app-to-app links into customer data are the clearest signals that token access is exceeding its intended boundary. If a token can support secrets hunting, it is already too permissive.

Q: How should teams reduce risk from secrets hidden in SaaS data?

A: Teams should search business systems such as tickets, attachments, and chat exports for embedded credentials, then remove or rotate anything sensitive. Those repositories often contain cloud keys and tokens that attackers can reuse immediately after exfiltration. Detection without cleanup leaves the same access available to the next intruder.

Technical breakdown

How OAuth tokens become a trusted integration channel

OAuth access tokens let one application act on behalf of a user or another system without repeatedly asking for credentials. That is useful for SaaS interoperability, but it also means the integration inherits the trust of the original grant. If the token is stolen or misused, the attacker does not need to defeat the primary login flow. They can operate inside the connected service with the authority that was already delegated, which is why OAuth-linked access has become a recurring identity security concern.

Practical implication: Treat app grants as governed identities and inventory every token that can reach sensitive SaaS data.

Why connected SaaS apps widen the blast radius

Modern SaaS environments are linked by many-to-many integrations, webhooks, API keys, and delegated app permissions. That creates a dependency chain in which compromise of one integration can expose several downstream systems. The danger is not only direct data access. Attackers can also traverse objects, notes, and records looking for embedded secrets, credentials, or tokens that open additional paths. In practice, the blast radius is defined by what the compromised app can reach, not by where the compromise started.

Practical implication: Map every third-party path from an integration to high-value data and revoke access that is not clearly required.

Why secrets in records turn access into escalation

When passwords, API keys, or other secrets are stored inside SaaS records, the compromise of an integration becomes a launch point for further escalation. Those secrets can be copied out and reused against other systems, turning a single token abuse event into a broader compromise chain. This is a classic example of identity and data controls colliding: the app grant opens the door, but the exposed secrets create the next set of credentials the attacker can weaponise.

Practical implication: Remove secrets from business records and treat any embedded credential as a latent escalation path.

Threat narrative

Attacker objective: The attacker objective was to use delegated SaaS access to reach sensitive data and harvest reusable secrets that could unlock additional systems.

1. Entry occurred through abused OAuth tokens tied to Salesloft Drift, giving attackers unauthorized access to connected SaaS applications.
2. Credential access followed as the attackers searched customer environments for embedded secrets and credentials that could be reused elsewhere.
3. Impact expanded across the integration chain because the compromised token trust extended into connected platforms such as Salesforce and other SaaS services.

Breaches seen in the wild

• Gainsight Salesforce breach 2025: Stolen OAuth tokens for Gainsight's Salesforce app, some eight years old, were used against customer orgs; Google saw 200+ instances at risk.
• 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 and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth delegation is now an identity boundary, not a convenience feature. Once a token can move from one SaaS service into several others, the control question shifts from authentication to delegated authority. That means identity programmes have to govern app grants, not just users, because the compromised trust relationship is the security event. Practitioners should treat integration scope as part of the access model.

Identity blast radius is the right concept for SaaS integration risk. The article shows that a single compromised integration can extend into multiple connected services, which is why traditional account-centric thinking underestimates exposure. Blast radius is determined by the combination of token scope, connected apps, and where secrets are stored. Practitioners need governance that reflects the reach of the integration estate, not the login surface alone.

Secrets inside SaaS content turn data governance into access governance. When credentials are embedded in records, the distinction between data exposure and privilege escalation disappears. A data platform can become an access broker if hidden credentials can be harvested and reused. That makes data visibility a prerequisite for NHI control, especially where third-party applications can search the same repositories humans use for collaboration.

Standards for machine and delegated identity are now a practical requirement for SaaS estates. OWASP-NHI and NIST CSF-aligned access governance both point toward the same operational conclusion: inventory, scope, and lifecycle review for non-human access must be continuous. The SaaS ecosystem is too connected for one-time approvals to be meaningful. Practitioners should govern the whole delegated path from app grant to downstream data access.

Vendors and customers share accountability for integration trust, but only customers can see the full blast radius. The source article rightly frames this as an ecosystem problem, not a single-product failure. Even when a third-party integration is the entry point, the enterprise still owns the risk of what that integration can reach and what secrets it can expose. Security teams should therefore measure third-party access as part of identity governance, not as a separate supplier task.

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

Identity blast radius: when a token can traverse multiple SaaS services, the meaningful unit of control is the integration path, not the individual login. That shifts programme focus toward app-grant inventory, downstream reach, and revocation discipline.

Enterprises should expect more incidents where stolen or abused OAuth tokens are used to hunt for embedded secrets inside collaboration and CRM data. The governing problem is no longer whether MFA worked at the front door, but whether the connected estate was visible enough to constrain the back door.

For practitioners

• Audit third-party OAuth grants Identify every SaaS integration that can read, write, or search sensitive records, then remove unused grants and overbroad scopes.
• Eliminate embedded secrets from SaaS records Search collaboration objects, CRM notes, and attachments for API keys, passwords, and tokens, then remove or quarantine any exposed credentials.
• Right-size token scope and lifetime Constrain each app grant to the minimum data set and shortest practical lifetime, especially for integrations that can reach customer records.
• Map downstream access paths Document which integrations can reach which systems and data stores so that compromise impact is measured by actual reach, not assumed trust.
• Add data visibility to identity reviews Use data-centric discovery to show where secrets live in SaaS content before recertifying app access or supplier permissions.

Key takeaways

• A compromised OAuth token can turn a trusted SaaS integration into an attacker-controlled access path across multiple connected applications.
• The article shows that attackers were not only after data, but also searching for secrets and credentials that could extend the compromise.
• Teams should govern delegated access, strip secrets from SaaS content, and measure blast radius by integration reach rather than by login controls alone.

Key terms

• 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.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
• Embedded Secret: An embedded secret is a credential, token, API key, or certificate that has been placed inside an image, file, or configuration bundle. Once exposed, it can outlive the original control that created it, so revocation and rebuilds become necessary even if the underlying system is later patched.

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.