Salesloft Drift token theft exposes the toxic data model in SaaS

At a glance

What this is: This analysis says the Salesloft Drift compromise was a token-theft supply chain attack that turned SaaS integration trust into a credential-harvesting campaign.

Why it matters: It matters because IAM, PAM, NHI, and lifecycle teams must treat third-party integrations, API keys, and OAuth tokens as governed identities with blast-radius limits, not static plumbing.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.

👉 Read Defakto Security's analysis of the Salesloft Drift token theft and Salesforce exposure

Context

Salesloft Drift token theft is best understood as a supply chain identity failure, not a conventional Salesforce breach. Attackers did not need to break application logic first; they used compromised OAuth tokens issued to a third-party integration and then pursued the credentials those tokens exposed across connected environments.

For IAM and NHI programmes, the key issue is that integrations, bots, and connectors often carry durable trust that outlives the business need that created it. When a third-party workflow can reach Salesforce, AWS, Snowflake, Slack, Azure, Google Workspace, or OpenAI, the governance question is no longer who authenticated once, but what that identity can keep touching after the original session should have ended.

This is a typical pattern for modern SaaS and AI-connected estates. The attack surface now includes every place credentials are copied, cached, or reused outside the original system of record.

Key questions

Q: What breaks when a third-party OAuth integration is compromised?

A: When a third-party OAuth integration is compromised, the attacker inherits the delegated permissions already granted to that connector and can move through whichever services trust it. The failure is not limited to the first application. It often includes downstream SaaS, cloud, and collaboration tools that accepted the same identity without additional review.

Q: Why do long-lived API keys and tokens create so much risk?

A: Long-lived API keys and tokens create risk because they persist across logs, tickets, chats, and automation pipelines long after the original use case ends. That persistence gives attackers more places to find them and more time to replay them. In practice, durable secrets turn routine integrations into standing trust.

Q: How do security teams know whether secret rotation is actually reducing exposure?

A: Rotation is working only if exposure shrinks in both lifetime and reach. If secrets still appear in collaboration tools, support systems, or automation logs, the programme is reducing incident impact but not the underlying trust debt. Teams should measure where secrets replicate and how quickly they can be revoked everywhere they appear.

Q: Who is accountable when a supplier integration exposes customer credentials?

A: Accountability sits with both the supplier that issued or stored the compromised secret and the customer that trusted the integration without a clear lifecycle model. Governance frameworks should define ownership for scope, revocation, and downstream impact before the next incident. Otherwise, response becomes a scramble after the fact.

Technical breakdown

How OAuth token theft turns a third-party integration into enterprise access

OAuth is designed to let a connected application act on a user's or system's behalf without sharing a password. In practice, that means the token becomes the real control plane for access. If attackers steal the token issued to a SaaS integration, they inherit the integration's delegated permissions and can call downstream APIs until the token expires or is revoked. In this incident pattern, the dangerous part is not the login screen. It is the trust already embedded in the connector, the scopes already approved, and the credentials already stored somewhere the attacker can reach.

Practical implication: review every third-party OAuth grant as a non-human identity with explicit scope, expiry, and revocation ownership.

Why exposed API keys and secrets become lateral-movement accelerants

API keys, cloud tokens, and service passwords are high-value secrets because they often authenticate machine-to-machine traffic without additional user friction. Once stolen, they can be replayed across services, embedded into automation, or used to query adjacent systems that trust the original identity. That makes secrets a mobility mechanism as much as an authentication mechanism. In a supply chain compromise, the first stolen token is often not the end state. It is the bridge to more durable access, more privileges, and a wider breach radius across SaaS and cloud estates.

Practical implication: map which secrets can reach adjacent systems and treat each one as a potential lateral-movement path.

Why long-lived credentials create toxic data exposure windows

Long-lived credentials persist far beyond the transaction that justified them, so they accumulate risk in logs, tickets, chats, and automation pipelines. The longer a secret exists, the more places it can be copied and the harder it is to prove what was exposed. This is why key rotation is only a damage-limitation tactic if the underlying model still issues persistent secrets. The real architectural problem is that durable credentials create permanent trust surfaces that attackers can eventually find and reuse.

Practical implication: reduce credential lifetime, eliminate unnecessary secret persistence, and govern every place secrets are replicated.

Threat narrative

Attacker objective: The objective was to harvest credentials that could unlock broader enterprise access than the original integration permitted.

1. Entry occurred when attackers obtained OAuth tokens associated with the Salesloft Drift integration and used those tokens to access connected Salesforce instances.
2. Escalation followed as the attackers searched those environments for additional credentials, including API keys, passwords, and cloud tokens that could open AWS, Snowflake, Slack, Azure, Google Workspace, and OpenAI.
3. Impact came from turning stolen secrets into broader access across multiple customer environments, forcing large-scale rotation and containment work after trust had already been abused.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Toxic data is the right name for long-lived secrets. Credentials are not inert configuration objects. Once they are copied into tickets, logs, chats, and automation pipelines, they become persistent trust artefacts that can outlive the business purpose that created them. The Salesloft Drift incident shows that the real breach surface is not the application alone but the distributed secret ecosystem around it. Practitioners should treat secret persistence as an exposure problem, not a housekeeping problem.

The broken assumption here is that third-party access remains accountable after issuance. That assumption was designed for a world where integrations were static and centrally visible. It fails when a SaaS connector or AI-linked workflow can reuse delegated access across multiple services and identities without fresh review. The implication is that access governance has to account for where a token can travel, not just who approved it at creation.

Ephemeral credential trust debt: this is the gap that most clearly emerges from the breach pattern. Enterprises keep accumulating durable secrets because each integration is provisioned as if its trust can be managed later. In reality, the later never arrives before the next compromise. The governance lesson is that every new connector increases hidden liability unless the identity model itself changes.

Rotation is containment, not resolution. Large-scale key rotation after a supplier compromise proves that many programmes still rely on reactive hygiene to compensate for permanent trust. That works only until the next token theft, at which point the same operational burden returns. The field should stop describing this as a credential management problem and start describing it as a lifecycle and blast-radius problem.

NHI governance must extend to the places secrets are copied, not just where they are created. Slack, Jira, Confluence, logs, and automation tooling often become secondary stores of authority. When those channels are excluded from governance, the organisation loses visibility into the real trust graph. Practitioners need a policy model that follows secrets across their full lifecycle, because attackers will.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• From our research: 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks, according to The State of Secrets Sprawl 2026.
• If your programme is still focused only on repositories, compare that exposure pattern with the 52 NHI Breaches Analysis to see how often trust breaks in adjacent systems rather than in code.

What this signals

Ephemeral credential governance is now a board-level control concern. The pattern here is not confined to one supplier compromise. As integrations multiply, every persistent token becomes a reusable trust object that can be stolen, copied, and replayed elsewhere. Teams should expect secret discovery to expand beyond repositories into collaboration and ticketing systems, and they should track whether revocation is actually automated.

Toxic data is becoming the correct operating model for secrets management. Once a credential has been copied into multiple systems, its residual risk becomes the real problem. That changes the programme question from 'how do we store secrets safely' to 'how do we prevent secrets from becoming durable in the first place.' The practical shift is toward ephemeral identity, scoped access, and ownership of the full secret lifecycle.

If you are mapping your programme against external guidance, the OWASP Non-Human Identity Top 10 is the right baseline for overprivilege, rotation, and third-party governance. The same logic also aligns with continuous verification principles in the NIST SP 800-63 Digital Identity Guidelines when integrations effectively act as identities.

For practitioners

• Inventory every third-party OAuth grant Build a complete register of integrations, the scopes they hold, and the business owner responsible for each grant. Prioritise connectors that can touch SaaS, cloud, and collaboration platforms from a single token.
• Shorten credential lifetime by design Replace persistent API keys and long-lived OAuth secrets with short-lived identities where the platform supports it. The goal is to make stolen tokens expire before they can be replayed across adjacent services.
• Track secret sprawl outside code Extend discovery to Slack, Jira, Confluence, support tickets, and logs because those are common places where secrets are copied and later reused. Apply the same review and revocation process there as in repositories.
• Tie revocation to supplier incidents Predefine who can revoke third-party credentials immediately when a supplier integration is suspected of compromise. Include downstream account review, not just token revocation, because stolen credentials often outlive the first alert.

Key takeaways

• This incident shows that compromised OAuth tokens can turn a third-party integration into a wide-ranging access path across cloud and SaaS services.
• The scale of the problem is bigger than one breach because long-lived secrets keep surfacing in places where teams do not expect them.
• Programmes that cannot shorten secret lifetime or revoke access quickly are managing exposure, not controlling it.

Key terms

• OAuth token: A token that allows one application to act on behalf of a user or system without reusing the original password. In identity programmes, it is effectively delegated authority with an expiry and scope that must be governed like any other credential.
• Toxic data: Sensitive credentials and secrets that become dangerous simply by existing in too many places for too long. The term captures the reality that copied tokens, keys, and passwords create durable trust surfaces that attackers can later discover and reuse.
• Secret sprawl: The uncontrolled spread of credentials across repositories, logs, tickets, chat tools, and automation systems. It turns a single secret into many exposure points, which makes discovery, revocation, and accountability much harder once a compromise occurs.
• Non-human identity: A machine or software identity such as an API key, token, certificate, service account, workload, or AI agent. These identities need lifecycle governance because they can hold privileges, move between systems, and outlive the business purpose that created them.

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 Defakto Security: Real-World Lessons From OAuth Tokens to API Keys, the toxic data behind the Salesloft Drift and Salesforce breach. Read the original.