Salesloft Drift token theft exposes wider NHI governance gaps

At a glance

What this is: A token-theft incident affecting Salesloft Drift users showed how stolen OAuth credentials and ticket data can cascade into broader compromise across connected systems.

Why it matters: It matters because IAM teams must govern third-party OAuth paths, API keys, and support-tool integrations as live identity dependencies, not just application connections.

By the numbers:

• Thus far about 700 Salesloft Drift customers are confirmed to have had OAuth tokens or some other access credential stolen in the attack.
• The exact total number of Drift clients is not made public, but thought to be at least 5,000 based on prior Salesloft marketing statements.

👉 Read Swarmnetics' analysis of the Salesloft Drift OAuth token theft

Context

Salesloft Drift token theft is an NHI governance problem because delegated access tokens can be abused long after the original integration was approved. When support workflows, CRM connectors, and customer tickets sit behind OAuth, the blast radius is defined by every connected account and every secret embedded in those workflows.

The primary lesson is that third-party access is only as safe as the weakest token, ticket, or API key in the chain. In this case, the issue is not just compromise of one product instance but the exposure of identity material that can be replayed across multiple enterprise systems.

Key questions

Q: What breaks when OAuth tokens are compromised in connected SaaS environments?

A: When OAuth tokens are compromised, attackers can inherit delegated access without defeating passwords or MFA. In connected SaaS environments, that access can spread into multiple applications, cached data sets, and embedded records. The failure is not only token theft, but the assumption that one app boundary contains the blast radius. That assumption rarely holds once integrations are chained.

Q: Why do OAuth-connected support tools create elevated NHI risk?

A: They concentrate operational secrets in places designed for troubleshooting, not identity governance. If attackers gain token-based access, they can search tickets and notes for API keys, session data, and internal references that widen the blast radius. That is why ticketing systems must be treated as part of the NHI estate.

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 third-party integration exposes corporate secrets?

A: Accountability is shared, but the enterprise owns the governance failure if it allowed the integration to persist without review. Frameworks such as the OWASP Non-Human Identity Top 10 and Zero Trust Architecture both point to the same expectation: access paths must be continuously verified, bounded, and removable.

Technical breakdown

How OAuth token theft becomes enterprise access

OAuth tokens are delegated credentials, not passwords, and they often inherit broad access to SaaS data, support records, or downstream APIs. Once stolen, the token can be replayed until it is revoked or expires, which makes the usable window far more important than the original theft method. In support and CRM tools, tokens can expose customer metadata, internal notes, and pasted secrets that were never meant to leave the workflow. That turns one compromised integration into an identity problem across multiple systems.

Practical implication: inventory every Drift-connected OAuth path and treat token revocation as incident containment, not routine hygiene.

Why support tickets become credential reservoirs

Support platforms often accumulate secrets because users paste API keys, logs, screenshots, and recovery details into tickets to speed troubleshooting. If an attacker gains access through a delegated token, they are not only reading case notes. They are also searching for embedded credentials that can be used to pivot into cloud consoles, internal tools, and customer environments. This is a classic NHI exposure pattern: secrets placed in operational workflows without lifecycle controls, retention boundaries, or least-privilege scoping.

Practical implication: classify support-ticket content as sensitive identity material and apply redaction, retention, and secret-detection controls.

Why integration sprawl increases the blast radius

The more systems that connect through one SaaS integration, the more a single token compromise can spread. OAuth apps, API keys, and vendor-managed connections create a shared trust layer that is easy to forget until it fails. In this case, the reported impact differs by organisation because each environment exposed different data, permissions, and downstream links. That variation is the point: the integration itself is the control plane, and every unchecked dependency expands the attack surface.

Practical implication: map all third-party integrations to their downstream permissions and remove unused connections before they become lateral paths.

Threat narrative

Attacker objective: The attacker objective appears to be credential harvesting and downstream access that can support extortion, follow-on intrusion, or resale of secrets.

1. Entry occurred through compromise of Salesloft Drift OAuth tokens or related credentials associated with connected customer environments.
2. Escalation followed when attackers searched compromised accounts for secrets and additional credentials embedded in support content and linked systems.
3. Impact depended on the victim environment, with some organisations reporting access to support tickets, internal data, or further compromise of connected systems.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

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

NHI Mgmt Group analysis

Stolen OAuth tokens create identity blast radius, not isolated application risk. Once a delegated credential is compromised, the attacker inherits whatever trust the integration already carried. That means the real exposure is often the downstream SaaS, support, and customer-data surface attached to the token, not the integration brand itself. Practitioners should read this as a governance problem in shared trust paths, not a single-vendor incident.

Support workflows have become a hidden NHI repository. Tickets, pasted logs, and troubleshooting notes routinely contain secrets, access tokens, and recovery details. That makes support tooling part of the identity estate, with lifecycle and classification requirements that many programmes still do not apply. The practical conclusion is straightforward: if support can hold secrets, it must be governed like an NHI control surface.

Third-party OAuth visibility is the control gap this incident exposes. The article reinforces a broader pattern: organisations often approve integrations without maintaining continuous inventory of what those integrations can reach. According to our research, 85% of organisations lack full visibility into third-party vendors connected via OAuth apps. That makes incident response slower and privilege containment harder because teams do not know the full dependency graph.

Credential exposure windows are now measured in minutes, not days. The article’s incident pattern aligns with a larger NHI reality: once a secret is exposed, attackers move quickly to replay it and enumerate what else it can open. The key governance mistake is assuming delegated access is safe because it was approved once. Practitioners should treat every long-lived token as a standing privilege path until proven otherwise.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Our research also found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes delegated access hard to govern at scale.
• For a broader NHI threat baseline, see 52 NHI Breaches Analysis for recurring compromise patterns and control failures.

What this signals

Third-party OAuth governance is becoming a continuous assurance problem. The Drift incident shows that periodic approvals are not enough when delegated access can be abused outside the original review window. Teams need live ownership, scoped revocation, and integration inventory that stays current as vendors, workflows, and tickets change.

Support desks now sit inside the identity perimeter. Any workflow that stores API keys, tokens, or recovery details should be treated as part of the NHI control surface, with OWASP Non-Human Identity Top 10 used to stress-test secret exposure, privilege scope, and lifecycle management.

With 85% of organisations lacking full visibility into OAuth-connected vendors, the practical signal is that integration sprawl is outpacing governance. That should push programmes toward tighter offboarding, better token telemetry, and explicit risk acceptance for every external app.

For practitioners

• Revoke and reissue all Drift-connected credentials Treat every OAuth token, API key, and vendor-managed connection tied to Drift as potentially exposed. Revoke existing credentials, confirm new tokens are bound to least-privilege scopes, and validate that no stale integration remains active in connected SaaS tools.
• Search support systems for embedded secrets Scan customer tickets, attachments, chat transcripts, and troubleshooting notes for API keys, bearer tokens, and recovery data. Redact or quarantine records that contain secrets, then define retention and access rules so support content does not remain a credential reservoir.
• Map downstream access from each OAuth app Build a full inventory of what each third-party OAuth app can reach, including Salesforce, support consoles, internal admin tools, and data export paths. Remove obsolete integrations and require reapproval for any app that can touch credentials or customer records.
• Add secret detection to operational workflows Extend secret scanning into service desk, CRM, and collaboration platforms so pasted credentials are detected before they are stored or shared. Pair that with alerting on unusual token use, especially when a support workflow suddenly touches authentication material.

Key takeaways

• Stolen OAuth tokens turn a single integration into a multi-system identity problem because delegated access can be replayed until it is revoked.
• The incident also shows that support tickets and troubleshooting notes can become secret reservoirs, which expands compromise beyond the original SaaS connector.
• Organisations that cannot inventory and govern third-party OAuth paths will keep discovering that their real blast radius sits in the connections, not the application they thought they approved.

Key terms

• Delegated Access Token: A delegated access token is a short-lived credential issued for a specific task on behalf of an identity. In agentic environments, it limits what the runtime can do, where it can go, and how long the authority lasts, which is essential when access must be brokered rather than carried.
• OAuth App Visibility: OAuth app visibility is the ability to see which third-party applications have been granted delegated access to internal systems and data. It is a core control for modern SaaS governance because hidden app connections can persist long after the original user or vendor relationship changes.
• Support Ticket Secret Exposure: Support ticket secret exposure occurs when API keys, tokens, or recovery data are stored in service desk content that later becomes accessible to attackers. It turns operational helpdesk data into sensitive identity material that must be classified, scanned, and retained carefully.

What's in the full analysis

Swarmnetics' full research covers the operational detail this post intentionally leaves for the source:

• The article breaks down which organisations reported token theft versus broader internal compromise.
• It outlines the suspected use of stolen OAuth tokens to search support tickets for secrets and access material.
• It describes the reported impact differences across vendors such as Cloudflare, Palo Alto Networks, Zscaler, Proofpoint, SpyCloud, Tanium, and Tenable.
• It summarises the open questions around the attacker, the Breachstars ransom site, and the investigation timeline.

👉 Swarmnetics' full post covers the attack scope, affected vendors, and reported secret-hunting behaviour.

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.