Salesloft Drift and the identity risk of stolen OAuth tokens

At a glance

What this is: This analysis says the Salesloft Drift incident turned stolen OAuth tokens into a scalable SaaS access problem, not just a token theft problem.

Why it matters: It matters because IAM teams now have to govern third-party OAuth access, standing permissions, and runtime revocation across NHI and agentic integrations.

Context

The central governance gap is simple: OAuth tokens can outlive the trust decision that created them. In third-party chatbot and SaaS integrations, that creates a permissions problem when access remains active even after the operational need has changed, especially across CRM and other high-value systems.

Salesloft Drift showed how quickly that gap becomes visible in practice. Once stolen tokens were used against SaaS APIs, normal traffic and malicious use became hard to distinguish, which is why NHI governance has to treat integration identity, scope, and revocation as first-class control points.

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 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. The risk increases when the token is refreshable or tied to always-on automation. Blast radius depends on scope breadth, not just token presence.

Q: What are the signs that an OAuth integration is being overused or behaving outside its intended purpose?

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. A useful signal is the gap between declared purpose and observed activity in logs. If an app is synchronizing broad content or making repeated high-value API calls, its real risk is higher than its stated function.

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.

Technical breakdown

How stolen OAuth tokens become trusted API access

OAuth tokens are bearer credentials, so possession often matters more than the original authentication event. In SaaS and chatbot integrations, a stolen token can inherit the permissions granted to the connected app, letting an attacker operate through normal API pathways without needing the user’s password. That is why over-broad scopes and long-lived refreshability are dangerous together: the token becomes a reusable access path, not a one-time proof. In this incident pattern, the control failure is not authentication alone but the combination of delegated trust, standing access, and weak revocation discipline.

Practical implication: treat every OAuth-connected app as a governed identity with scope review and revocation authority.

Why API traffic can hide token abuse

When attacker activity is executed through valid OAuth credentials, the requests often look like legitimate integration traffic. That collapses many detection assumptions because the protocol, source service, and API patterns can all appear normal while the intent is malicious. Bulk exports, unusual object access, and atypical user-agent or origin signals become more useful than simple login failures. This is one reason third-party SaaS integrations create a unique identity blind spot: the abuse happens inside an authorised channel, not at the perimeter.

Practical implication: monitor connected-app behaviour, not just authentication events, and alert on bulk or atypical API access.

Why standing privilege makes chatbot integrations high risk

Always-on access for AI-powered or automated integrations creates standing privilege that persists even when the task does not. In practice, that means a chatbot or agent can keep calling APIs without a fresh human decision, which expands the blast radius if tokens are stolen or misused. The governance problem is not that automation exists, but that the identity continues to hold access after its immediate need has passed. ZSP and just-in-time authorization are relevant here because they reduce how long the token remains usable.

Practical implication: replace always-on integration access with runtime-scoped permissions and enforced revocation at task completion.

Threat narrative

Attacker objective: The objective was to use delegated SaaS access to exfiltrate CRM data while blending into legitimate integration traffic.

1. Entry occurred when OAuth tokens tied to a third-party chatbot integration were stolen.
2. Credential abuse followed as the stolen tokens were used to query SaaS APIs at scale through legitimate channels.
3. Impact emerged as multiple organizations reported CRM data exfiltration before the tokens were revoked.

Breaches seen in the wild

• 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.
• GitHub OAuth token breach 2022: Stolen Heroku and Travis CI OAuth tokens let an attacker clone private repos from dozens of orgs, including npm, and reuse an AWS key found in them.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group 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.

Ephemeral credential trust debt is the real failure mode here. The article exposes how long-lived, refreshable OAuth access creates a debt between the original approval decision and the actual risk at use time. That debt accumulates across SaaS, chatbot, and agentic workflows, where access is retained “just in case” rather than because a live task still needs it. The practitioner implication is to treat token lifetime as a governance variable, not a convenience setting.

Standing privilege in AI-powered integrations expands blast radius faster than human IAM review cycles can react. Access review processes assume privileges persist long enough to be reviewed and certified, but autonomous and semi-autonomous integrations can consume and reuse access in ways that outpace those cycles. Even when the integration is not fully autonomous, the security model still depends on runtime controls, ownership, and constrained scopes. The lesson is that the access model must change before the review model can catch up.

Salesloft Drift is a supply-chain identity incident, not a single-vendor token event. The risky condition is the web of third-party apps, delegated scopes, and downstream SaaS endpoints that turn one compromised integration into broad data exposure. That pattern aligns with OWASP-NHI secret leakage and third-party NHI risk, but the important point is structural: trust extended farther than visibility and control did. Practitioners should map where delegated access crosses organisational boundaries and where revocation authority actually lives.

Blast radius is the new control metric for OAuth governance. Traditional access management asks whether a token works; the better question here is how far it can reach before it is stopped. In this case, the answer depended on scope breadth, token persistence, and whether the connected app had meaningful runtime constraints. Identity teams should measure blast radius by object reach, data sensitivity, and revocation speed, not by token count alone.

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.
• The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

The pattern here is not limited to one incident. SaaS ecosystems now depend on delegated access across chatbots, automation platforms, and connected apps, so teams need to measure where a token can reach before they measure how often it rotates.

Delegated access perimeter: when a third-party integration becomes the trust boundary, governance has to move from account-centric review to scope-centric control. That shift matters because access reviews alone do not tell you whether a token can still reach sensitive CRM objects after the original use case has ended.

NHI teams should also assume that a stolen token may pass through normal telemetry unless connected-app behaviour is actively monitored. The practical next step is to align revocation authority, logging, and runtime authorization so blast radius is constrained before data moves.

For practitioners

• 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.
• Monitor connected-app behaviour Look for bulk exports, atypical origins, unusual user agents, and API patterns that indicate a stolen token is being used through a trusted channel.
• Constrain AI and automation access by task Require just-in-time authorization, on-behalf-of boundaries, and tool allowlists so automated workflows cannot keep operating beyond the approved task.

Key takeaways

• 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.
• The risk is amplified by over-broad scopes, long-lived tokens, and always-on automation, which together widen the blast radius of a compromise.
• Teams should govern connected apps as identities, narrow their scopes, and move sensitive integrations toward runtime-scoped access with fast revocation.

Key terms

• Delegated Trust Artifact: A delegated trust artifact is a credential or token that represents an already-approved access relationship rather than a fresh authentication event. In NHI governance, it must be managed as an identity asset because its security value comes from the permissions attached to it, not from the original login that created it.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Standing Privilege: Standing privilege is access that remains active even when no immediate task requires it. For NHI programmes, it is a common failure mode because long-lived credentials and persistent roles create unnecessary exposure. Reducing standing privilege usually means tighter expiry, on-demand access, and clearer review of who or what still needs access.
• Connected App Telemetry: Connected app telemetry is the behavioural data generated by a SaaS integration, including API calls, source origins, user agents, and object access patterns. It helps security teams distinguish normal delegated automation from token abuse when authentication itself still looks valid.

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.