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 and the broader identity risk it exposes in SaaS integrations.

Why it matters: It matters because IAM, PAM, and NHI teams have to govern delegated access, token lifecycle, and visibility across integrations, not just user logins.

👉 Read AuthMind's analysis of the Salesloft Drift token abuse incident

Context

OAuth tokens and SAML assertions are designed to delegate access between applications, but that delegation becomes a security boundary of its own once tokens are long-lived, over-scoped, or poorly inventoried. In this case, the primary identity problem is not authentication failure at the Salesforce core, but the abuse of trusted non-human access paths across connected SaaS systems.

For identity programmes, this is a classic delegated-access governance failure. Teams that focus only on user MFA and perimeter controls miss the quieter exposure created by app-to-app trust, token reuse, and incomplete visibility into who or what can act inside SaaS environments.

Key questions

Q: What breaks when OAuth tokens are stolen from a trusted SaaS integration?

A: A stolen OAuth token can bypass password-based controls and act with the permissions already granted to the integration. That means the attacker may access data, trigger actions, or move across connected systems without obvious login failures. The failure is not the platform core, but the trust placed in delegated access.

Q: Why do delegated tokens increase breach impact in cloud and SaaS environments?

A: Delegated tokens often carry broad scopes and long lifetimes, so one compromise can expose multiple environments before anyone notices. Because the traffic looks authorised, defenders may not see the breach until data moves or behaviour changes. The result is a larger blast radius than the initial compromise suggests.

Q: What do security teams get wrong about OAuth and SAML access?

A: Teams often treat federated and delegated access as a setup detail instead of a governed identity path. That leads to weak inventory, poor ownership, and slow revocation. The mistake is assuming the trust relationship is stable just because the login flow is convenient.

Q: Who is accountable when a third-party integration is abused?

A: Accountability sits with both the organisation that issued the access and the team that approved or failed to review it. Governance should assign clear ownership for token lifecycle, integration approval, and revocation. If no one owns the delegated path, the breach response will always be slower than the attacker.

Technical breakdown

OAuth token abuse in SaaS integrations

OAuth lets an application act on behalf of a user or service without sharing passwords. That convenience becomes risky when the token carries broad scopes, remains valid for too long, or is reused across multiple tenants. In the Salesloft Drift case, the attacker did not break Salesforce itself. They abused trusted delegated access and used the token as a legitimate-looking identity credential. Because the traffic looked authorised, conventional login alarms were unlikely to fire. The technical problem is not just token theft, but token trust without enough lifecycle control or behavioural visibility.

Practical implication: inventory every delegated integration and treat its tokens as first-class identities with scope, expiry, and revocation controls.

Why token-based trust is hard to detect

Token abuse often bypasses the signals security teams expect from password compromise. There may be no MFA prompt, no failed login chain, and no obvious new device. Activity can appear normal because the token already encodes trust. That makes SaaS-to-SaaS abuse especially difficult for SIEM rules built around human authentication events. Detection depends on behavioural context such as source IP, access timing, access volume, and which objects were touched. In other words, the control problem is not just authentication, but recognising when delegated access starts behaving outside its intended pattern.

Practical implication: build detections around abnormal delegated access patterns, not only around interactive login events.

Token lifecycle and revocation gaps

A token is only as safe as the organisation’s ability to find it, classify it, and revoke it quickly. Many enterprises lack a complete inventory of active integrations, issued scopes, and dependency chains across vendors. When a breach lands, teams often have to trace connections manually, which slows containment and broadens impact. The Salesloft event showed how quickly one compromised integration can ripple across multiple customer environments. This is a lifecycle problem as much as a compromise problem: access exists, but ownership, review, and offboarding are incomplete.

Practical implication: tie integration offboarding to vendor risk reviews and revoke tokens as part of standard access lifecycle management.

Threat narrative

Attacker objective: The attacker’s objective was to exploit delegated SaaS trust to access customer data at scale through a trusted integration path.

1. Entry occurred when attackers obtained stolen OAuth tokens tied to the Salesloft Drift integration and used them as trusted access credentials inside connected Salesforce environments.
2. Escalation followed as the valid tokens let the attacker move through customer instances, extract data, and expand the attack surface without needing to break the core platform.
3. Impact emerged when organisations had to revoke integrations, reset tokens, and investigate what data had been accessed across multiple environments.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

Delegated SaaS access is now a primary identity perimeter. The breach was not a Salesforce compromise, it was a trust compromise inside the integration layer. OAuth tokens converted a third-party connection into durable access, which means identity governance has to extend beyond users and service accounts into every delegated app relationship. The practitioner takeaway is that integration trust must be governed as an identity control surface, not a convenience feature.

Token-based trust creates an identity blast radius that traditional login security cannot see. Once a token is issued, the attacker inherits the permissions attached to that delegation, often without MFA prompts or obvious authentication anomalies. That makes the real risk scope much wider than a single credential theft. Teams need to recognise that privilege now travels through software relationships, and that visibility into those relationships is a control requirement, not an optional enhancement.

Long-lived integrations are a lifecycle failure, not just a detection problem. If access can persist for months across multiple customers, then ownership, rotation, and offboarding were not designed tightly enough around the integration lifecycle. This is a standing-access problem in disguise, and the industry keeps treating it as an isolated incident problem. Practitioners should read it as proof that delegated access needs the same lifecycle discipline applied to human and machine identities.

Identity observability is becoming the only reliable way to catch trusted abuse early. When access looks legitimate by design, static policy checks miss the attack until exfiltration is already underway. That shifts the governance burden toward behavioural context, source validation, and scope-aware monitoring across SaaS. The field should stop assuming that trusted access is safe access, because trust is now a reusable attack primitive.

Salesloft token abuse shows why the identity control model must follow the delegation chain. The meaningful boundary is no longer the login screen. It is the chain from issued token to integrated workload to downstream customer instance, and that chain can fail anywhere trust is reused without review. Practitioners should govern the delegation chain as part of the identity programme, not as an adjacent SaaS management task.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That is why 52 NHI Breaches Analysis is the right next read for teams mapping breach patterns to lifecycle failure.

What this signals

Identity blast radius: delegated access can turn a single compromised integration into a multi-tenant exposure event, which is why teams need control maps that follow tokens across SaaS boundaries. The practical shift is toward ownership, expiry, and revocation discipline for every trusted connection.

When 80% of identity breaches involve compromised non-human identities such as service accounts and API keys, per the Ultimate Guide to NHIs, the lesson is structural. Security programmes that do not inventory delegated access will keep mistaking governance gaps for isolated incidents.

The next programme question is not whether integrations are useful, but whether the organisation can prove who owns each trust path, how long it lives, and how quickly it can be disabled. That is where SaaS identity governance now lives.

For practitioners

• Inventory all delegated SaaS integrations Map every OAuth, SAML, and API-token relationship across core business systems, then assign an owner, purpose, and expiry expectation to each connection.
• Classify tokens as governed identities Treat each active token like a non-human identity with scope, lifecycle, and revocation rules, rather than a background technical artifact.
• Monitor behavioural drift in delegated access Alert on unusual access volume, new source locations, and repeated machine-like activity from identities that normally behave like low-frequency integrations.
• Tie offboarding to integration review Require revocation of tokens and connected app access whenever a vendor relationship changes, a service is retired, or scopes are no longer justified.

Key takeaways

• The Salesloft Drift incident shows that trusted integration paths can be abused as effectively as stolen passwords, with much less visibility.
• The scale mattered because one compromised token chain forced revocation and investigation across multiple major SaaS environments.
• The limiting control is not only detection, but lifecycle governance for delegated access, including inventory, ownership, rotation, and offboarding.

Key terms

• Delegated Access: Delegated access is a trust relationship that lets one application or service act on behalf of another identity without sharing a password. In practice, it creates a non-human identity path that must be governed like any other privileged credential, including scope control, ownership, rotation, and revocation.
• OAuth Token: An OAuth token is a bearer credential issued to an application or user so it can access specific resources for a defined purpose. Because possession usually equals authority, token security depends on tight scope design, short lifetimes where possible, and fast revocation when trust changes.
• Identity Observability: Identity observability is the ability to see how identities behave across systems, not just whether they authenticated successfully. It combines access context, source, volume, timing, and pattern analysis so security teams can spot misuse of trusted credentials before data leaves the environment.
• Identity Blast Radius: Identity blast radius is the amount of systems, data, and downstream access exposed when one identity is compromised. For non-human identities, the blast radius is often determined by token scope, integration reach, and how quickly the organisation can revoke or contain the path.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by AuthMind covering the Salesloft Drift token abuse incident: stolen OAuth tokens and SaaS trust exposure. Read the original.