Salesloft Drift Breach: Lessons for SaaS Integration Security

The Salesloft Drift breach was a supply-chain attack in which a threat cluster, tracked in reporting as UNC6395, stole OAuth and refresh tokens tied to the Salesloft Drift application and used them to query Salesforce instances belonging to Drift customers. Roughly 700 organizations were reported in scope. No password was cracked. No MFA was bypassed. The attacker authenticated as the integration itself, so to Salesforce it read as ordinary API traffic.

Drift is a conversational marketing and AI chat product that Salesloft acquired. Many customers connect Drift to Salesforce so chat leads flow into their CRM. That connection is a trust relationship, and the tokens behind it are bearer credentials: hold one, and the system assumes you are authorized. The attacker did not phish an admin. They took the integration's tokens and used them the way any legitimate integration would.

The reported sequence, at a broadly documented level:

1. The attacker acquired Drift's OAuth tokens. The initial vector is reported to trace back to a compromise in Salesloft's development environment earlier in the year.
2. They called Salesforce APIs using those tokens. To Salesforce, the caller was Drift, an app the customer had already consented to.
3. They ran targeted SOQL queries against high-value objects such as Cases, Accounts, and Users, hunting for secrets embedded in text: cloud access keys, data-warehouse tokens, and passwords pasted into support cases.
4. They deleted query jobs to shrink the forensic trail.
5. Harvested secrets were used to pivot toward other cloud and SaaS environments.

A concise, sourced timeline

The active exfiltration window is reported as roughly August 8 to August 18, 2025, with public disclosure by Salesforce and Salesloft following on August 26. A follow-on advisory covering abuse of the Drift Email connection into Google Workspace tokens is reported around August 28. Investigators later indicated the underlying Salesloft compromise began earlier in the year, giving the attacker time to prepare before touching customer data. Dates and the ~700 figure are drawn from public advisories and should be treated as reported specifics to verify against the primary sources at publication time.

What data was in scope

Exposure centered on data pulled from customer Salesforce tenants, mostly from Case, Account, Contact, Opportunity, and User objects. The attacker was not indiscriminate. They were mining freeform text for secrets: cloud access keys, warehouse tokens and connection strings, VPN and single sign-on configuration, and credentials that support agents had pasted into case bodies. For customers who connected Drift Email to Google Workspace, a small number of Workspace email accounts were also reached through the same token-abuse pattern.

OAuth tokens carry the authority of whoever granted them and answer to no one at runtime. That is the bearer-token problem. If you hold the token, the system treats you as the integration. No MFA challenge. No password check. No anomaly on the human identity side, because no human logged in.

That single property collapses the detections most teams lean on:

• Impossible travel is irrelevant, because a service token is not tied to a user location.
• Failed-login spikes never appear, because the token simply works.
• MFA anomalies do not fire, because service-to-service OAuth never sees MFA.
• New-device warnings do not trigger, because the "device" is the integration's own backend.

This is the uncomfortable part for anyone running an AI-adjacent stack. A probabilistic chat product held deterministic authority over a system of record. When the vendor was compromised, the blast radius was defined by what the integration was permitted to do, not by what it usually did. The quiet was not a detection failure in the classic sense. Every call was valid, every scope was pre-approved, and the identity layer had nothing to complain about.

Native Salesforce logs did record the API calls. That is the good news. The problem was what those logs looked like in isolation: normal Drift traffic, from the Drift connected app, under Drift's app ID. Without a runtime baseline of what Drift normally queried, the malicious SOQL blended into the noise.

Split the visibility gap into two columns.

What most teams could see: the integration existed, its OAuth scopes, the connected-app configuration, and aggregate API usage counts.

What most teams could not see without real effort: the specific SOQL statements being run, which objects and fields were touched, whether that query pattern deviated from historical Drift behavior, whether the harvested data contained secrets, and how the activity compared to the effective access the token actually held.

That gap is the whole ballgame. The configuration page said "Drift can read Cases." The runtime truth was "Drift is pulling every Case body looking for cloud keys." A theoretical config review returns the first sentence. Only runtime evidence returns the second. This is the difference between a vendor's config page and a record of what a specific non-human identity did with the access it was granted.

Theoretical configuration is not the same as effective access. When the Drift integration was installed, someone consented to a set of OAuth scopes. Nobody sat down and calculated the real reach: every Case body ever created, every Account note, every field a support agent ever pasted a credential into.

Three points compound.

First, OAuth consent is a permission grant, not a policy. The moment a user clicks Allow, the integration inherits their effective access, and there is no downstream check on what it does with that reach.

Second, integrations are non-human identities. Drift held bearer tokens with broad read access to a system of record. That makes it a machine insider, and in most programs it sat outside every insider-risk control aimed at humans.

Third, blast radius is fixed at consent time. By the time an attacker shows up, the scope is already set. Prevention means scoping and watching integrations before you need to, and it means being able to answer, for any connected app, which service identity it runs as and which objects and actions its access truly covers.

The operational reframe is straightforward. Do not measure an integration by the vendor's theoretical config page. Correlate its actual activity to its effective access inside the third-party app: which connected-app identity made the call, which objects and fields it read, and which actions it performed. That correlation is the evidence a config review cannot produce.

Detection here could only come from the runtime behavior of the integration, not from user identity signals. If your alerting keys off human login patterns, a stolen service token walks straight past it.

The practical takeaways:

• Detection has to watch the integration itself: query patterns, object and field access, and volume, baselined per connected app.
• Containment speed depends on knowing which integrations exist and being able to revoke access from one place instead of hunting through each SaaS console.
• Post-incident forensics needs per-integration query logs, not aggregate API counts. "Drift made 40,000 calls" is not an answer. "Drift read every Case body in a two-hour burst" is.
• Effective-access mapping tells you the real blast radius before an incident, so a revocation decision is a known quantity rather than a scramble.

Worth being precise about tooling here. Autonomous, inline blocking of a compromised integration is available today only for a narrow set of AI platforms, and Salesforce connected apps are not among them. For a case like this, the achievable and high-value posture is discover and govern: continuous discovery of every non-human identity touching your systems of record, a runtime baseline of what each one does, and governed workflows to revoke and rotate fast. Inline runtime enforcement across the broader SaaS estate is a direction of travel, not a present-tense guarantee, and it should be planned as roadmap rather than assumed as a control you already have.

Prevention comes down to treating every integration as a non-human identity with a runtime footprint you can see, baseline, and shut off. The chat product does not need to be malicious. It needs to be compromised once.

• Inventory every OAuth-connected app across Salesforce, Google Workspace, Microsoft 365, Slack, and every core SaaS system of record.
• Map each connected app to a business owner, a stated purpose, and a scope-review date.
• Reduce OAuth scopes to the minimum the workflow requires, not the vendor default.
• Rotate refresh tokens on a fixed schedule, and expire the ones no integration is using.
• Baseline normal API behavior per integration: which objects, which query patterns, what volume.
• Alert on deviation from that baseline, not just on user-side signals.
• Scan freeform CRM fields such as Cases and notes for credential patterns, then remediate the ones you find.
• Include connected apps and AI agents in your insider-risk and access-review programs.
• Run a revocation drill: how fast can you kill an integration's access and reconstruct what it did last month?

Common mistakes that widened the blast radius

The tokens were stolen from the vendor. The damage was decided inside each affected customer's tenant. The recurring mistakes: granting the integration broader scopes than the chat-to-lead workflow needed, letting support agents paste credentials into case bodies, never treating the connected app as a monitored identity, no alerting on abnormal query volume from an app, no token rotation, and no inventory of which third-party AI tools held live tokens into the CRM.

The compliance angle

Depending on the data exposed, affected organizations faced obligations under general data-protection and state breach-notification regimes, plus contractual notice to their own customers, and health-data rules where sensitive records sat in cases. The audit conversation shifted too. "We reviewed the vendor's security report" stopped being a sufficient answer for an integration holding live access to a system of record. Auditors began asking specifically about OAuth token inventory, third-party integration monitoring, and evidence of runtime visibility over connected apps. Treat the specific regulatory triggers as items to confirm against your own data map rather than assumptions.