Salesloft token abuse shows why trust is the new attack surface

At a glance

What this is: This is an analysis of the Salesloft Drift token abuse incident, which shows how compromised OAuth trust relationships can expose multiple Salesforce environments without a Salesforce breach.

Why it matters: It matters because IAM and NHI teams need to govern delegated SaaS access as a live attack surface, not a static integration list, especially where tokens persist across tenants and vendors.

Context

OAuth tokens let one application act on behalf of a user or service inside another platform. In this case, attackers abused stolen tokens tied to the Salesloft Drift integration to reach Salesforce environments through trusted delegated access rather than by breaking Salesforce itself.

For identity programmes, the problem is not just token theft. It is the governance gap around who issued the token, what scope it carried, how long it stayed valid, and whether anyone was actively monitoring app-to-app access patterns across the SaaS estate.

The article frames this as a breach of trust that cut across major enterprises, which is typical of modern SaaS integration risk rather than an isolated configuration mistake.

Key questions

Q: What breaks when an OAuth integration is compromised but the core platform is not breached?

A: The trust model breaks, not just the token. A valid delegated token can still grant access to customer data, workflows, and APIs even when the primary SaaS platform remains intact. That means organisations must govern the integration path itself, including scope, ownership, revocation, and monitoring, rather than assuming platform security covers delegated access.

Q: Why do long-lived developer OAuth credentials increase breach impact?

A: Because they preserve trust even after the initiating user action is over. If a token is stolen, the attacker inherits whatever repository, workflow, or API reach was granted at issuance, and that reach can persist until explicit revocation. The result is a wider blast radius than most teams expect from a seemingly small authentication event.

Q: How can security teams tell whether delegated SaaS access is over-extended?

A: Look for integrations that can reach more data, more functions or more systems than their business purpose requires. Warning signs include inherited admin roles, broad OAuth scopes, service accounts with persistent access and tokens that are reused across multiple apps. If the effective access is wider than the approved use case, the integration is over-extended.

Q: When should organisations revoke an OAuth grant or third-party app permission?

A: Revoke it when the business owner cannot justify the access, when the app is unused, when scopes exceed the current need, or when the provider cannot meet your security baseline. Dormant consent is still active risk, and expired business purpose should mean expired trust.

Technical breakdown

How OAuth token abuse turns delegated access into lateral reach

OAuth is designed to delegate access without sharing a password. That same delegation becomes dangerous when a token is stolen, because the bearer token itself is enough to act inside connected SaaS services until it is revoked or expires. The attacker does not need to defeat the primary platform if the integration already has broad authority. In multi-tenant SaaS, one compromised app can therefore become a pivot point across customer environments, especially where scopes are wide and token lifetimes are long.

Practical implication: govern delegated SaaS access as a credential class with its own inventory, scope, and revocation process.

Why long-lived tokens create hidden trust debt

Long-lived tokens are operationally convenient because they avoid repeated reauthentication, but they also extend the window in which stolen access remains usable. In practice, this creates trust debt: the organisation inherits risk the moment the token is issued, then accumulates more exposure each day it stays valid. If the integration is not continuously reviewed, teams often discover the problem only after a disclosure or anomaly, not at issuance time. That makes token age and scope just as important as the application itself.

Practical implication: define expiry, rotation, and re-consent rules for OAuth tokens based on risk, not convenience.

Why standard monitoring misses app-to-app compromise

Traditional monitoring is still biased toward user logins, endpoint events, and interactive sessions. OAuth-driven access often happens behind the scenes through APIs, so it can look legitimate unless teams specifically track delegated identities, unusual access volume, and unfamiliar source locations. The visibility problem is structural: the access path is valid, the token is accepted, and the activity may resemble automation. That is why identity observability matters for SaaS integrations, especially when third-party apps bridge multiple business systems.

Practical implication: add delegated-access telemetry and anomaly detection to SIEM and identity monitoring workflows.

Threat narrative

Attacker objective: The attacker sought persistent, trusted access to Salesforce-connected data and workflows through delegated SaaS integrations rather than direct platform compromise.

1. Attackers obtained stolen OAuth tokens associated with the Salesloft Drift integration and used them as valid entry credentials into connected Salesforce environments.
2. The delegated tokens provided standing access through trusted application paths, allowing activity to appear legitimate while the attacker moved through customer instances.
3. The compromise forced token revocation, integration shutdowns, and internal investigations as organisations worked to contain access and assess data exposure.

Breaches seen in the wild

• 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.
• 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.

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

Delegated SaaS trust is now an attack surface, not a convenience layer. The Salesloft Drift incident shows that OAuth relationships can carry the same operational risk as privileged credentials when the token itself becomes the access mechanism. Once an app is trusted, the security boundary shifts from login control to delegation control. Practitioners should treat every external integration as a governed identity relationship, not a feature toggle.

Long-lived OAuth tokens create trust debt that compounds silently. Tokens issued for convenience can remain valid long after the organisation has forgotten why they exist or who approved them. That is not just a lifecycle weakness; it is a structural exposure window that expands with every inactive integration and over-broad scope. The governance lesson is that token age, scope, and revocation ownership must be visible as first-class identity controls.

Token abuse exposes a named concept: identity spillover across SaaS tenants. One compromised integration can ripple from vendor app to customer environment to downstream business systems without a platform breach in the core service. That spillover is what makes SaaS delegation different from ordinary account compromise. The implication is that identity governance must follow the trust chain across tenants, vendors, and linked services, not stop at the application boundary.

Identity observability has become a control requirement for delegated access. Traditional perimeter and login-centric monitoring cannot see the quiet misuse of valid tokens inside API traffic. Behavioural signals such as sudden access spikes, foreign source locations, and automation-like patterns are often the earliest evidence. Security teams need to treat delegated-access telemetry as part of core IAM and NHI governance, not an optional detection layer.

OAuth and SAML design assumptions break when trust is recycled faster than oversight. These protocols assume delegated access remains legible enough to inventory, review, and revoke. That assumption fails when integrations proliferate faster than governance can track them, because the organisation no longer knows which trusted paths are active, which scopes are excessive, or which token holders still matter. The implication is that lifecycle governance must be rebuilt around delegated trust rather than human login events.

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 spillover across SaaS tenants: a single compromised integration can propagate access across vendor, customer, and downstream business systems. That makes delegated trust a lifecycle problem, not just an authentication problem, because the real boundary is the trust chain rather than the app boundary.

Security teams should move delegated access into the same governance model they use for privileged accounts and machine credentials. If the organisation cannot answer who owns a token, why it exists, and when it will be removed, the token is already outside control.

The practical shift is from login-centric monitoring to delegated-access observability. Behavioural anomalies, unusual source geographies, and sudden volume spikes are often the earliest signs that trusted app-to-app access has been repurposed for abuse.

For practitioners

• Inventory all delegated SaaS integrations Build a live register of every OAuth and SAML integration, including issuer, scope, owner, expiry, and business purpose. Remove orphaned or undocumented connections first, because unknown integrations are the fastest path to hidden exposure.
• Reduce token scope and lifetime Replace broad, long-lived access grants with narrowly scoped tokens and explicit renewal rules. Tie renewal to business justification, not vendor defaults, so stale trust does not persist indefinitely.
• Monitor delegated-access behaviour as identity telemetry Track access volume, source geography, automation-like cadence, and unusual API activity for each integration. Route those signals into your SIEM and identity workflows so token misuse is visible before bulk exfiltration begins.
• Create a token revocation playbook Define who can revoke integration tokens, how quickly revocation happens after disclosure, and how downstream business owners are notified. Test the playbook against a third-party compromise scenario, not just a user account incident.
• Re-certify third-party access on a fixed cadence Treat vendor integrations like privileged access and require periodic review of scope, necessity, and ownership. If the integration cannot be justified, offboard it and revoke the associated credentials.

Key takeaways

• The incident shows that delegated OAuth trust can be abused even when the underlying SaaS platform is not breached.
• Its impact spread because token-based access often persists longer and is monitored less rigorously than interactive user access.
• The strongest control is lifecycle governance over integrations, including scope reduction, ownership clarity, continuous monitoring, and fast revocation.

Key terms

• Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
• 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 Revocation: Token revocation is the ability to invalidate a credential before its natural expiry when it is exposed, misused, or no longer needed. For JWTs and other NHI credentials, revocation closes the gap between detection and continued access, which is essential when a stolen token can otherwise remain usable.
• Identity Observability: Identity observability is a continuous governance approach that correlates identity activity with business context, telemetry, and policy state. Instead of checking access at a single point in time, it tracks what an identity can do, what it did, and why that action matters to the business.

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.