TL;DR: Stolen OAuth tokens from the Salesloft Drift app let an attacker log into hundreds of Salesforce tenants, enumerate data, export records with Bulk API 2.0, and delete jobs to obscure the trail, according to CYATA and corroborating incident reporting. Token trust, not endpoint compromise, was the failure mode, and that changes how teams should govern connected apps and agent identities.
At a glance
What this is: This is an analysis of OAuth token abuse in the Salesloft Drift incident, where stolen tokens enabled Salesforce tenant access, large-scale data extraction, and trail deletion.
Why it matters: It matters because IAM and SaaS governance teams have to treat connected apps, refresh tokens, and agent identities as first-class access paths, not trusted background plumbing.
Context
OAuth token abuse is a delegated-access failure, not a password compromise. In this incident, stolen tokens for the Salesloft Drift connected app were reused to enter customer Salesforce tenants and pull data at scale, which means the trust boundary sat in the token lifecycle rather than at the user login layer.
For IAM, PAM, and SaaS governance teams, the key issue is how much authority a connected app inherits once its OAuth tokens are minted. When refreshable, broad-scope tokens are treated as routine integration artefacts, the app can become a durable access path that survives normal user controls and hides in expected API traffic.
Key questions
Q: What breaks when a connected app token is stolen?
A: When a connected app token is stolen, the attacker authenticates as the app rather than as a person, so MFA and user login checks often never trigger. The result is app-level access to data and APIs that can look legitimate in logs. The right response is to revoke the token, trace dependent grants, and treat the token as the real identity boundary.
Q: When does OAuth create more risk than it reduces in SaaS environments?
A: OAuth becomes high risk when scopes are broad, tokens are long-lived, and the organization cannot see how the credential is reused across connected apps. At that point, convenience outweighs control, and a stolen token can preserve trusted access without repeated authentication.
Q: What are the signs that a SaaS-to-SaaS integration has been compromised?
A: Look for unusual query volume, bulk data exports, unexpected changes to integration behavior, and access from unfamiliar infrastructure. In a Salesforce-linked incident, suspicious activity often shows up in API logs as repeated query bursts rather than interactive logins. Because trusted integrations blend into routine operations, anomaly detection has to focus on access patterns, not just failed authentication events.
Q: What should teams do when cloud tokens or integrations are suspected to be compromised?
A: Revoke the token or integration immediately, then trace what systems it could reach and what data it could access. Rotate related secrets, disable unnecessary scopes, and validate backups or keys were not altered. Treat the token as a compromised identity, not a simple configuration issue.
Technical breakdown
How stolen OAuth tokens become a trusted API session
OAuth bearer tokens work because possession is enough. If an attacker has a valid access token, the resource server treats the caller as the connected app or delegated principal until the token expires or is revoked. Refresh tokens extend that trust window by minting new access tokens without reauthentication. In SaaS integrations, this can bypass MFA, because MFA protects interactive login, not every downstream API call. Once the app identity is trusted, monitoring often sees normal-looking client behaviour rather than obvious account takeover.
Practical implication: teams need to govern token issuance and revocation as a core access-control process, not a housekeeping task.
Why Salesforce data extraction stayed hidden in normal API traffic
The attack did not need exotic exploitation. The actor used ordinary Salesforce object discovery, SELECT COUNT() queries, and Bulk API 2.0 exports to enumerate and extract data at scale. Those operations are legitimate application behaviours, which is exactly why they blend into baseline noise when an integration is already expected to query records. Deleting the Bulk job afterwards removed an obvious artefact, but the underlying issue was that the connected app had enough scope to make the traffic look routine.
Practical implication: API and event logs must be correlated with token issuance and connected-app baselines, or bulk export abuse will look like normal integration activity.
Why connected-app trust is a governance problem, not just a detection problem
The central failure is that organisations often govern human sessions more tightly than delegated machine sessions. A connected app with broad scopes, long-lived refresh capability, and weak behavioural baselining can act like a persistent privileged identity across many tenants. In NHI terms, this is not just token theft. It is the reuse of a trusted non-human identity whose authority outlives the operator, the session, and often the original business context.
Practical implication: connected-app authority should be scoped, time-bounded, and offboarded with the same discipline used for privileged human access.
Threat narrative
Attacker objective: The attacker aimed to harvest tenant data from trusted SaaS integrations while keeping the activity within ordinary API-looking traffic and reducing the chance of detection.
- Entry occurred through stolen OAuth tokens associated with the Salesloft Drift connected app, allowing the actor to authenticate without breaking into a user endpoint.
- Credential abuse followed as the actor reused valid bearer and refresh tokens from attacker infrastructure to query Salesforce tenants and access Google Workspace mailboxes where Drift Email had been connected.
- Escalation happened through normal Salesforce API behaviour, including object enumeration, SELECT COUNT() calls, and Bulk API 2.0 exports of large datasets.
- Impact included data exposure at scale and deliberate job deletion to obscure evidence, with public disclosures later confirming affected organisations and token rotation across platforms.
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.
- Gainsight Salesforce breach 2025: Stolen OAuth tokens for Gainsight's Salesforce app, some eight years old, were used against customer orgs; Google saw 200+ instances at risk.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Connected-app trust is now a primary attack surface: OAuth tokens can turn a SaaS integration into a durable access path that outlives the login event that created it. This incident shows that the real control failure sits in token governance, scope design, and revocation discipline, not in endpoint hardening. The practitioner conclusion is simple: if an integration can act like a user, it must be governed like a privileged identity.
Agentic identity blind spots create the modern blast radius: organisations still treat integrations as plumbing, even when those integrations authenticate, query, export, and automate across systems. That mindset lets bearer and refresh tokens inherit trust without matching oversight, which is why the same connected app can access Salesforce, Google Workspace, and other SaaS surfaces. The implication is that inventory, ownership, and behavioural baselining for non-human identities are now operational necessities.
Token lifecycle is the control plane for SaaS identity security: the attack succeeded because valid tokens were reusable, broad enough to be useful, and hard to distinguish from legitimate integration traffic. That combination invalidates any governance model that assumes access reviews alone will catch misuse after the fact. The practitioner conclusion is that issuance, rotation, revocation, and telemetry correlation have to be managed as one lifecycle.
Least privilege for integrations must be measured by observable behaviour, not declared scope: this campaign used ordinary queries and Bulk API exports, which means the app’s authority was broader than many teams would accept if they looked at actual usage. A connected app that can enumerate, count, and export records at scale has already crossed from convenience into control risk. The practitioner conclusion is to align effective authority with real workload behaviour, not just the permission checkbox.
Ephemeral access assumptions break when refreshable tokens behave like standing privilege: refreshable OAuth authority was designed for continuity, but in this case continuity became persistence for an attacker. The assumption that delegated access is naturally short-lived fails when a stolen refresh token can keep reissuing usable access tokens. The practitioner conclusion is that SaaS programmes need to rethink what “temporary” means for machine-held credentials.
From our research library:
- The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
What this signals
Connected-app governance is now inseparable from IAM: teams that still separate user authentication from SaaS delegation are missing the real control point. The practical shift is to baseline every integration as an identity with its own issuance, scope, and offboarding lifecycle, then monitor it the way you would a privileged workforce account.
OAuth token abuse turns ordinary API activity into an access-control problem, not an anomaly-detection problem. If the organisation cannot explain why an app is allowed to count, enumerate, and export records at scale, then the permission model is already wider than the business need.
Token lifecycle control is the new boundary for SaaS governance: when connected apps can authenticate across multiple services, revocation and rotation become the first line of containment rather than the last. That means offboarding, secret hygiene, and behavioural baselines need to be designed for non-human identities, not borrowed from human IAM without adjustment.
For practitioners
- Inventory every connected app as a governed identity Record the owner, purpose, scopes, tenant locations, and token type for each integration, including SaaS-to-SaaS connections and mailbox-linked automations.
- Shorten refresh token and session lifetimes Treat refresh tokens as high-value secrets, limit their lifetime where the platform allows, and remove blanket long-lived access for integrations that do not require it.
- Correlate token issuance with API and data-access logs Join OAuth server events, connected-app audit data, Salesforce event monitoring, and bulk export logs so unusual issuance or first-use patterns can be detected quickly.
- Audit for hidden secrets inside business records Search cases, notes, and text fields for embedded API tokens, passwords, and keys, then rotate anything exposed because exfiltrated CRM data can carry more credentials.
- Offboard integrations by revoking tokens everywhere they exist When a connected app is disabled or a vendor relationship changes, revoke tokens in each dependent platform and verify that no residual token path remains active.
Key takeaways
- The incident shows that stolen OAuth tokens can turn a trusted SaaS integration into a durable access path without breaking into endpoints.
- Public reporting points to hundreds of affected organisations and confirmed exposure across Salesforce tenants, with some Google Workspace mailboxes also accessed through Drift Email.
- The limiting control is delegated-access governance: token revocation, scope reduction, and cross-platform correlation would have reduced the attacker’s room to operate.
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 SP 800-53 Rev 5 and NIST CSF 2.0 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 are the core secret exposure mechanism in this incident. |
| NHI-03 — Vulnerable Third-Party NHI | The Drift integration functioned as a third-party NHI whose trust was abused. | |
| NHI-05 — Overprivileged NHI | Broad connected-app scopes enabled data enumeration and bulk export at scale. | |
| Recommendation — Scan connected-app token stores and downstream logs for exposed OAuth credentials and revoke anything found. Review third-party integrations as governed identities and restrict the scopes they inherit by default. Reduce integration scopes to the minimum callable data and operations required for the workload. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The campaign used stolen tokens to access tenants and move through SaaS data paths. |
| Recommendation — Map token abuse to credential-access and lateral-movement detections across SaaS logs. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | OAuth token lifecycle is an authenticator-management problem in this breach. |
| Recommendation — Apply authenticator management controls to revoke, rotate, and expire integration credentials on schedule. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The incident exposed weak entitlement governance for connected SaaS apps. |
| Recommendation — Continuously verify that connected-app entitlements match current business need and remove excess access. | ||
Key terms
- Connected App: A connected app is a third-party integration that is granted access to a SaaS platform through APIs and OAuth permissions. From a governance perspective, it is an identity-bearing access path that needs ownership, scoping, and periodic review like any other non-human identity.
- OAuth Refresh Token: An OAuth refresh token is a long-lived credential that lets an application request new access tokens without asking the user to log in again. In practice, it behaves like a reusable access key, so compromise can create persistent access until the token is revoked or expires.
- Backend API Abuse: Backend API abuse is the misuse of application programming interfaces that are intended for server-to-server or internal application communication. It occurs when attackers, insiders, or compromised workloads call trusted endpoints to extract data, trigger actions, bypass controls, or automate fraud. The risk rises when APIs lack strong authentication, authorization, rate limits, and monitoring.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
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 July 9, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org