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.
NHIMG editorial — based on content published by CYATA covering the Salesloft Drift OAuth token breach: LLMjacking and OAuth token abuse across customer Salesforce tenants
By the numbers:
- Cloudflare rotated 104 internal API tokens found in the exfiltrated case text and notified customers.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a connected app token is stolen and reused?
A: A stolen connected app token turns delegated trust into direct access.
Q: Why do OAuth-connected integrations increase NHI risk?
A: OAuth-connected integrations increase NHI risk because they behave like machine identities with persistent authority and long-lived credentials.
Q: How can security teams detect token abuse in SaaS platforms?
A: Look for abnormal API sequences rather than login failures.
Practitioner guidance
- Inventory every connected app as an identity Create a register of connected apps, OAuth clients, and refresh-token holders across CRM, collaboration, and cloud platforms.
- Correlate token issuance with data-access behaviour Join OAuth server logs, API access logs, and SaaS event logs so you can see first use, geo drift, burst queries, and job deletion in one timeline.
- Reduce scopes before you need revocation Replace broad connected-app permissions with narrow platform-specific scopes, enforce IP restrictions where possible, and shorten token lifetime so compromise does not inherit standing privilege across tenants.
What's in the full article
CYATA's full analysis covers the operational detail this post intentionally leaves for the source:
- Cloudflare’s incident timeline and the sequence of SOQL, Bulk API, and cleanup actions used by the actor.
- Google Threat Intelligence guidance on token abuse patterns, affected integrations, and connected-app indicators of compromise.
- Salesforce and Google response actions, including token revocation and integration disablement details.
- Per-tenant exposure context and the customer disclosure pattern seen across the affected organisations.
👉 Read CYATA’s analysis of the Salesloft Drift OAuth token breach →
Salesloft Drift token abuse in Salesforce: what IAM teams need to know?
Explore further
Connected apps are non-human identities, not background plumbing: This incident shows that a trusted integration can become the primary identity path into customer data when tokens are stolen. Once the app’s bearer tokens were reused, Salesforce controls were acting on a valid identity, not an obvious intrusion. The implication is that IAM teams must govern connected apps with the same seriousness they apply to service accounts and privileged human accounts.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: Who is accountable when a third-party integration exposes customer data?
A: Accountability is shared, but operational ownership must be explicit. The SaaS owner is responsible for governing the connected app inside its tenant, while the integration owner must manage scopes, tokens, and offboarding across every platform touched. If neither side owns lifecycle controls, the integration becomes a persistent identity gap.
👉 Read our full editorial: OAuth token abuse turned Salesloft Drift into a Salesforce breach