TL;DR: OAuth token theft in the Salesloft Drift supply-chain campaign continues to expose Salesforce data at Qualys and Tenable, underscoring that stolen tokens can remain operational long enough to reveal customer support records and that detection lags when integrations are silently trusted, according to Anomali. The issue is not just compromise, but the governance assumption that third-party access stays visible, bounded, and reviewable in time to matter.
At a glance
What this is: This is Anomali’s update on the Salesloft Drift token abuse campaign, which shows stolen OAuth tokens still being used to reach Salesforce data through trusted third-party integrations.
Why it matters: It matters because IAM and NHI programmes have to govern delegated app access as a lifecycle problem, not just a login problem, when third-party tokens can outlive detection and review cycles.
Context
Salesloft Drift token abuse is a non-human identity governance problem because OAuth tokens can act as silent credentials inside trusted SaaS-to-SaaS integrations. When those tokens are stolen or over-scoped, defenders may not see the abuse through normal password or MFA signals.
In this case, attackers used stolen OAuth tokens to access Salesforce environments at Qualys and Tenable and exposed customer support data including names, business emails, phone numbers, and case details. The incident shows that third-party access can remain operational even after the original compromise is understood, which is typical of delegated-access abuse rather than an isolated account takeover.
The broader issue is not simply token theft. It is the governance gap created when integrations are trusted longer than their business purpose, review cadence, or monitoring coverage can actually support.
Key questions
Q: What breaks when a stolen OAuth token is used against a trusted integration?
A: The trust model breaks because the system still sees a valid credential, even though the actor behind it is no longer trustworthy. In practice, stolen delegated access can bypass interactive authentication and continue until revocation or expiry, which is why connected app tokens need ownership, monitoring, and fast containment.
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 a third-party OAuth integration is over-trusted?
A: Warning signs include broad scopes, old tokens that still work, unclear app ownership, and integrations that were never revisited after a vendor or business change. If an app can keep accessing data long after its purpose changed, governance is lagging behind the actual access model.
Q: How should IAM teams govern third-party SaaS access after a breach?
A: They should recertify every downstream entitlement tied to the affected integration, identify which apps inherited trust from the compromised connection, and revoke anything without a clear owner. The same review should cover dormant test apps, vendor connectors, and service accounts, because each can preserve access beyond the original incident.
Technical breakdown
How stolen OAuth tokens stay useful inside trusted SaaS integrations
OAuth tokens are delegated access credentials, not passwords, and they often inherit the trust that a connected application already has with downstream systems. In a SaaS-to-SaaS setup, that means a token can let an attacker move through approved integration paths without triggering the same controls used for interactive user login. The risk rises when scope is broad, token lifetime is long, and logging does not make third-party actions easy to distinguish from normal API traffic. In this campaign, those properties turned a stolen token into a durable access path into Salesforce data.
Practical implication: inventory OAuth-linked apps and constrain token scope and lifetime to the minimum needed for business function.
Why detection lags when OAuth abuse looks like normal integration traffic
OAuth abuse is hard to detect because the activity often arrives through legitimate APIs and sanctioned app relationships, so the traffic itself does not look anomalous at first glance. That shifts the defender’s job from blocking a known bad login to identifying whether a trusted integration is still acting within its intended boundary. Review has to include token provenance, app ownership, scope, and recent usage patterns. Without that context, investigators may know data was accessed but still struggle to tell which integration path carried it.
Practical implication: correlate API logs with app inventory so legitimate integration traffic can be separated from compromised delegated access.
Why third-party access creates a standing exposure problem
Third-party NHI access becomes a standing exposure problem when the organisation cannot prove that every integration still needs the privileges it already has. OAuth tokens can remain valid long after the business reason for access changes, and review processes often focus on user accounts rather than machine-to-machine trust. That mismatch creates a governance blind spot: the access is real, but the ownership, attestation, and offboarding discipline are weaker than they are for human identity. The Salesloft Drift campaign illustrates how that blind spot turns into delayed discovery and wider blast radius.
Practical implication: tie OAuth app recertification to vendor relationship changes, not just calendar-based access reviews.
Threat narrative
Attacker objective: The objective was to use trusted delegated access to reach Salesforce-held customer support data without triggering the controls that normally protect user logins.
- Entry occurred when attackers obtained stolen OAuth tokens tied to the Salesloft Drift integration and used them against connected Salesforce environments.
- Credential abuse happened through trusted delegated access rather than interactive authentication, which allowed the activity to blend into normal SaaS traffic.
- Impact followed when customer support data, including names, business emails, phone numbers, and case details, was accessed and exfiltrated from Qualys and Tenable environments.
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
Delegated SaaS access is now a governance boundary, not an implementation detail: When a third-party app can reach production data through OAuth, the organisation is managing non-human identity risk whether it has labelled it that way or not. The Salesloft Drift campaign shows that integration trust can persist beyond the visibility of the original compromise. Practitioners should treat app-to-app access as a governed identity domain with its own ownership and review requirements.
Silent tokens create detection debt: OAuth tokens do not behave like interactive credentials, so the absence of a login event is not evidence of safety. That means normal authentication-centric monitoring will miss the earliest signs of abuse. The practical consequence is that incident response starts later than the compromise did, which enlarges the exposure window and complicates attribution.
Third-party access without lifecycle offboarding is the failure mode this breach exposes: Access outlives the business relationship when token revocation, app review, and vendor offboarding are not tied together. That is not a technology bug, it is a governance assumption that trusted access will naturally age out. The implication is that organisations must reframe third-party NHI ownership as a lifecycle control, not a one-time approval.
Identity blast radius now includes customer support data: The data exposed here was not core infrastructure, yet the business impact was still meaningful because support records often carry direct customer context, contact details, and issue history. That widens the practical scope of identity governance beyond production systems. Security teams should expect adversaries to value the easiest reachable data, not only the most sensitive system.
Runtime trust in integrations is the new review target: A vendor connection can be technically valid and still be operationally inappropriate if its access scope exceeds the current business need. That makes recertification less about the existence of the app and more about whether its live permissions still match the role it is performing. The field should move toward continuous governance of integration trust, not periodic checkbox approval.
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.
- Read next: SaaS-to-SaaS and OAuth App Governance Guide
What this signals
Third-party OAuth access now needs the same governance discipline as privileged human access: The problem is no longer just whether an integration is legitimate at onboarding. It is whether the live token estate still matches the current business relationship, which makes lifecycle control the real boundary of trust.
OAuth token abuse expands the identity blast radius beyond the login event: Once a connected app is trusted, the attack surface includes every downstream dataset that app can reach. That means support records, CRM data, and other business context become reachable through governance gaps that traditional authentication controls never see.
For practitioners
- Inventory every OAuth integration Map each third-party app, the resources it can reach, the owner who approved it, and the data it can touch. Include dormant connections and inherited access that may not appear in user-centric reviews.
- Revoke tokens on vendor offboarding Treat partner change, app replacement, and contract end as revocation triggers for OAuth credentials, not just help desk cleanup. Token validity should end when the business purpose ends.
- Shorten token scope and lifetime Remove unnecessary permissions from connected apps and reduce how long tokens remain valid so stolen credentials have a narrower abuse window. Prefer narrowly scoped, purpose-specific access over broad platform trust.
- Correlate API logs with app ownership Use API telemetry to distinguish approved integration traffic from unusual data access patterns, then tie those events back to the app owner and business justification. Detection should focus on delegated actions, not only failed logins.
- Tie recertification to relationship changes Schedule access review events when a vendor changes scope, when a project ends, or when an integration is no longer actively used. Calendar-only reviews miss the moments when third-party risk actually changes.
Key takeaways
- This campaign shows that stolen OAuth tokens can keep third-party SaaS access alive long enough to expose sensitive customer support data.
- The evidence points to a governance gap, not just a compromise event, because delegated access remained usable across trusted integrations.
- The limiting control is lifecycle discipline for third-party app access, especially revocation, scope reduction, and review tied to vendor changes.
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 CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The incident centres on a compromised third-party integration used as the access path. |
| NHI-04 — Insecure Authentication | Stolen OAuth tokens functioned as trusted authentication material in downstream SaaS access. | |
| NHI-07 — Long-Lived Secrets | Persistent token validity extended the abuse window after theft. | |
| Recommendation — Review third-party integrations for trust assumptions and revoke any app that no longer needs access. Validate how OAuth tokens are issued, scoped, and revoked across connected applications. Shorten token lifetimes and eliminate credentials that remain valid beyond their business need. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | Stolen tokens enabled credential-like access followed by data theft from Salesforce environments. |
| Recommendation — Map token-theft campaigns to credential access and exfiltration tactics in detection and hunting workflows. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is the governance of delegated permissions, entitlements, and third-party authorizations. |
| Recommendation — Enforce review and limitation of third-party entitlements so delegated access stays aligned to business need. | ||
Key terms
- OAuth Token Abuse: The misuse of valid OAuth access or refresh tokens to gain unauthorized access without repeating the original login. In NHI terms, the token becomes the credential, so the real control problem is issuance, storage, scope, and revocation rather than passwords alone.
- Third-Party NHI: Third-Party NHI is a non-human identity owned or operated by an external organization, partner, contractor, or supplier. It includes service accounts, API keys, certificates, tokens, and automated agents that access systems outside the primary enterprise boundary. Governance must cover issuance, scope, monitoring, revocation, and contractual accountability.
- Token Revocation: Token revocation is the ability to invalidate a credential before its natural expiry when it is exposed, misused, or no longer needed. For JWTs and other NHI credentials, revocation closes the gap between detection and continued access, which is essential when a stolen token can otherwise remain usable.
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org