Topic starter
25/06/2026 12:56 am
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.
Editorial analysis by NHI Mgmt Group, based on content published by Defakto Security: “From OAuth Tokens to API Keys: The Toxic Data Behind the Salesloft Drift / Salesforce Breach”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: The incident shows that SaaS integrations can turn delegated access into an enterprise-wide trust problem when credentials are reusable and persistent.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 5 days ago by NHI Mgmt Group
25/06/2026 10:02 am
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.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
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.
👉 Read our full editorial: Salesloft Drift token theft exposes the toxic data model in SaaS
This post was modified 5 days ago by NHI Mgmt Group