TL;DR: The Salesloft Drift incident showed how stolen OAuth tokens tied to a third-party chatbot integration could be used to query SaaS APIs at scale, with multiple organisations reporting CRM data exfiltration before tokens were revoked, according to Britive. The lesson is that long-lived, over-scoped OAuth access turns NHI governance into a blast-radius problem, not just a secrets problem.
Editorial analysis by NHI Mgmt Group, based on content published by Britive: “Lessons Learned from the Salesloft Drift Incident”.
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 stolen OAuth tokens create such a large blast radius in SaaS environments?
A: Because the token often carries delegated access to multiple objects, actions, and downstream APIs, so one compromise can reach far beyond the initial integration.
A: Look for integrations that access data continuously when the business use case only needs occasional access, or that touch multiple users’ files, calendars, or mailboxes far beyond expected workflow limits.
Practitioner guidance
- Audit third-party OAuth scopes Inventory connected apps, identify overly broad object and action scopes, and remove access that is not explicitly tied to a live business need.
- Shorten token lifetime and revocation paths Replace long-lived refreshable access with runtime-scoped permissions, short TTLs, and immediate revocation workflows for integrations that no longer need access.
- Treat integrations as governed identities Assign ownership, purpose, and lifecycle management to each chatbot or SaaS integration so access reviews can target a named identity rather than a generic app.
Bottom line: The incident shows how a stolen OAuth token can function as delegated trust, turning a third-party integration into an access path for CRM data.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Stolen OAuth tokens are not just secrets, they are delegated trust artifacts. Once a third-party integration token is stolen, the attacker does not need to defeat the normal login flow. The incident shows that permission scope, token lifetime, and integration ownership matter as much as secrecy, because the token is already inside the trust boundary. Practitioners should therefore manage connected apps as governed identities, not as technical afterthoughts.
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.
- The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
A question worth separating out:
Q: How should organisations govern AI-powered OAuth apps?
A: Organisations should treat AI-powered OAuth apps as higher-uncertainty delegated actors because the model can decide when to act, not just what data to touch. That means stricter logging, narrower scopes, shorter review cycles, and explicit owner accountability for every high-risk action path such as sending mail or editing files.
👉 Read our full editorial: Salesloft Drift and the identity risk of stolen OAuth tokens