Salesloft Drift OAuth supply-chain breach (UNC6395) — mass Salesforce data theft via an AI chat integration
Real-world incident26 Aug 2025🗺️ Tool-Using AgentAttackers stole OAuth tokens from the Salesloft Drift AI chat integration and used them to silently export Salesforce data from 700+ organisations, reportedly including Cloudflare, Google, Palo Alto Networks and Zscaler.
Root cause — why it happened
Drift is an AI chat assistant many companies put on their websites. To do its job, it was given a standing 'master key' (an OAuth token) into each customer's Salesforce — the system that holds their sales and support records. Attackers got hold of those keys from the Drift side, then used them to log straight into hundreds of customers' Salesforce accounts and quietly copy out the data. Because the key already carried Drift's trust, no password prompt or extra check stood in the way. They were really hunting for other passwords and cloud keys hidden inside that data, to break in elsewhere.
Risks this case illustrates
Named in the standard (OWASP/ATLAS/NIST) lens. Click a highlighted component in the diagram below to see which risks attach where.
How it unfolded
A standing key into every customer's Salesforce
Long before the attack, each customer connected the Drift AI chat assistant to their Salesforce so it could read and write sales records on their behalf. That connection left a standing key — one that keeps working without anyone logging in again. Hundreds of companies had one.
integration: Salesloft Drift (AI chat) oauth_grant: scope: api, refresh_token, full # broad; rarely minimised access_token: <bearer> # short-lived but auto-renewed refresh_token: <bearer, long-lived> # standing trust into the tenant bound_to: <none> # not IP/device/tenant-pinned mfa_required_on_use: false # token carries existing trust # Same shape replicated across 700+ customer Salesforce orgs.
Controls & guardrails — what would have stopped it
Two things together would have blunted this. First, give the AI integration only the narrow access it truly needs, with keys that expire quickly — not a standing master key into everything. Second, watch how much data it pulls and be able to switch all its keys off in one move. Then a stolen key opens far less, for far shorter, and gets shut faster.
- Least-privilege identity & scoped credentials
Doesn't prevent manipulation — only caps its reach. Hard to get right operationally; over-broad scopes are the common real-world failure.
- Egress allowlisting & DLP on tool argumentsaddressesSensitive Data Leakage
Allowlists fight an open-ended channel; legitimate-but-broad destinations (any URL fetch, any email) are hard to constrain without breaking usefulness. Encoding can evade naive DLP.
- MCP/plugin pinning, manifest hashing & re-reviewaddressesSupply-Chain Compromise
Review catches what reviewers understand; a subtle malicious directive can pass. Pinning helps only if you actually re-review on update rather than auto-accepting.
- Runtime monitoring & anomaly detectionaddressesSensitive Data Leakage
Detects the anomalous, not the novel-but-subtle; high false-positive rates cause alert fatigue. Always a step behind a sufficiently quiet attacker.
- Full-trace audit logging
Logging is forensic, not preventive — it explains harm after the fact. Useless if no one reviews it or if the materialised context isn't captured.
- Governance: risk assessment, red-teaming & incident responseaddressesSupply-Chain Compromise
Process reduces likelihood and speeds recovery but executes no technical control itself; weak follow-through makes it theatre.
Lessons
- ▸ A third-party AI integration is a privileged non-human principal: its standing OAuth tokens are high-value targets, and one vendor-side compromise fans out across every tenant that trusts it.
- ▸ OAuth bearer tokens are completed authentication — they ride existing trust and bypass MFA, so the control surface is scope, binding, lifetime, monitoring, and revocability, not a login prompt.
- ▸ When access is legitimate, only volume and destination distinguish theft from normal use — instrument per-integration egress/query anomalies, not just authorisation.
- ▸ Mass, fast revocation is the corrective that actually ends this class of incident; design integrations so all their tokens can be killed in one move.
- ▸ Secrets stored as free text in CRM records turn a data breach into a credential-harvesting campaign — scan and purge them so a dump yields nothing live.
Proposals & gaps this case surfaced
Non-destructive suggestions for the library — proposed, not adopted.
Treat each third-party AI integration as a privileged non-human principal: issue least-scope, IP/device-bound, short-lived grants (avoid 'full' scope and standing long-lived refresh tokens), instrument the integration's data egress for volume/object-breadth/destination anomalies, and maintain a tested one-move revocation path for all of an integration's tokens so a single vendor-side compromise cannot fan out into hundreds of standing footholds.
This case shows a gap: a lot of guidance focuses on tricking the AI model, but here the AI was never tricked at all — its standing 'master key' into other systems was simply stolen and reused. We should treat that long-lived integration key as its own risk to manage: keep it small, short-lived, watched, and quick to switch off.
These surface as proposals across the Control Library and Risk Taxonomy; adopt them by hand when ready.
Sources
- Widespread Data Theft Targets Salesforce Instances via Salesloft Drift — Google Threat Intelligence Group (GTIG, primary) ↗
- The Ongoing Fallout from a Breach at AI Chatbot Maker Salesloft — Krebs on Security ↗
- Cloudflare, Zscaler among companies impacted by Salesloft Drift incident — The Record (Recorded Future News) ↗
- GTIG — Widespread Data Theft Targets Salesforce Instances via Salesloft Drift (primary advisory + 28 Aug update) ↗ — UNC6395; bulk SOQL exfil of Cases/Accounts/Users/Opportunities; credential-harvesting intent; mass token revocation; Drift Email → Google Workspace.
- Krebs on Security — The Ongoing Fallout from a Breach at AI Chatbot Maker Salesloft ↗ — Fallout, victim scope, and 'treat all Drift-connected tokens as compromised' guidance.
Practise the risk class — related scenarios
A support email hides instructions — and the assistant obeys them
A speed optimisation becomes a cross-tenant listening device
Compromise the pipeline that builds agents, and every new worker is born malicious
Two doors to the same secret: reconstruct the model through its API, or just walk off with the weight file
A fake Sentry error report hijacks a developer's coding agent into running a shell command
The forensic record is itself the attack surface — an agent's log is poisoned, then quietly rewritten
A cost-saving open-weights swap quietly ships a model with its safety surgically removed
A screenshot that's harmless at full size becomes an order once the system shrinks it
A capable third-party model that behaves perfectly — until it sees the trigger
An attacker captures the agent's bearer token — and inherits its authority
A trusted MCP email tool quietly BCCs every message to an attacker
A forged peer registers on the agent directory — and the planner enlists it
A poisoned web page hijacks a research agent — and the planner acts on its behalf
An inbox summary quietly ships a secret to an attacker's server