TL;DR: Attackers used stolen OAuth tokens from the Salesloft Drift integration to access Salesforce customer instances and hunt for credentials across connected services, including AWS, Snowflake, Slack, Azure, Google Workspace, and OpenAI, according to Defakto Security. The incident shows that long-lived secrets act as toxic data and that rotation alone cannot repair the broken trust model behind non-human identity governance.
At a glance
What this is: This analysis argues that the Salesloft Drift compromise exposed how OAuth tokens and other long-lived secrets become toxic data across connected SaaS environments.
Why it matters: It matters because IAM and NHI teams have to treat third-party integrations, token sprawl, and downstream credential discovery as one governance problem, not separate fixes.
Context
Salesloft Drift token theft is a SaaS trust-model problem, not a simple application breach. A third-party integration issued OAuth tokens, those tokens were stolen, and the resulting access reached customer environments through trusted connections rather than direct exploitation of the target.
For NHI governance, the issue is that integrations, automation, and AI-connected services often inherit durable access that survives far beyond the original business need. Once those credentials exist, they can be reused to hunt for other secrets across SaaS, cloud, and collaboration platforms.
This is a typical failure pattern in modern SaaS estates: trust is granted at connection time, but containment is expected later through rotation, monitoring, and cleanup. The model is already too late by then.
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 compromised integration tokens create such a large blast radius?
A: They usually sit inside trusted workflows that can touch more than one system, so one stolen token can expose the original SaaS app and then lead attackers to additional secrets in cloud, chat, or automation environments. That turns a single credential loss into an ecosystem-wide identity problem.
Q: What are the signs that secret sprawl is creating hidden exposure?
A: Look for credentials appearing in support tickets, logs, chat threads, automation pipelines, and vendor connectors, especially when those secrets can reach production systems. If the same class of credential is reused across multiple services, your exposure is already larger than the original application boundary.
Q: How should teams decide between rotation and short-lived identity for integrations?
A: Use rotation as a containment step, not as the design goal. If an integration depends on permanent secrets to keep working, the safer choice is to move to short-lived, scoped identity so the credential cannot outlive the task it was created for. That changes the trust model instead of just refreshing it.
Technical breakdown
Why stolen OAuth tokens become ecosystem access
OAuth tokens are delegated credentials, so whoever holds them can act within the scopes already granted to the integration. When a third-party app sits inside a SaaS trust boundary, the token often becomes a bridge into customer data, adjacent APIs, and downstream services. That bridge is especially dangerous when the token can be replayed outside the original session context and when the integration itself has broad read or write scopes. In this incident pattern, attackers do not need to break authentication again once the token is in hand. They simply use the trust already issued by the environment.
Practical implication: review every integration token as an access path, not a convenience credential.
How credential hunting spreads after initial access
Once attackers land in a trusted SaaS workspace, they usually pivot to whatever will open more doors. That means API keys, passwords, OAuth refresh tokens, and cloud credentials stored in tickets, logs, chat threads, and configuration records. The point is not just data theft. It is compound identity abuse, where one stolen credential reveals another, and each newly found secret expands the blast radius. This is why SaaS incidents so often become multi-platform exposure events instead of staying contained to the original app.
Practical implication: map where secrets can be discovered after a single integration compromise and remove those storage paths.
Why long-lived secrets create toxic data
A long-lived secret is harmful because its security value decays while its usability persists. The longer an OAuth token, API key, or cloud credential remains valid, the more opportunity exists for interception, resale, or abuse. Rotation helps only after exposure is known, but it does not change the fact that the credential existed, persisted, and could be reused. In NHI governance terms, this is toxic data: information that should not remain valuable after creation but does because the operating model depends on permanence.
Practical implication: replace durable secrets with short-lived, context-bound identities wherever the integration pattern allows it.
Threat narrative
Attacker objective: The objective was to collect credentials that unlocked broader access across connected SaaS and cloud services, not merely to view one application’s data.
- Entry occurred through stolen OAuth tokens issued to the Salesloft Drift integration, giving attackers trusted access into Salesforce-connected environments.
- Credential harvesting followed as the attackers searched those environments for API keys, passwords, cloud tokens, and other reusable secrets.
- Escalation happened when the stolen secrets were used to expand access across services including AWS, Snowflake, Slack, Azure, Google Workspace, and OpenAI.
- Impact was broader ecosystem compromise and forced rotation activity across customer estates, with some Workspace accounts confirmed accessed through the integration.
Breaches seen in the wild
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Credential permanence is the real control failure: This breach worked because the ecosystem assumed a token would remain safe long enough to be managed after issuance. That assumption fails when the credential itself is the attack payload and the integration boundary is already trusted. The implication is that governance has to move away from protecting permanent secrets and toward minimizing their existence in the first place.
Toxic data is a better model than secret sprawl: OAuth tokens, API keys, and passwords do not behave like normal configuration data once they are embedded across SaaS, support, and automation workflows. They persist, propagate, and outlive the business purpose that created them. Practitioners should treat every durable secret as a future incident surface, not just an access mechanism.
Third-party NHI trust is now a supply-chain control problem: The article shows that a compromised integration can expose downstream identities even when the primary target was not directly breached. That moves this issue out of simple application security and into NHI governance, vendor trust, and lifecycle offboarding. The practitioner conclusion is that third-party access must be governed as continuously revocable exposure, not static permission.
Rotation alone cannot repair inherited trust: Frequent key rotation can narrow exposure after a disclosure, but it does not resolve the underlying dependency on long-lived credentials. The model still leaves organisations managing stockpiles of secrets that are discoverable, reusable, and chained across services. The field needs short-lived identity design, not better bookkeeping for permanent tokens.
Short-lived identity is the structural alternative: When access is ephemeral and scoped to a specific action, the window for token theft collapses. That does not remove the need for monitoring, but it changes the governance question from how to recover after exposure to how to stop creating reusable trust assets. Practitioners should redesign integrations so standing credentials are the exception, not the default.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Secret sprawl now behaves like inherited attack surface: Once a third-party connector can expose tokens, the governance problem is no longer limited to the source application. The reader should assume every durable credential can be discovered again through logs, chat, tickets, and automation paths unless those storage points are actively removed.
The better control objective is not faster rotation alone but less reusable trust. That means designing SaaS integrations so credentials expire before they can be harvested and ensuring that third-party access is revocable at the same speed it was granted.
For practitioners
- Inventory integration-issued OAuth tokens Identify every third-party app, bot, and connector that can mint or store OAuth tokens, then classify which ones can reach production SaaS, cloud, or collaboration systems.
- Eliminate long-lived reusable secrets Replace static API keys, passwords, and refresh tokens with short-lived credentials wherever the platform supports scoped, time-bound access.
- Harden secret discovery paths Remove credentials from tickets, logs, chat exports, and automation artifacts so a single compromised connector cannot reveal a second layer of access.
- Tighten third-party offboarding Revoke dormant connectors, unused app grants, and inherited access promptly when a vendor relationship, integration, or workflow changes.
Key takeaways
- The incident shows that SaaS integrations can turn delegated access into an enterprise-wide trust problem when credentials are reusable and persistent.
- Its significance is the chain reaction, one stolen token can lead to multiple downstream services, creating a much larger exposure surface than the original integration.
- The practical answer is to reduce standing secret value through short-lived identity, strict offboarding, and removal of hidden secret storage paths.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CSA Cloud Controls Matrix set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Stolen OAuth tokens and downstream secret exposure are the core failure mode in this article. |
| NHI-03 — Vulnerable Third-Party NHI | The compromise originated in a third-party integration that had trusted access to customer environments. | |
| NHI-07 — Long-Lived Secrets | The article argues that durable OAuth tokens and API keys are the toxic asset behind the breach pattern. | |
| Recommendation — Map exposed tokens to NHI-02 and remove every storage path that lets one secret reveal another. Apply NHI-03 to review vendor-integrated identities and revoke access that outlives the business relationship. Treat long-lived secrets as NHI-07 exposure and replace them with short-lived credentials wherever possible. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The incident is fundamentally about delegated access that remained too broad and too durable. |
| Recommendation — Apply PR.AA-05 to minimize integration entitlements and enforce revocation when access is no longer needed. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attackers harvested credentials and then moved through connected services, matching this tactic chain. |
| Recommendation — Map the incident to TA0006 and TA0008 to hunt for credential theft followed by cross-service movement. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud IAM governance is central because the breach abused delegated identities across SaaS and cloud services. |
| Recommendation — Use IAM controls to inventory and constrain cross-service delegation and third-party access. | ||
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.
- Toxic data: Sensitive credentials and secrets that become dangerous simply by existing in too many places for too long. The term captures the reality that copied tokens, keys, and passwords create durable trust surfaces that attackers can later discover and reuse.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Third-Party NHI: Third-Party NHI is a non-human identity owned or operated by an external organization, partner, contractor, or supplier. It includes service accounts, API keys, certificates, tokens, and automated agents that access systems outside the primary enterprise boundary. Governance must cover issuance, scope, monitoring, revocation, and contractual accountability.
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 June 24, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org