Salesloft Drift OAuth breach shows why NHI governance failed

At a glance

What this is: This is Token Security's analysis of the Salesloft Drift OAuth breach, where stolen integration tokens let attackers impersonate a trusted NHI and move through Salesforce customer environments.

Why it matters: It matters because IAM and NHI programmes must govern token scope, lifecycle, and downstream trust chains, not just user authentication and MFA.

Context

The security gap here is straightforward: a trusted integration token can act as a machine identity with more reach than a human account, yet many governance models still treat it as a technical artifact rather than an identity that needs lifecycle control. In this case, the compromise did not begin with password theft or MFA bypass. It began with stolen OAuth credentials that were already authorised to reach Salesforce.

That matters for NHI governance because OAuth tokens, API keys, and service accounts often sit outside the review cadence used for human users. Once those credentials are embedded in SaaS workflows, their trust relationship can extend far beyond the original app. The Salesloft Drift case is a clear example of how one exposed integration can become a platform-wide access path.

The article also shows why downstream secret discovery is part of the identity problem, not a separate cleanup task. When attackers can read customer records and embedded credentials from a trusted integration, one compromised NHI can seed additional compromises across cloud and data platforms.

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: SaaS Integration Risk

A: The exposure created when a SaaS application connects to other systems through OAuth grants, API keys, or automation workflows. These connections often inherit broad trust and can extend access well beyond the original business need if they are not reviewed and revoked on a lifecycle basis.

Q: How can organisations tell whether NHI governance is actually working?

A: NHI governance is working when every machine identity has an owner, a purpose, a minimum-necessary entitlement, and evidence of rotation and review. If teams can produce that chain without manual reconstruction, the programme is mature enough to withstand audit pressure. If they cannot, the governance model is still fragmented.

Q: What should teams do first after a third-party integration is compromised?

A: Contain the integration immediately by revoking tokens, disabling related OAuth grants where needed, and checking for related activity across the same trust boundary. Then identify reachable data, review logs for lateral use, and rotate any secrets that may have been exposed through the connected workflow. The first 24 to 72 hours should focus on scope, not theory.

Technical breakdown

How stolen OAuth tokens become trusted machine identities

OAuth access and refresh tokens are bearer credentials, which means possession is enough to act as the authorised integration until revocation or expiry. In SaaS environments, those tokens often stand in for a non-human identity, carrying delegated access into other systems without a human sign-in step. That makes token theft structurally different from password theft: the attacker does not need to authenticate as a person, only to present the credential the platform already trusts. In the Salesloft Drift case, the stolen tokens let the attacker appear as the integration itself, not as an external intruder.

Practical implication: Treat every OAuth token as an identity with scope, ownership, and revocation requirements, not as a disposable technical secret.

Why MFA and human login controls did not help

MFA protects interactive human authentication, but it does not govern a pre-authorised integration that is already allowed to call APIs. Once the attacker had valid Drift tokens, Salesforce saw legitimate app activity and accepted it as trusted machine traffic. This is the central governance gap in many SaaS estates: the control plane for humans is stronger than the control plane for NHIs, even though the latter often has broader data reach. The result is a blind spot where an integration can move data, query objects, and export records without triggering the same checkpoints used for employees.

Practical implication: Separate human authentication controls from machine identity governance and review the permissions granted to every SaaS integration.

How one compromise propagated into additional cloud credentials

The breach did not end inside Salesforce. Once attackers had access to customer records, they found AWS keys, Snowflake tokens, and other secrets embedded in the data they could query. That is a classic NHI amplification pattern: a trusted integration becomes a discovery point for other credentials, which then become fresh entry paths into adjacent environments. The mechanism is not exploitation of a software bug so much as exploitation of identity trust chains that were never bounded tightly enough. This is why identity governance for NHIs has to include both direct access and what those identities can reveal.

Practical implication: Inventory embedded secrets exposed to SaaS integrations and treat them as part of the same trust domain as the integration token itself.

Threat narrative

Attacker objective: The attackers aimed to extract customer data and reusable credentials from trusted SaaS environments to extend the breach across cloud platforms.

1. Entry occurred when attackers stole OAuth access and refresh tokens tied to the Drift AI chat integration.
2. Escalation followed when those tokens were used to authenticate directly as a trusted Salesforce integration with no human checkpoint.
3. Impact came when the attackers queried Salesforce data at scale, deleted logs, and harvested embedded cloud credentials for follow-on compromise.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• 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

OAuth token governance failed because the organisation treated delegated access as a technical artifact rather than a first-class identity. That assumption breaks as soon as a token can act with the same trust as an application account and reach customer records at scale. The Salesloft Drift case shows that lifecycle ownership, revocation authority, and permission scoping must be applied to machine identities with the same discipline used for privileged human access.

Human-centric authentication controls do not contain machine-to-machine compromise. MFA and login assurance are designed around interactive users, not bearer credentials already authorised to act on behalf of an integration. When the attacker presents the right token, the platform sees a legitimate actor, which means the governance failure is not just weak authentication but a misplaced control boundary.

Identity blast radius is the right concept for SaaS integration risk. A single trusted app can expose customer data in one system and embedded secrets for several others, so the real unit of governance is the downstream reach of the credential. Practitioners should measure how far one integration can move before revocation, because that is the true exposure surface.

Vendor access without lifecycle offboarding is a durable breach pattern. Once an integration token can outlive the business assumption that created it, accountability lags behind access. That means third-party access reviews must track not only who owns the integration, but also what data it can reveal, what other credentials it can surface, and how quickly it can be revoked.

The market keeps calling these credentials secrets, but the operating reality is identity. OAuth tokens, API keys, and service accounts behave like identities because they authenticate, authorise, and propagate trust across systems. NHI governance is the discipline that makes that distinction operational, and this breach is another proof that the distinction cannot be ignored.

From our research library:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Read next: Service Account Security Guide

What this signals

Identity blast radius: the important question is not whether a token is valid, but how far that token can reach before revocation. When a SaaS integration can expose customer records and embedded secrets, governance has to move from account-centric reviews to dependency-aware access control.

Access reviews built for people do not solve delegated machine access. OAuth tokens can behave like durable identities with broad downstream reach, so the governance model needs explicit ownership, expiry, and revocation paths for every integration that touches sensitive data.

Only 20% have formal processes for offboarding and revoking API keys, according to the Ultimate Guide to NHIs. That gap is exactly what lets trusted machine identities outlive the business assumptions behind them.

For practitioners

• Inventory every SaaS integration token Map OAuth access and refresh tokens to an owner, system purpose, and explicit business justification so no integration remains unclaimed.
• Scope integrations to the minimum Salesforce access Review which objects, queries, and export actions each integration can perform, then remove permissions that are not required for the workflow.
• Separate machine identity reviews from human access reviews Build a governance process that certifies integrations on their own lifecycle, rather than folding them into employee recertification cycles.
• Scan downstream records for embedded secrets Look for AWS keys, Snowflake tokens, API keys, and similar credentials inside CRM and case data that a trusted integration can read.
• Pre-authorise revocation for compromised integrations Define who can invalidate a token, what signals trigger quarantine, and how quickly dependent workflows can be restored after revocation.

Key takeaways

• This breach exposed how a trusted OAuth integration can function as a machine identity with enough privilege to bypass human-centric access controls.
• Token Security says the incident affected hundreds of organisations and ran long enough to support data extraction and secret harvesting.
• The limiting control is not stronger MFA for users but tighter lifecycle governance, scoping, and revocation for non-human identities.

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.
• Bearer Credential: A bearer credential is a secret that grants access to whoever possesses it, without requiring proof of the original user at every request. In SaaS and cloud environments, OAuth tokens, session cookies, and similar artifacts behave this way, which makes theft and replay a direct access 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.