Topic starter
14/07/2026 6:07 pm
TL;DR: About 700 Salesloft Drift customers are confirmed to have had OAuth tokens or other access credentials stolen, while Google said a very small amount of Workspace tokens were taken and multiple cybersecurity firms reported downstream compromise, according to Swarmnetics. The incident shows how delegated access, support-ticket content, and integration sprawl can turn one exposed NHI path into broader identity risk.
Editorial analysis by NHI Mgmt Group, based on content published by Swarmnetics: “Salesloft Drift Hack Leads to Rash of Compromised OAuth Tokens; Cybersecurity Companies Victimized”.
By the numbers:
- About 700 Salesloft Drift customers are confirmed to have had OAuth tokens or other access credentials stolen.
- The exact total number of Drift clients is not public, but it is thought to be at least 5,000 based on prior Salesloft marketing statements.
Key questions
Q: What breaks when a SaaS integration can read support tickets and delegated credentials?
A: The control boundary breaks first.
Q: Why do stolen OAuth tokens create such a broad access risk in third-party integrations?
A: OAuth tokens can act like delegated login credentials across multiple services, so one stolen token may open access to private data in several connected systems.
Q: What are the signs that NHI governance is failing in an enterprise?
A: Common warning signs include unclear ownership for service accounts, secrets stored in code or configuration instead of managed vaults, infrequent rotation, and weak offboarding of API keys.
Practitioner guidance
- Map delegated SaaS access paths Inventory every Drift-style integration, then record which support queues, CRM objects, and downstream systems each delegated credential can reach.
- Separate support data from identity secrets Tag tickets, notes, and attachments that may contain access tokens or credentials, and restrict delegated accounts from broad search or export rights.
- Revoke and rotate by credential type Treat OAuth tokens, refresh tokens, and API keys as different revocation problems so incident response matches the credential class.
Bottom line: Delegated SaaS access can turn one stolen token into a much larger identity problem when support systems and connected applications share too much data.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
14/07/2026 6:12 pm
Delegated SaaS access is now an NHI control plane, not a convenience layer. When a third-party integration can read customer support content and reuse delegated access across multiple systems, the identity boundary is no longer the primary application. The governance problem is that teams often inventory the app but not the reachable data, so they miss the true blast radius. Practitioners should treat connected SaaS access as part of NHI governance, not as a peripheral integration concern.
A few things that frame the scale:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
A question worth separating out:
Q: Should organisations treat API keys and OAuth tokens the same way?
A: No. API keys are usually static bearer secrets that require direct revocation, while OAuth tokens are delegated authorisations with scope and refresh behaviour. Teams need separate inventory, rotation, and incident response paths for each so that one control model does not hide the other.
👉 Read our full editorial: Salesloft Drift token theft exposes wider NHI governance gaps