Salesloft OAuth token theft exposes the master key problem

At a glance

What this is: This is an analysis of the Salesloft breach and the wider token-theft pattern it exposed, showing how stolen OAuth tokens turned trusted integrations into direct access paths across Salesforce-connected environments.

Why it matters: It matters because IAM and NHI teams have to govern delegated access, token lifetime, and connected app trust as a live attack surface, not a static integration detail.

By the numbers:

• The number of organizations hit by UNC6395 is more than 700 worldwide.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.

👉 Read Illumio's analysis of the Salesloft OAuth token breach and trust-path compromise

Context

OAuth token theft is a delegated-access problem, not a simple password problem. In this breach pattern, the attacker does not need to defeat MFA or reset a human login. The token already carries the trust needed to act as the integration, which makes the access path structurally different from ordinary account compromise.

For IAM, PAM, and NHI programmes, that changes the control question. The issue is no longer only who signed in. It is which connected apps can act on behalf of a business process, how long that trust persists, and whether those tokens are still valid after the relationship or tool changes. That is why token governance belongs in the core identity model, not in an integration exception queue.

Illumio’s article is a typical example of a modern enterprise trust-chain breach. The starting point is not unusual anymore: one compromised integration can expose a much larger environment than the original system suggests.

Key questions

Q: What breaks when a stolen OAuth token is used against a trusted integration?

A: The trust model breaks because the system still sees a valid credential, even though the actor behind it is no longer trustworthy. In practice, stolen delegated access can bypass interactive authentication and continue until revocation or expiry, which is why connected app tokens need ownership, monitoring, and fast containment.

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 connected app governance?

A: Teams often treat connected apps as convenience features instead of identity-bearing systems. That leads to weak inventory, broad scopes, and missing revocation ownership. Governance has to cover the whole token lifecycle, including issuance, review, rotation, and offboarding, or the organisation cannot tell which integrations still have legitimate authority.

Q: Who is accountable when a SaaS integration token is stolen?

A: Accountability should be shared, but operational ownership must be explicit. The business owner, identity team, and vendor all have different responsibilities, yet someone inside the enterprise must own review, rotation, and revocation. Without a named owner, the credential becomes a governance orphan and attackers benefit from the gap.

Technical breakdown

OAuth tokens as delegated identity, not passwords

OAuth tokens represent authorisation already granted to an application, which is why they can survive beyond the original user session. In practice, the token becomes the identity for API calls, and the target system evaluates the request as coming from a trusted integration. That is useful for interoperability, but it also means compromise of the token bypasses the usual human-facing controls that teams depend on for sign-in events. Once issued, the token can expose data, invoke APIs, and chain into other linked systems if scopes and trust relationships are broad enough.

Practical implication: Treat OAuth tokens as first-class credentials with lifecycle, scope, and revocation requirements.

Trusted integrations can become lateral movement paths

In a connected stack, a compromised integration is not contained by the boundary of one SaaS platform. The attacker can pivot from the initial system into downstream tools that share credentials, tokens, or sync pathways. This is a lateral movement pattern built on legitimate pathways, which makes it harder to distinguish from normal business traffic. In the Salesloft case, the trusted connection between systems gave the attacker a path into Salesforce and then potentially into additional environments where secrets were stored or referenced.

Practical implication: Map application-to-application trust chains and classify them by blast radius, not by owner team.

Why API activity is harder to detect than malware

API abuse is quiet because the traffic often uses valid authentication and expected endpoints. Query patterns can look operational rather than malicious, especially when the attacker mimics regular SOQL or bulk-export behaviour. This shifts detection away from signature-based tooling and toward behavioural baselining, anomaly detection, and token-specific context. If an organisation does not know which integrations are active, which scopes they hold, or whether they are still needed, the monitoring problem becomes much harder because there is no reliable baseline to compare against.

Practical implication: Instrument token usage, connected-app activity, and abnormal query volume together in detection logic.

Threat narrative

Attacker objective: The attacker objective is to use trusted integration access to steal business data, harvest additional secrets, and create reusable leverage for extortion or further compromise.

1. Entry occurred when attackers compromised the Salesloft-Drift integration and gained trusted token-based access into connected Salesforce environments.
2. Escalation followed as stolen OAuth tokens were used to query data through legitimate API channels and move into linked environments where additional secrets were present.
3. Impact came from exfiltrated Salesforce records and recovered credentials that could be reused for follow-on access and extortion.

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

Delegated access is now a primary identity attack surface. OAuth tokens, connected apps, and integration scopes are no longer background plumbing. They are the credentials that let software act with authority, which means their compromise has the same governance seriousness as a stolen privileged account. The practitioner conclusion is simple: if a system can act on behalf of the business, it needs identity lifecycle controls that match that authority.

Blast radius, not initial compromise, is the decisive control variable. The article shows how one stolen token can fan out across CRM data, linked apps, and stored secrets. That pattern fits OWASP-NHI and NIST CSF thinking because the real question is not whether access exists, but how far that access can move before it is contained. The practitioner conclusion is to govern trust chains by maximum reachable impact.

Long-lived token trust debt is the named concept this breach sharpens. Long-lived token trust debt is the accumulation of access that outlasts the business relationship, the integration owner, or the original security review. That debt was designed for stable, human-monitored integrations. It fails when tokens survive silently for months or years and remain valid after the environment has changed. The practitioner conclusion is to treat unused, old, and unowned tokens as governance defects, not administrative leftovers.

Visibility is necessary but insufficient without decisive containment. The article correctly points to behavioural signals, but the deeper issue is that many organisations still cannot enumerate all active integrations or map their effective trust relationships. That means detection often arrives after exposure has already spread. The practitioner conclusion is that identity governance and runtime containment must be aligned, not operated as separate programmes.

Token compromise collapses the distinction between identity and infrastructure control. Once credentials can open cloud tools, storage, and SaaS systems, the old perimeter model no longer describes the attack path accurately. Access control, secret handling, and network containment become one combined risk surface. The practitioner conclusion is to align IAM, NHI governance, and containment policy around shared business workflows rather than isolated platforms.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to The 2024 ESG Report: Managing Non-Human Identities.
• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, which shows governance blind spots persist even where security teams think coverage exists.
• For a broader breach lens, see The 52 NHI breaches Report, which turns recurring token and credential failures into a repeatable control pattern.

What this signals

With 72% of organisations already suspecting or confirming NHI breach exposure, the Salesloft pattern is not an edge case but a warning about how mature enterprise trust chains now behave in practice. The programme implication is that token inventory, ownership, and revocation need board-level attention alongside privileged access and cloud posture controls.

Long-lived token trust debt: this is the governance gap created when credentials continue to function after the business context that justified them has changed. That debt grows quietly in SaaS integrations, and it only becomes visible when an attacker uses the old trust path to move laterally or exfiltrate data. Programmes that do not inventory it will keep underestimating blast radius.

The next step for practitioners is to connect identity governance with runtime containment so stolen delegated access can be isolated before it fans out. NHI programmes that stop at inventory and policy will miss the operational half of the problem, which is where breach impact is actually reduced.

For practitioners

• Audit every connected app and integration Build a current inventory of all Salesforce-connected apps, third-party sync paths, and service-to-service tokens. Remove unknown or unused connections, and require a named owner for every integration so there is a revocation path when business context changes.
• Rotate and revoke tokens on a lifecycle schedule Set expiry, rotation, and revocation rules for OAuth tokens, API keys, and other secrets tied to business integrations. Do not allow tokens to persist indefinitely because the original employee or vendor relationship still exists.
• Constrain scopes to the smallest workable trust domain Limit each token to the minimum permissions needed for its task, then separate read, export, and administration scopes so one compromised credential cannot unlock broad data movement or downstream secret discovery.
• Detect abnormal API behaviour as identity abuse Monitor for unusual query volume, bulk exports, new source locations, and token usage patterns that do not match the baseline for each connected app. Alerting should be tied to the specific token and integration, not just the user or host.
• Contain trusted-path compromise with segmentation If a token is stolen, isolate the integration path quickly so the attacker cannot pivot into other linked systems. Use environment segmentation and policy-based containment to reduce the number of systems reachable from one compromised credential.

Key takeaways

• This breach shows that delegated access credentials can become the same kind of high-value asset as a privileged account, because the token itself carries the authority.
• The scale signal is already broad, with more than 700 organisations hit by the UNC6395 campaign and stolen records now being reused for extortion.
• The control that changes the outcome is not just detection but token lifecycle governance, scope minimisation, and rapid revocation of trusted integrations.

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.
• Connected App: A connected app is a third-party integration that is granted access to a SaaS platform through APIs and OAuth permissions. From a governance perspective, it is an identity-bearing access path that needs ownership, scoping, and periodic review like any other non-human identity.
• Session Trust Debt: The accumulated risk created when an active session remains trusted after the conditions that supported it have changed. It is a practical way to describe stale access, especially in environments with long-lived credentials and automated workflows.
• Blast Radius: Blast radius is the amount of data, systems, and business process a compromised credential can reach before containment. For NHI and integration security, it is the practical measure of how much damage one stolen token, key, or certificate can cause across connected environments.

What's in the full article

Illumio's full article covers the operational detail this post intentionally leaves for the source:

• The step-by-step account of how the Salesloft-Drift trust path was compromised and how the tokens were used downstream.
• The specific indicators Illumio highlights for detecting abnormal API activity and token misuse across connected systems.
• The detailed containment ideas for shrinking blast radius after a trusted integration has already been abused.
• The vendor's explanation of how visibility tools help map system-to-system communication in real environments.

👉 Illumio's full post adds the breach chain, exposure scope, and containment guidance for token theft scenarios.

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.