Salesloft Drift breach exposes the limits of SaaS trust

At a glance

What this is: This is an analysis of the Salesloft Drift supply chain breach and how stolen OAuth tokens enabled Salesforce data theft through a trusted third-party integration.

Why it matters: It matters because SaaS access, delegated OAuth trust, and token lifecycle governance increasingly shape identity risk across human, NHI, and machine-to-machine programmes.

By the numbers:

• Salesloft Drift was linked to a coordinated campaign that ran between August 8 and August 18, 2025.
• Attackers attempted access to publicly exposed AWS credentials within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today.

👉 Read AccuKnox's analysis of the Salesloft Drift supply chain breach

Context

Salesforce integration risk is not just a SaaS security problem, it is an identity governance problem. When a third-party application is granted OAuth access, the enterprise is trusting delegated credentials and the offboarding, revocation, and scope controls that should constrain them.

The Salesloft Drift breach shows how quickly that trust can be abused once OAuth tokens are compromised. For IAM and PAM teams, the intersection is clear: a token is a non-human identity in practice, and if its lifecycle is not tightly controlled, the blast radius extends into customer data, internal records, and downstream systems.

Key questions

Q: What breaks when third-party OAuth integrations are over-scoped?

A: Over-scoped integrations turn delegated access into an attacker-controlled session with too much reach. The failure is not only data exposure, but also the ability to query records, harvest secrets, and pivot into adjacent systems without triggering interactive-login defenses. Teams should treat app consent as a privileged access decision and review it as tightly as they review admin access.

Q: Why do SaaS supply chain breaches often lead to credential theft?

A: Because the first compromise usually exposes more than records. Attackers search trusted SaaS data for passwords, API keys, and cloud tokens, then use those secrets to widen access. The breach becomes a credential discovery problem as much as a data exposure problem.

Q: What do security teams get wrong about OAuth refresh tokens?

A: They often assume a refresh token will keep working after scopes change or that it will be reissued automatically. In practice, Google’s refresh-token behaviour depends on consent timing, app status, and scope class. Teams should test lifecycle edge cases, especially when a feature moves from development to production.

Q: Who is accountable when a SaaS integration exposes customer data?

A: Accountability sits with the organisation that owns the delegated access path, even if the token originated from a third-party service. Security, application, and SaaS owners all need a defined revocation process and an incident playbook. If the integration can reach customer data, it must be governed like any other privileged identity.

Technical breakdown

How OAuth token compromise becomes a trusted access path

OAuth tokens let an application act on behalf of a user or service without re-entering primary credentials. That delegation is useful, but it also means the token becomes the real bearer of trust. If attackers steal the token, they inherit whatever scope was granted, often without tripping normal authentication controls. In SaaS ecosystems, this is especially dangerous because the token can bypass many of the checks teams assume are protecting the session. The problem is not OAuth itself, but weak governance over granted access, scope, and token revocation.

Practical implication: inventory and constrain every delegated OAuth grant as if it were a privileged credential.

Why credential harvesting follows SaaS integration breaches

Once inside a SaaS environment, attackers often search for more than the initial data set. Credential harvesting means scanning records, messages, or attachments for reusable secrets such as API keys, passwords, and cloud tokens. This turns one compromised integration into a launch point for broader compromise. The article’s focus on AWS keys and authentication passwords matches a common escalation pattern in supply chain incidents, where attackers use the first foothold to find the next one. Data access and credential discovery reinforce each other.

Practical implication: treat SaaS content as a secrets exposure surface, not just a business records repository.

How runtime visibility limits blast radius after token abuse

Preventing every integration compromise is unrealistic, so the next control layer is runtime detection. Behavioural monitoring looks for unusual query volume, unexpected data access patterns, or atypical process behaviour after a token is used. In a Salesforce context, repeated count queries followed by bulk extraction are strong indicators of abuse. Zero Trust architecture helps only when it is enforced with context-aware policy and monitoring, not as a slogan. Without runtime signals, teams discover the problem only after records leave the platform.

Practical implication: pair delegated-access governance with anomaly detection that can spot token abuse in SaaS workloads.

Threat narrative

Attacker objective: The attacker objective was to harvest additional credentials and exfiltrate valuable Salesforce data through a trusted third-party access path.

1. Entry occurred through a compromised OAuth token associated with the Salesloft Drift integration, giving attackers trusted access into Salesforce-connected environments.
2. Escalation followed as the attackers searched the exposed data for reusable secrets, including AWS access keys and authentication passwords, turning application access into credential harvesting.
3. Impact was data theft across multiple organisations, with sensitive Salesforce records exposed and the trust relationship between SaaS applications and enterprise identities broken.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Klue OAuth Supply Chain Breach — OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.

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

NHI Mgmt Group analysis

Trusted SaaS integrations have become NHI governance assets, not just application connectors. When an OAuth token can act with broad delegated authority, it behaves like a non-human identity and should be governed with the same lifecycle discipline as any other privileged credential. This is where IAM and NHI governance converge most sharply. Practitioner conclusion: treat third-party app grants as managed identities with explicit scope, expiry, and revocation controls.

Credential harvesting is the real objective in many SaaS supply chain breaches. The immediate stolen data is often less important than the secrets buried inside it. That means defensive focus must extend beyond data classification to secret discovery, token revocation, and downstream cloud access containment. Practitioner conclusion: assume that SaaS compromise is a potential cloud compromise until proven otherwise.

Zero Trust fails when it stops at network segmentation and does not reach delegated identity. Context-aware policy is only effective if the enterprise can enforce least privilege on OAuth scopes, service tokens, and application-to-application trust paths. The breach shows that perimeter thinking still survives inside modern SaaS estates. Practitioner conclusion: extend Zero Trust into integration governance, not just infrastructure controls.

OAuth sprawl is the new privilege sprawl, and it deserves a named control model. Delegated trust drift is the accumulation of stale, over-scoped, or poorly monitored third-party grants that outlive the business need that created them. Once that drift exists, revocation becomes reactive instead of preventive. Practitioner conclusion: build governance for delegated trust the same way mature programmes govern privileged access.

This breach reinforces that machine and human identity programmes can no longer be separated in practice. The compromised integration was not a person, but the blast radius reached human-owned business data and cloud secrets. That makes cross-domain governance mandatory, especially where SaaS integrations feed IAM, PAM, or cloud workflows. Practitioner conclusion: unify identity telemetry so token abuse, privilege misuse, and third-party access are reviewed together.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• Read 52 NHI Breaches Analysis for additional breach patterns that show how credential exposure turns into downstream access risk.

What this signals

Delegated trust drift is now a programme-level issue for IAM and cloud security teams. If third-party OAuth grants are not owned, reviewed, and revoked like privileged credentials, the organisation accumulates invisible access paths that outlive their business purpose. Teams should align integration inventory with access review, token expiry, and service owner accountability, using NIST SP 800-207 Zero Trust Architecture as the policy lens.

The practical signal is that SaaS incidents will increasingly be investigated as identity incidents, not just data incidents. That means security operations need a fast path from anomalous SaaS behaviour to token revocation, secret rotation, and downstream cloud validation. The strongest control programmes will connect SaaS telemetry to IAM, PAM, and cloud response in one workflow.

This breach also reinforces a useful analytical concept: delegated trust drift describes the gap between the access a third-party integration was approved for and the access it still retains today. When drift accumulates, the organisation loses confidence that any single grant reflects current need. The answer is continuous ownership, not periodic memory of who connected what.

For practitioners

• Map every third-party OAuth grant Identify all SaaS integrations with delegated access, then document scopes, owners, expiry, and revocation path. Prioritise applications that can read mail, CRM data, files, or secrets-bearing records.
• Shorten token lifetime and enforce offboarding Remove standing OAuth grants that do not have a current business need, and make revocation part of application offboarding rather than incident response. Tie this to access review cadence and contract renewal.
• Scan SaaS content for embedded secrets Search records, attachments, tickets, and messages for API keys, passwords, and cloud tokens, then route findings into secret rotation workflows instead of simple alerting.
• Add runtime detections for bulk SaaS extraction Alert on repeated count queries, unusual export volume, or access from atypical locations and processes. Feed those signals into investigation playbooks that include token revocation and downstream credential checks.
• Review cloud and IAM fallout together When a SaaS integration is compromised, verify whether exposed records included AWS keys, passwords, or service credentials, then reset dependent credentials and review all downstream trust chains.

Key takeaways

• The breach shows that trusted SaaS integrations can become credential harvesting paths when OAuth grants are not tightly governed.
• The scale of the problem is amplified by secret persistence, because leaked credentials often remain exploitable long after the first disclosure.
• The control gap is delegated trust lifecycle management, which must include scope review, revocation, and runtime detection of abusive access patterns.

Key terms

• Delegation Drift: Delegation drift is the gradual accumulation of excessive or outdated access in groups, roles, and admin pathways. It weakens governance because identity state changes faster than teams review it, creating privilege escalation paths that are easy to miss during normal operations.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.
• 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.
• Zero Trust: A security model that assumes no identity — human or non-human — should be trusted by default, even inside a network perimeter. Every access request must be verified, authorised, and continuously validated.

What's in the full article

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

• A step-by-step breakdown of how the Salesloft Drift compromise unfolded across Salesforce-connected environments.
• Specific control examples for ASPM, secret scanning, and runtime policy enforcement in CNAPP workflows.
• Illustrative prevention patterns for exposed AWS keys, token abuse, and process-based network controls.
• Vendor examples of how Zero Trust policies map to multi-cloud enforcement and admission control.

👉 AccuKnox's full post covers the attack chain, token abuse, and Zero Trust control mapping in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps practitioners connect identity governance to practical controls across cloud, SaaS, and privileged access.