Salesloft Drift token abuse expands the NHI governance gap

At a glance

What this is: This is an analysis of how the Salesloft Drift OAuth token theft campaign is continuing to expose downstream Salesforce data through compromised third-party access.

Why it matters: It matters because IAM and NHI programmes must govern delegated OAuth access, integration scope, and revocation speed, not just passwords and user sessions.

By the numbers:

• 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 Anomali's Cyber Watch coverage of the Salesloft Drift breach and related threats

Context

OAuth tokens create delegated access that often looks less urgent than a password leak, but they can be just as useful to an attacker once they are stolen. In the Salesloft Drift campaign, the problem is not only token theft but the fact that downstream organisations may not immediately see which integrations were touched, what scope was inherited, or how long the exposure persisted. This is a non-human identity problem because the compromised access belongs to an integration, not a person.

For IAM and NHI teams, the central issue is lifecycle control across third-party access. If token revocation, scope review, and API log analysis are not tightly governed, the attack surface persists after the original compromise is discovered. That makes OAuth integrations part of the identity perimeter, even when they are owned outside the enterprise.

The case is typical of modern supply-chain identity abuse: once a token is valid, attackers do not need to defeat primary authentication again. The real challenge is seeing delegated access fast enough to contain it before customer data is exposed.

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 OAuth-based NHI attacks complicate incident response?

A: Because the access path is distributed across multiple services, owners, and logs. A stolen token may touch Salesforce, a connected app, and upstream identity records, which slows scoping and containment. Response teams need correlation across the identity provider, SaaS audit logs, and the integration owner to determine how far the access went.

Q: How do teams know whether OAuth token governance is actually working?

A: Look for short token lifetimes, tested revocation, no tokens in logs, and a clean mapping from each integration to an accountable owner. If disconnected apps still retain access, or if nobody can explain which scopes are approved, the programme is functioning on paper only.

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

OAuth tokens as silent delegated access

OAuth tokens are bearer credentials, which means possession is usually enough to use them until they expire or are revoked. Unlike passwords, they often travel through integrations, automation workflows, and connected applications with little user visibility. In a campaign like this, attackers do not need to crack identity proofing again. They inherit authorised API access and operate inside the trust established by the original consent or application grant. That is why OAuth abuse is a governance problem as much as a compromise problem: the token itself becomes the security boundary, and that boundary is often weakly monitored.

Practical implication: Treat OAuth grants as managed credentials with explicit scope, review, and revocation controls.

Third-party integrations expand the identity perimeter

Salesforce exposure through Drift shows how modern identity boundaries extend beyond the core directory. A third-party app can become a proxy for access into customer records, support data, and other sensitive systems. When the integration is compromised, defenders must reason about inherited privilege, API scope, and downstream data access rather than only the app itself. This is where NHI governance matters: service principals, OAuth clients, and integration tokens need the same lifecycle discipline that teams apply to privileged human access, especially when the data path crosses organisations.

Practical implication: Map every external integration to the data and APIs it can reach, then constrain that reach to the minimum required.

Why token theft is harder to detect than password theft

Token abuse is operationally quiet. There may be no interactive login prompt, no MFA challenge, and no obvious user-initiated event to correlate. Attackers can query APIs, pull case records, and move through trusted app pathways while blending into normal machine traffic. That makes alerting, investigation, and scoping slower than in typical account-takeover cases. The article’s emphasis on reviewing API logs is well founded because API activity is often the only reliable source of evidence once the token is in circulation.

Practical implication: Build detection around API behaviour, unusual app access, and token lifetime rather than around interactive sign-in events.

Threat narrative

Attacker objective: The objective was to use compromised delegated access to harvest customer and support data from trusted SaaS environments.

1. Entry via stolen OAuth tokens from the Salesloft Drift supply-chain compromise gave attackers access to connected Salesforce environments without needing fresh user credentials.
2. Escalation occurred through trusted third-party integration scope, allowing the actors to query support data and reach records that sat behind delegated app access.
3. Impact was the exfiltration of customer support information, including names, business emails, phone numbers, and case details, across multiple organisations.

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 OAuth access is now a first-class NHI risk: The Salesloft Drift campaign shows that machine-to-machine trust can fail without any password theft or MFA bypass. Once a token is issued, the attacker operates inside a pre-authorised access path that many IAM teams still treat as lower priority than human accounts. The practical conclusion is that OAuth grants must be governed as live credentials, not static app settings.

Identity blast radius is determined by integration scope, not just compromise source: A single stolen token can expose multiple downstream tenants if the connected app is widely trusted. That makes the identity perimeter larger than the directory and more dynamic than conventional access reviews assume. Practitioners should recognise that delegated access expands blast radius in ways traditional account-centric models miss.

Third-party access without lifecycle offboarding creates persistence by design: The campaign demonstrates that revoking the obvious token is not enough if related integrations, logs, and inherited grants remain active. The governance failure is not only exposure, but delayed offboarding of the integration relationship itself. Security teams need to treat vendor-connected access as an owned identity lifecycle, not a one-time approval.

Standing privilege review is too slow for bearer-token abuse: OAuth tokens can be used before a scheduled review cycle ever reaches them. That means recertification alone cannot protect delegated SaaS access unless it is paired with event-driven revocation and API-level monitoring. IAM programmes that still rely on periodic review will continue to discover abuse after the data has left.

Ephemeral credential trust debt: The campaign illustrates how short-lived or delegated credentials create a false sense of safety when their monitoring, revocation, and scope controls are weak. The issue is not token lifetime alone, but the organisational debt created when teams trust integrations faster than they can validate them. Practitioners should treat every new OAuth trust as accumulated exposure until proven otherwise.

From our research:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories and are 13% more likely to be categorised as critical than code-based leaks.
• For a broader view of breach patterns, see 52 NHI Breaches Analysis for how identity failures propagate across access chains.

What this signals

Ephemeral credential trust debt: Teams should expect delegated access to keep expanding faster than manual governance can track it. With AI-related credential leaks surging 81.5% year-over-year in 2025, the problem is no longer isolated to source control or a single app tier. Programmes that do not inventory and review integration access continuously will keep inheriting hidden exposure.

The practical signal for IAM and NHI teams is that OAuth governance now belongs in the same operational queue as privileged access and offboarding. Use OWASP Non-Human Identity Top 10 to anchor scope, rotation, and revocation decisions, then align them with SaaS audit logging and vendor retirement processes. The faster the trust relationship changes, the more automation you need around it.

For practitioners building the next control layer, focus on the identity perimeter rather than the application label. A connected app can function like a privileged service account, and once that analogy is accepted, the right controls become clearer: ownership, scope, review cadence, and incident-triggered revocation. That is the governance shift this campaign reinforces.

For practitioners

• Audit all third-party OAuth grants Inventory every connected app, map the APIs and data sets it can reach, and identify which grants can read customer, support, or administrative records. Prioritise integrations with broad scopes or unclear ownership.
• Revoke and rotate on a live incident timeline When token theft is suspected, revoke related OAuth credentials immediately, then review adjacent integrations that share the same tenant, consent path, or service owner. Do not stop at the first revoked token.
• Log and alert on API behaviour, not just sign-ins Create detections for unusual app-to-API patterns, atypical request volume, and access from integrations that rarely touch the affected records. API logs are often the only evidence of delegated abuse.
• Tighten integration scope before deployment Require least-privilege scopes for every new SaaS integration and block broad read access by default. Review whether a connected app truly needs case history, contact data, or export permissions before approval.
• Align third-party access to lifecycle offboarding Add vendor termination and app retirement checks to access reviews so inactive integrations do not survive contract changes, ownership shifts, or tool migrations. Treat third-party OAuth access as part of the offboarding workflow.

Key takeaways

• OAuth token abuse turns delegated SaaS access into a non-human identity risk that can bypass traditional login controls.
• The campaign shows how quickly token theft can become customer-data exposure when integration scope and revocation are weak.
• IAM teams need lifecycle governance for third-party access, not just periodic review of human accounts and passwords.

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.
• 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.
• Integration Scope: Integration scope is the permission boundary granted to a connector or automated workflow. It defines what the integration can read, modify or trigger across systems. When scopes are too broad, the connector becomes a privileged pathway that must be governed like any other high-risk access relationship.
• Token Revocation: Token revocation is the ability to invalidate a credential before its natural expiry when it is exposed, misused, or no longer needed. For JWTs and other NHI credentials, revocation closes the gap between detection and continued access, which is essential when a stolen token can otherwise remain usable.

What's in the full analysis

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

• The specific incident timeline across Salesloft, Qualys, and Tenable, including what each organisation confirmed and when.
• The full analyst commentary on why OAuth token abuse makes victim identification slower than password-based compromise.
• The incident-response details around integration shutdowns, token revocation, and partner investigation steps.
• The broader Anomali watchlist context covering related phishing and malware activity from the same period.

👉 Anomali's full post includes the breach updates, analyst commentary, and related campaign context.

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 building or maturing an identity security programme, it is worth exploring.