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.
At a glance
What this is: This report examines the Salesloft Drift token theft and shows how stolen OAuth tokens and connected support data widened the blast radius across multiple customer environments.
Why it matters: It matters because IAM and NHI teams have to govern delegated SaaS access, token scope and third-party integrations as one control surface, not as separate vendor connections.
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.
Context
OAuth token theft is a governance problem as much as a compromise problem. When a SaaS integration can read support tickets, reuse delegated access, and expose other credentials, the identity boundary moves from the primary application into every connected workflow.
In this case, the security issue is not only the token theft itself but the way connected systems, support content, and API-style access expanded the possible blast radius. For NHI programmes, that means the lifecycle of third-party access has to be governed alongside the data it can reach.
The article indicates that some organisations saw only token exposure while others reported broader internal compromise. That spread is typical of SaaS-to-SaaS and delegated-access incidents, where the same initial path produces different outcomes depending on ticket content, privilege scope, and downstream controls.
Key questions
Q: What breaks when a SaaS integration can read support tickets and delegated credentials?
A: The control boundary breaks first. Support tickets often contain secrets, account details, and operational context that were never meant to be readable through delegated access. Once that access is stolen, attackers can search for reusable credentials and move from one application into broader identity compromise.
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. The risk increases when tokens are long-lived, over-scoped, or shared across integrations. Attackers often prefer this route because it bypasses normal password controls and can remain useful until the token is discovered and revoked.
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. Other red flags are excessive permissions, third-party exposure without controls, and low visibility into where non-human identities exist or how they are used across the stack.
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.
Technical breakdown
How stolen OAuth tokens extend beyond the original SaaS
OAuth tokens are delegated credentials that let one service act on behalf of a user or workload without re-authentication at every step. In an integration-heavy environment, that delegation can reach support portals, CRM records, message histories, and other systems that were never intended to sit inside one trust boundary. Once a token is stolen, the attacker inherits whatever scope and session privileges were already granted, which is why the compromise often looks wider than the initial application. The technical lesson is that the token is only one part of the control plane; the real risk is the set of downstream permissions that token can traverse.
Practical implication: Map every OAuth path to the systems and data it can actually reach, not just to the app where the token was issued.
Why support tickets and integration content become credential exposure points
Support tickets often contain account identifiers, embedded secrets, troubleshooting notes, and snippets of configuration that reveal how an integration is wired together. When a delegated identity can read or export those records, the ticketing system becomes a credential reservoir rather than a neutral helpdesk workflow. In this case, the article shows that attackers could pull text and access tokens from customer support tickets using stolen OAuth access, which turns content handling into an identity-security issue. That is a classic example of secret leakage through operational data, not a pure application vulnerability.
Practical implication: Classify support-ticket content as sensitive identity data and limit which delegated accounts can read, search, or export it.
Why API keys and OAuth tokens need different governance assumptions
An API key is usually a bearer secret with stable access until it is revoked, while an OAuth token is a delegated authorisation artifact with scope, expiry, and refresh behaviour that can be abused in different ways. The article notes that organisations managing their own Drift connections through API keys were told to revoke existing keys immediately, which shows that static credentials and delegated tokens need separate incident handling. If teams treat both as generic secrets, they miss the difference between revocation, rotation, scope reduction, and session invalidation. That distinction matters because the control failure is not just exposure, but unmanaged persistence of access.
Practical implication: Separate API key governance from OAuth token governance so revocation, rotation, and expiry are handled according to credential type.
Threat narrative
Attacker objective: The attackers appear to be harvesting reusable credentials and connected support data to expand compromise across multiple organisations and create leverage for extortion.
- Entry occurred through compromised access tied to the Drift integration rather than through direct compromise of the victim organisations' primary environments.
- Credential access followed when attackers stole OAuth tokens and other access credentials, then used them to reach connected systems and support content.
- Escalation happened as the stolen access was used to search for secrets and additional credentials, increasing the scope of compromise across affected organisations.
- Impact varied from token theft to broader internal-network compromise, depending on what the connected systems exposed.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Secret leakage in support workflows is a lifecycle failure, not an isolated incident. The exposed material in this case was not limited to a single stolen token. It included ticket text and access credentials, which means the organisation had no effective boundary between operational support data and sensitive identity material. That is the same failure mode NHI governance is meant to catch: credentials persisting in places where delegated identities can read them.
OAuth token governance and API key governance must be split operationally. The article shows that some customers were told to revoke API keys while others were affected through OAuth-based access. Those are different credential classes with different control assumptions, different revocation paths, and different blast-radius characteristics. Runtime governance gap: access can be created through one channel and consumed through another, so ownership has to follow the whole delegation chain.
The wider lesson is that integration sprawl creates identity ambiguity. When one service can surface support content, another can search for secrets, and a third can reuse tokens, responsibility for access becomes distributed but never disappears. That is why NHI programmes need a named owner for every third-party credential, every downstream permission set, and every offboarding path. The practitioner conclusion is simple: if you cannot explain who can revoke the credential and what data it can reach, you do not govern it.
From our research library:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
What this signals
Identity blast radius is now the key design metric for SaaS integrations. Teams should stop asking only whether a connection is authenticated and start asking what it can read, export, and reuse. In a delegated-access incident, the credential is just the entry point; the real problem is how far the token can travel before revocation catches up.
Support systems are part of the credential surface. If tickets, notes, and attachments can be searched or exported by third-party access, they need the same governance discipline as secrets stores. That means tighter scoping, stronger content classification, and explicit ownership for offboarding paths.
OAuth token governance now needs relationship mapping, not just rotation cadence. Rotation helps, but it does not answer who can consume the token, which downstream systems it touches, or whether revoked access still leaves historical data exposed. That is the operational gap this incident exposes for identity programmes.
For practitioners
- 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.
- Limit support-system read scope Apply least-privilege access to helpdesk and CRM integrations so a stolen token cannot enumerate or harvest embedded secrets at scale.
- Test third-party offboarding paths Verify that disabling a vendor connection actually removes its ability to read historical records, not just future events.
Key takeaways
- Delegated SaaS access can turn one stolen token into a much larger identity problem when support systems and connected applications share too much data.
- The reported impact ranged from limited token theft to broader internal compromise, which shows how much the outcome depends on scope and content exposure.
- Teams need separate governance for OAuth tokens, API keys, and support-data access if they want to reduce the blast radius of third-party identity compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The incident exposed OAuth tokens and credentials through connected SaaS workflows. |
| NHI-03 — Vulnerable Third-Party NHI | The compromise originated through a third-party integration with broad downstream access. | |
| NHI-05 — Overprivileged NHI | Stolen tokens were able to reach support data and other connected systems beyond the minimum needed scope. | |
| Recommendation — Scan integrated SaaS workflows for exposed tokens and remove secret-bearing content from delegated access paths. Review third-party integrations for excessive reach and revoke any connection that can read more data than it needs. Reduce delegated scopes so stolen NHI credentials cannot traverse support, CRM, and adjacent systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential rotation and revocation are central to limiting reuse after token theft. |
| Recommendation — Apply authenticator management controls to rotate exposed credentials and retire stale access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The attack exploited excessive delegated permissions across connected systems. |
| Recommendation — Tighten permissions and entitlements so delegated access cannot exceed the intended business task. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path involved stealing tokens and using them to move across connected environments. |
| Recommendation — Map token theft and cross-system reuse to TA0006 and TA0008 when prioritising detections and response. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Stolen tokens functioned as authentication material for connected services. |
| Recommendation — Harden API authentication so stolen bearer material cannot be reused without additional context checks. | ||
Key terms
- Authentication Token Theft: Authentication token theft is the unauthorized capture and use of a credential that proves a user, service, or agent has already authenticated. Technically, it includes stealing session cookies, bearer tokens, refresh tokens, or API tokens, then replaying them to bypass login controls and impersonate the original identity until the token expires or is revoked.
- Delegated SaaS access: Delegated SaaS access is permission granted to one application, connector, or service account to act on behalf of another identity or data owner. It is often necessary for automation, but it becomes a governance risk when the grant is broad, stale, or poorly owned.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Support Case Data Leakage: Support case data leakage occurs when sensitive information is exposed through helpdesk tickets, chat transcripts, or case notes. These fields often contain credentials, internal troubleshooting details, and customer data that should not be treated as safe storage. Strong redaction, retention limits, and secret scanning reduce the risk.
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 IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 14, 2026.
Updated on October 13, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org