Salesloft Drift OAuth breach shows why NHI governance failed

At a glance

What this is: The Salesloft Drift OAuth breach showed how stolen non-human identity tokens can bypass human login controls and expose Salesforce data at scale.

Why it matters: It matters because IAM, NHI, and PAM teams need controls that govern machine trust, not just user authentication, when integrations can access customer data and hidden secrets.

👉 Read Token Security's analysis of the Salesloft Drift OAuth breach

Context

The primary issue here is not a user login failure, it is a delegated machine identity that carried trusted access into Salesforce. OAuth tokens, API keys, service accounts, and AI integrations now sit on the same trust path as human users, but they are usually governed with less scrutiny and fewer lifecycle controls.

Salesloft’s Drift integration breach shows what happens when a third-party NHI becomes a hidden conduit into SaaS data. Once that token was stolen, the attacker did not need to beat MFA or harvest passwords, because the integration itself was already authorised to act.

Key questions

Q: How should security teams handle stolen OAuth tokens in SaaS environments?

A: Treat stolen OAuth tokens as compromised production identities, not just leaked secrets. Revoke the token immediately, verify which datasets and APIs it could reach, and inspect downstream systems for additional credentials the integration may have exposed. The key is to contain the delegated trust path before the attacker can expand into other cloud services.

Q: Why do third-party integrations create more identity risk than human logins?

A: Third-party integrations often hold persistent, broad, and poorly observed access to sensitive systems. Unlike human logins, they can operate without MFA prompts, may run continuously, and frequently touch multiple downstream services. That makes them ideal for covert reconnaissance, data export, and secret harvesting when the token or service account is abused.

Q: What breaks when OAuth scopes are too broad for a SaaS integration?

A: Broad scopes collapse the boundary between routine app activity and attacker-controlled access. If one integration can read, export, and traverse too much data, a stolen token can quickly turn into customer data exposure and secret discovery. Narrow scopes, isolated permissions, and clear ownership are what prevent one identity from becoming a platform-wide breach.

Q: Who is accountable when a machine identity exposes customer data?

A: Accountability sits with the team that owns the integration, the platform team that granted the scope, and the security function that failed to govern the token lifecycle. For SaaS and cloud programmes, machine identities need explicit ownership, review, and revocation processes just like privileged human access.

Technical breakdown

Stolen OAuth tokens become trusted machine access

OAuth access and refresh tokens are non-human identities because they represent pre-authorised delegated access rather than a person logging in. In this incident, the attacker did not need to crack passwords or defeat MFA. They used valid tokens to authenticate as the integration itself, which is exactly why token theft is so dangerous in SaaS environments: the platform sees legitimate app behaviour, not an obvious intrusion. Once the token is accepted, the boundary between authorised integration and attacker control disappears.

Practical implication: treat every third-party OAuth token as a production identity with explicit scope, ownership, and revocation handling.

Salesforce query activity can hide reconnaissance and exfiltration

After initial access, attackers used query APIs to enumerate objects, locate valuable records, and export data over time. This is a common abuse pattern for NHI compromise because the activity blends into normal application traffic unless teams baseline what a specific integration should query, how often, and at what volume. Deleting logs or disguising requests makes the abuse harder to separate from expected app behaviour, especially when monitoring is tuned for human sign-in anomalies rather than machine session patterns.

Practical implication: build behavioural baselines for high-value integrations and alert on unusual query breadth, export volume, or object traversal.

One compromised integration can propagate new secret exposure

The breach did not stop at Salesforce access. Attackers reportedly found AWS keys, Snowflake tokens, and other secrets embedded in records, which means one compromised NHI can expose other NHIs across cloud and SaaS platforms. This is the compound-risk problem in modern identity estates: a single delegated trust path can create a wider secret-harvesting opportunity than the original target. Once secrets are surfaced inside business systems, the attack becomes a cross-platform identity problem, not just a SaaS incident.

Practical implication: classify integrations as secret-bearing identities and scan downstream systems for credentials that a breached NHI could reveal.

Threat narrative

Attacker objective: The attacker’s objective was to turn one trusted SaaS integration into broad customer data access and a launch point for additional cloud and identity compromises.

1. Entry occurred when attackers stole OAuth access and refresh tokens tied to the Drift AI chat integration, giving them legitimate machine access into Salesforce.
2. Escalation followed as the attacker used that trusted integration to query objects, enumerate records, and blend activity into normal app traffic while harvesting more secrets.
3. Impact came from data export across hundreds of organisations and the discovery of additional cloud credentials that could seed follow-on compromises.

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

Third-party OAuth trust is now an identity perimeter, not an integration detail: The Salesloft Drift breach shows that delegated access can become the real front door into SaaS data. Once a token is stolen, the platform still sees an authorised machine, which means traditional user-authentication controls are watching the wrong boundary. Practitioners should treat third-party OAuth trust as a governed identity surface, not a convenience layer.

Credential visibility fails when the integration layer is treated as background infrastructure: The breach worked because the attacker moved through a machine identity that was trusted too broadly and monitored too lightly. That is a governance failure, not just an incident response issue, because the access path existed long before the intrusion. The implication is that SaaS and cloud programmes need explicit ownership for every non-human identity that can reach sensitive data.

Identity blast radius is the right named concept for this pattern: One compromised NHI can expose downstream secrets, customer records, and additional systems in a single chain of trust. That blast radius is shaped less by the initial token and more by what that token can see, query, and reveal once inside the business system. Practitioners should reduce the scope of machine identities before they become secret harvesters.

Standing machine privilege still creates the same governance debt in SaaS that it does in infrastructure: A valid token with persistent access is functionally a standing credential, even if it belongs to an integration rather than a person. The problem is not only theft but persistence, because long-lived trust gives attackers time to blend in and expand. Security teams should re-evaluate which integrations have access that outlives operational need.

Human-centric defenses do not close machine identity exposure: MFA, login review, and user session monitoring are useful controls, but they do not govern a stolen OAuth token that never asks a human to authenticate. This is where NHI governance must sit alongside IAM and PAM, because the adversary path is no longer a person logging in. The practitioner conclusion is to extend identity policy to machine principals with the same rigor as privileged users.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• In the same research, only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which explains why delegated access keeps outrunning governance.
• For a wider view of breach patterns, 52 NHI Breaches Analysis shows how hidden machine trust repeatedly becomes the entry point for compromise.

What this signals

Identity blast radius: the practical risk here is not the first stolen token, but how far that token can reach once an integration is trusted inside multiple SaaS and cloud systems. Programmes that still separate SaaS governance from NHI governance will miss the cross-platform propagation path.

If your controls are still built around human sign-in events, you are already behind. The operational signal to watch is delegated access that can query, export, and reveal secrets without triggering any user-facing authentication step.

A stronger response is to treat integrations as governed identities with owners, scopes, and revocation tests, then link them to broader identity lifecycle controls and detection rules.

For practitioners

• Inventory every third-party OAuth integration Map which SaaS applications hold delegated access, who owns them, what scopes they carry, and which downstream datasets they can query or export.
• Reduce token scope before the next review cycle Remove broad read and export permissions from integrations that do not need them, and separate operational access from reporting access where possible.
• Baseline machine behaviour for high-value apps Define normal query volume, object traversal, and export patterns for each integration, then alert on unusual access to customer records or secrets.
• Scan business systems for downstream secrets Look for AWS keys, Snowflake tokens, API keys, and other credentials that integrations might expose inside Salesforce records or similar data stores.
• Test revocation and quarantine workflows Validate that compromised OAuth tokens can be invalidated quickly and that dependent business processes can fail over without leaving standing access behind.

Key takeaways

• The breach revealed a governance gap in delegated machine access, not a failure of human login security.
• One compromised integration exposed data across hundreds of organisations and created a pathway to additional cloud secrets.
• The limiting control is scope and lifecycle governance for OAuth tokens, not just detection after abuse has begun.

Key terms

• OAuth Token: An OAuth token is a delegated credential that allows an application to act on behalf of a user or another service without re-entering a password. In NHI governance, it should be treated as a production identity with explicit scope, ownership, and revocation requirements.
• Delegated Access: Delegated access is permission granted to one identity to act within the bounds of another identity or system relationship. For machine identities, it often persists beyond the immediate task, which makes lifecycle control and scope review essential for security teams.
• Identity Blast Radius: Identity blast radius is the amount of access, data, and downstream systems that a compromised identity can reach before containment. It is determined by scope, connectivity, and persistence, not by the attacker’s first foothold alone.
• Standing Machine Privilege: Standing machine privilege is persistent access held by a non-human identity that remains active beyond immediate need. It creates governance debt because a stolen or over-privileged token can be reused continuously until someone revokes it or the trust relationship expires.

What's in the full article

Token Security's full blog covers the operational detail this post intentionally leaves for the source:

• A step-by-step breakdown of how the Drift integration was compromised and how the attacker moved through Salesforce.
• Specific examples of the secrets and customer records exposed during the campaign.
• Token Security's product-side visibility and remediation workflow for discovering compromised NHIs.
• The vendor's explanation of how its NHI discovery and response model maps to this breach pattern.

👉 Token Security's full post covers the attack path, exposed secrets, and NHI remediation details.

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.