Salesloft Drift and the identity risk of stolen OAuth tokens

At a glance

What this is: This is an analysis of the Salesloft Drift incident and its key finding: compromised OAuth tokens can act like legitimate identities across SaaS APIs.

Why it matters: It matters because IAM teams must treat third-party integrations and AI workflows as governed non-human identities with scoped, revocable access.

👉 Read Britive's analysis of the Salesloft Drift incident and OAuth token risk

Context

OAuth tokens are often treated as convenient plumbing, but in practice they can become durable identity artifacts with broad API reach. When a third-party integration holds standing permission, the real control point is not login, it is how scopes, lifetime, and revocation are governed across the non-human identity lifecycle. Salesloft Drift is a clear example of why AI-connected SaaS integrations now belong in the NHI risk register.

The incident fits a pattern security teams already see in secrets sprawl, over-permissioned tokens, and standing access for automation. That is typical of environments where integrations grow faster than access review, ownership, and telemetry. The governance gap is not unique to one vendor or one chatbot, which is why the wider lessons generalise well beyond this case.

Key questions

Q: How should security teams govern OAuth tokens for AI-powered integrations?

A: Treat them as non-human identities with explicit owners, narrow scopes, short lifetimes, and a defined revocation path. The goal is to prevent a stolen token from becoming a standing enterprise credential. Governance should cover issue, use, rotation, monitoring, and retirement, not just initial authentication.

Q: When does OAuth access create more risk than it reduces?

A: OAuth creates more risk when the integration is over-scoped, long-lived, or always on, because a stolen token can behave like legitimate automation. In those cases, convenience outweighs control. The tipping point is usually when one token can read or export many records without task-specific limits.

Q: What is the difference between token revocation and least privilege?

A: Revocation removes current access, while least privilege limits what the identity can do before anything goes wrong. Both are necessary. Revocation handles incident response, but least privilege reduces the blast radius that an attacker can exploit if a token is stolen or abused.

Q: Why do AI-connected SaaS integrations need NHI controls?

A: Because they operate as software identities with real authority, often holding API access that can read, write, or export business data. If they are unmanaged, they become shadow AI and shadow NHI at the same time. Control them like any other privileged machine identity, with ownership and lifecycle review.

Technical breakdown

Why stolen OAuth tokens behave like trusted identities

OAuth access tokens inherit the scopes and trust boundaries of the connected application. If an attacker steals the token, API requests are usually indistinguishable from legitimate automation because the request carries valid authorization, not a broken password prompt. That makes OAuth compromise an identity and authorization problem, not just a credential theft problem. Long-lived refreshable tokens deepen the issue because they extend the period in which a compromised integration can keep acting. In NHI terms, the token becomes a standing access vehicle unless the organisation actively constrains scope, lifetime, and revocation.

Practical implication: Treat every OAuth-connected integration as a governed NHI with explicit ownership, expiry, and revocation paths.

Over-broad scopes and standing privileges widen blast radius

The risk is amplified when integrations receive blanket object access or broad action permissions. In that model, a token does not need to be especially powerful to be dangerous because the scope already authorises bulk reads, exports, or administrative actions. Standing privilege means the access exists before any task is requested, which defeats just-in-time intent. For AI agents and chatbots, that is especially problematic because their execution can be continuous, opaque, and difficult to distinguish from human activity. The correct technical framing is blast-radius reduction through least privilege, short lifetime, and task-scoped authorization.

Practical implication: Reduce token scope to the minimum objects and actions, then remove always-on access wherever possible.

Telemetry must distinguish normal automation from abuse

When token abuse occurs, detection depends on recognising deviations in volume, origin, timing, and connected-app behaviour. Bulk exports, unusual user-agent strings, and atypical API call patterns can indicate misuse even when authentication appears valid. The challenge is that modern SaaS activity logs often show the app identity, not the human or agent behind the action, so attribution can be weak unless ownership and delegation are recorded. This is why runtime authorization and centralized identity telemetry matter together. Without both, teams may see the exfiltration only after the token has already been used at scale.

Practical implication: Instrument SaaS integrations with behavioural logging and revoke suspicious tokens before investigation stalls.

Threat narrative

Attacker objective: The attacker’s objective was to use trusted integration access to pull SaaS data at scale while blending in with legitimate API traffic.

1. Entry occurred when a third-party chatbot integration's OAuth token was stolen and reused against SaaS APIs with valid authorization.
2. Escalation followed through over-broad scopes and refreshable access, allowing the attacker to query CRM objects at scale without triggering obvious authentication failures.
3. Impact was data exfiltration from CRM objects before tokens were revoked and investigations completed.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

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

NHI Mgmt Group analysis

OAuth compromise is now an NHI governance problem, not a niche app risk. The central lesson from this incident is that token theft matters because the token is already an identity with authority. Once an integration is granted standing access, traditional account-centric controls lose much of their value. Practitioners should therefore model third-party integrations as first-class non-human identities and govern them accordingly.

Standing privilege remains the easiest path to silent SaaS abuse. The incident reinforces a simple point: if access is always on, an attacker only needs one successful token theft to inherit it. That makes scope reduction, TTL enforcement, and on-behalf-of boundaries more important than perimeter assumptions. Teams should regard always-on automation as an avoidable design choice, not an operational requirement.

Blast-radius control is the right named concept for this class of failure. When a token can query many objects and actions, the security question becomes how much damage one compromised identity can do before revocation. That is the blast-radius problem in NHI security, and it is directly shaped by scope, lifetime, telemetry, and ownership. Security teams should measure and reduce blast radius before they optimise convenience.

Identity and permissions must be reviewed together. The article is right to frame this as more than token hygiene, because revocation alone does not fix over-authorisation. If the same integration is reissued with the same broad scopes, the risk returns immediately. Organisations need review processes that check who owns the integration, what it can do, and how quickly it can be shut down.

AI-connected SaaS tooling will keep exposing weak governance first. The more organisations let chatbots and workflow automations act inside business systems, the more they need policy, lifecycle control, and observability that were built for machine identities. That is not a future-state problem. Practitioners should treat this as a current governance baseline.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• Only 44% of organisations have implemented any policies to manage their AI agents, even though 92% agree that governing AI agents is critical to enterprise security.
• For a broader identity lens, the 52 NHI Breaches Analysis maps recurring patterns in token abuse, overprivilege, and delayed revocation.

What this signals

Ephemeral authentication does not help if the entitlement model is still standing. The strategic shift for practitioners is from token handling to identity governance, because compromise inherits whatever access was already granted. With 19% of organisations giving AI systems dramatically more access than human employees, per the 2026 Infrastructure Identity Survey, overpermissioned automation is already an enterprise norm rather than an edge case.

Blast-radius thinking should now sit inside access review and incident response. Teams need to know which integrations can touch the most sensitive data, how quickly those tokens can be revoked, and who can approve emergency shutdown. The governance pattern aligns closely with the OWASP Non-Human Identity Top 10, especially the controls around overprivilege and lifecycle management.

For practitioners

• Inventory all OAuth-connected integrations Create a register of every third-party chatbot, SaaS connector, and automation that can query business systems. Record owner, purpose, scopes, token type, refresh behaviour, and revocation path so reviews can target the real NHI surface area.
• Right-size scopes to task boundaries Replace blanket object access with the smallest set of objects and actions required for each integration. Remove standing access where the workflow can be authorized at runtime and avoid persistent privileges that outlive the task.
• Enforce token revocation playbooks Define how security operations will revoke stale or suspicious tokens, confirm downstream access removal, and preserve evidence for investigation. The playbook should be tested against both human and agent-driven workflows, not only standard user accounts.
• Monitor for bulk and anomalous API patterns Tune detection for unusual export volume, unexpected connected-app activity, unfamiliar user-agent strings, and origin shifts. Log enough context to distinguish valid automation from abuse, especially when the integration identity is the only visible actor.
• Apply runtime authorization to AI workflows Require just-in-time approval or short-lived authorization for high-risk actions taken by AI agents and chatbots. Tie those permissions to ownership and expiry so access is removed automatically when the workflow ends.

Key takeaways

• Stolen OAuth tokens are dangerous because they can inherit legitimate API authority and blend in with normal automation.
• Over-broad scopes, refreshable tokens, and standing privilege are the structural weaknesses that turn one compromise into a SaaS data event.
• IAM teams should govern integrations as non-human identities, with ownership, least privilege, runtime controls, and fast revocation.

Key terms

• OAuth Token: An OAuth token is a bearer credential that lets an application call APIs on behalf of a user or service. In NHI governance, the token matters because it can carry real authority, often across SaaS systems, and must be treated as a revocable identity artifact rather than a convenience string.
• Standing Privilege: Standing privilege is access that exists continuously before any specific task is requested. For non-human identities, it creates unnecessary exposure because compromise can be used immediately. Security teams reduce this risk by scoping access narrowly and replacing persistent permissions with time-bound authorization.
• Blast Radius: Blast radius is the amount of damage a compromised identity can do before it is contained. In NHI environments, it is shaped by scope, lifetime, delegation, and revocation speed. Smaller blast radius means fewer systems, records, and actions are exposed if an integration is abused.
• Shadow AI: Shadow AI is an AI system or agent operating without formal governance, ownership, or inventory coverage. It becomes a security issue when it can access business tools through hidden tokens or unmanaged integrations, leaving IAM teams unable to review, restrict, or revoke its authority.

Deepen your knowledge

OAuth token governance and runtime authorization for AI workflows are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for SaaS integrations and agentic automation, it is worth exploring.

This post draws on content published by Britive covering the Salesloft Drift incident: Lessons Learned from the Salesloft Drift Incident. Read the original.