Salesloft Drift OAuth abuse shows how SaaS trust can collapse

At a glance

What this is: This is an analysis of the Salesloft Drift OAuth abuse campaign, which used inherited tokens to reach Salesforce, Google Workspace and connected systems without a phishing email.

Why it matters: It matters because IAM teams have to govern third-party OAuth trust, token lifetime and integration scope as access paths, not as a one-time onboarding decision.

Context

OAuth trust can become an access channel long after the original approval event, especially when tokens are inherited by connected services and not continuously reviewed. In this case, the governance gap is not authentication failure at the inbox, but the persistence of delegated access across SaaS systems.

The article centres on non-human access governance because the abused credentials were OAuth tokens tied to a third-party integration, not user passwords. Once those tokens were compromised, the actor could query Salesforce objects, reach email data and attempt downstream access in connected cloud services.

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 OAuth tokens create risk even when no phishing email is sent?

A: Because the trust decision was made earlier, often during app onboarding. If the token remains valid and broadly scoped, an attacker can use it directly without tricking a user into clicking anything. This makes delegated access a governance issue, not just an inbox security issue.

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: How should teams respond when support data may contain secrets?

A: Treat the support system as a sensitive data repository and reduce who can search, export or query it. Then remove the habit of pasting credentials into tickets, because once a case system becomes a secret store, any compromised integration can become a secret-harvesting path.

Technical breakdown

How inherited OAuth tokens become a standing access path

OAuth tokens are delegated credentials that let one application act within another service’s authorised scope. When those tokens are long-lived, broad in scope and stored in a connected integration, they function like standing access rather than temporary consent. In this campaign, the attacker did not need to phish a user or break primary authentication. The trust decision had already been made, and the token remained valid until revoked. That changes the security model from user login protection to delegated access lifecycle control.

Practical implication: treat third-party OAuth tokens as governed credentials with expiry, scope review and revocation ownership.

Why support cases became the highest-value target

Support and case-management records often contain the most operationally sensitive secrets in a SaaS environment because users paste credentials, tokens and recovery data into tickets. That makes the case system a secret aggregation layer, not just a help desk workflow. Once the attacker had query access, targeting Cases was a fast path to higher-value material such as AWS keys, Snowflake tokens, VPN credentials and passwords. The breach shows how hidden secrets often sit outside formal vaults and inside business workflow data.

Practical implication: classify support and case data as a secret-bearing system and restrict who and what can query it.

Why email and SaaS compromise now move together

The Drift Email token abuse shows how a single delegated trust relationship can span CRM, email and downstream storage. The breach was not limited to Salesforce records because connected OAuth credentials can be reused across adjacent cloud services when permissions overlap. That creates a chain where one compromised integration can expose communication channels, harvested secrets and attempted storage access. This is why gateway-focused email security no longer captures the full risk surface.

Practical implication: connect SaaS app inventory, email telemetry and token governance so one delegated trust path is visible end to end.

Threat narrative

Attacker objective: The objective was to turn delegated SaaS trust into broad, reusable access for secret harvesting, email compromise and downstream cloud intrusion.

1. Entry occurred through compromised OAuth tokens tied to the Salesloft Drift integration, giving the attacker authorised access without a phishing email or password theft.
2. Credential access came from targeted Salesforce queries against Cases and other objects, where the attacker harvested AWS keys, Snowflake tokens, VPN credentials and passwords.
3. Escalation followed when Drift Email tokens were abused to reach Google Workspace accounts and exfiltrate email data, extending the blast radius beyond Salesforce.
4. Impact included stolen API tokens, exposed support data and downstream risk of spear phishing, impersonation and further cloud access attempts.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Snowflake breach: Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Delegated OAuth trust became a persistence layer, not a login convenience. The attacker did not need to defeat primary authentication because the access path already existed in a trusted integration. That shifts the governance problem from user-facing sign-in controls to lifecycle control over issued tokens, scopes and connected-app ownership. The practitioner conclusion is simple: delegated access must be governed as a credential estate.

Support workflows have become secret concentration points. Cases and tickets often hold the exact material attackers want next, including cloud keys, recovery material and credentials pasted by users or support teams. This is not an anomaly in modern SaaS operations, it is a structural pattern. The implication is that case data handling must be treated as part of secrets governance, not only service desk governance.

Blast-radius control is now the decisive NHI governance concept. The compromise of one integration reached Salesforce, email and attempted cloud storage access because token scope was broader than the business expected. That means the key question is no longer whether an app is trusted at onboarding, but how far that trust can travel if the token is abused. Practitioners need to measure delegated access by potential blast radius, not by application name.

Traditional perimeter thinking underestimates third-party NHI risk. Secure email gateways and inbox filters are blind to inherited OAuth authority and cannot reason about token provenance. The attacker never had to deliver a malicious message, which means the usual email threat model missed the entry point entirely. For identity teams, this validates a broader shift toward SaaS posture, token inventory and cross-system access governance.

OAuth abuse should be read as an identity lifecycle failure, not only a supply chain story. The issue is not simply that a third-party app was involved, but that its delegated access remained valid long enough to be weaponised across many customers. Once token ownership, scope and revocation are not continuously managed, the integration behaves like durable access rather than temporary automation. The practitioner lesson is to govern issuance, review and offboarding together.

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

Delegated OAuth access needs the same lifecycle discipline as other NHI credentials. Once an integration token can read business records, mailbox data or support cases, it is no longer a convenience layer. It is a governed credential that needs ownership, expiry and revocation boundaries aligned to business risk, not just app connectivity.

Third-party trust has to be measured by blast radius, not by vendor reputation. The question for IAM teams is how far a token can travel across SaaS, email and downstream storage if it is abused. That is a posture problem, and it belongs in the same governance conversation as secrets sprawl and privileged access.

For practitioners

• Audit third-party OAuth tokens Inventory every connected SaaS integration, then rank tokens by privilege, data reach and ownership so stale delegated access can be removed first.
• Limit support-case secret exposure Restrict who can query case objects and remove patterns that encourage users to paste API keys, recovery codes or passwords into tickets.
• Revoke unused app permissions Set a recurring review for dormant integrations, excessive scopes and service accounts that can still read mail, CRM data or storage objects.
• Correlate SaaS and email telemetry Join OAuth events, mailbox activity and API queries so a single delegated token can be detected when it starts behaving outside normal use.

Key takeaways

• This breach shows that delegated OAuth access can outlive the trust decision that created it and become a persistent entry point.
• The compromise reached more than 700 organisations and exposed support data containing secrets, making the scale of the blast radius operationally serious.
• Teams need to govern third-party tokens, support-case secret exposure and cross-SaaS visibility as one control plane, not separate problems.

Key terms

• OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
• 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.
• 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.
• SaaS posture management: SaaS posture management is the continuous discovery, classification, and policy enforcement of cloud application risk. For AI-enabled SaaS, it extends beyond configuration checks to include data retention, model training permissions, delegated access, and automated remediation when behaviour drifts from policy.

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.