Salesloft Drift: stolen agent credentials open more than 700 Salesforce estates

What happened

Between March and June 2025, a threat actor that Google's Threat Intelligence Group tracks as UNC6395 had access to Salesloft's GitHub account. How the account was first compromised has never been publicly disclosed. From there the actor conducted reconnaissance of the Salesloft and Drift application environments and pivoted into the AWS environment of Drift, Salesloft's AI chat agent product, where it stole the OAuth access and refresh tokens Drift held for its customers' technology integrations.

Between 8 and 18 August 2025, per Google's advisory, the actor presented those stolen tokens to customers' Salesforce instances and executed queries against "Salesforce objects such as Cases, Accounts, Users, and Opportunities." The exfiltrated data, largely support-case text, was then mined for secrets customers had pasted into tickets. Google reported the actor "targeting sensitive credentials such as Amazon Web Services (AWS) access keys (AKIA), passwords, and Snowflake-related access tokens." A separate strand used Drift Email tokens to access "a very small number of Google Workspace accounts."

On 20 August 2025, Salesloft and Salesforce revoked all active Drift tokens and Salesforce removed Drift from its AppExchange. The US financial regulator FINRA alerted member firms that the breach "impacted more than 700 organizations" (the count comes from FINRA and press reporting of Google statements; Google's own advisory publishes no number). Cloudflare, Zscaler, Palo Alto Networks and PagerDuty each published first-party disclosures, consistently confining the impact to Salesforce-held data and denying compromise of their core systems. Cloudflare reported finding 104 of its own API tokens in the stolen case data and rotated them, telling customers: "We let our customers down. For this, we sincerely apologize."

Drift was taken fully offline on 5 September 2025 for a security review. It has not returned to the AppExchange, and third-party reporting in March 2026 describes a gradual product sunset; no first-party end-of-life statement has been located. Proposed class actions followed against Salesforce and against Salesloft; in December 2025 the Judicial Panel on Multidistrict Litigation declined to centralise the Salesforce-related actions. All litigation remains at the allegation stage. One attribution note this register will treat as standard discipline: UNC6395 is a tracking designation for an uncategorised cluster, not an identified group, and Google has said the public claims of responsibility made by others are unsupported.

The duty engaged

GDPR Article 28 and the processor chain. For any affected organization with EU or UK data subjects in its CRM, the chain ran: controller (the customer organization) → Salesforce (processor) → Salesloft/Drift (a further processor or independent integration partner, depending on contract structure). Drift held standing credentials into the controller's CRM. Article 32 required security appropriate to the risk from everyone processing on the controller's behalf; the question a regulator or court would ask is whether storing live OAuth tokens for hundreds of customer estates in an environment reachable from a compromised GitHub account met that standard. That is an open question of fact, not a settled conclusion; it is also precisely the question the class actions plead, and those remain unproven allegations.

Articles 33 and 34: the notification cascade. Each affected organization, as controller, owed its own 72-hour breach assessment from the moment it had awareness, which for most arrived as a vendor notification in late August. Support-case text routinely contains names, contact details and correspondence; whether each controller's assessment concluded notifiable risk is invisible from outside. The structural lesson is that a vendor-side compromise put several hundred controllers simultaneously on the Article 33 clock, with their assessment dependent on facts only the vendor and its investigators held.

Contract. The DPAs and security exhibits between the affected organizations and Salesloft are not public. The live issues they would govern: security warranties for credential storage, breach-notice timing, audit rights under Article 28(3)(h), and indemnity allocation. The procurement-stage point: an AI agent holding standing delegated access is a processor with keys, and its contract should be read the way one reads a custodian's.

What Salesforce's position illustrates. Google was explicit that no Salesforce platform vulnerability was exploited; the tokens were valid bearer credentials presented by an unauthorised holder. The plaintiffs suing Salesforce allege its security fell short anyway. Whatever the courts make of that, the architecture point survives: a platform can be uncompromised and still be the venue where the loss lands.

The liability chain

The agent vendor (Salesloft/Drift) is the natural centre of gravity. It held the credential store; the intrusion ran through its GitHub and AWS environments; its product was removed, taken offline and ultimately wound down. Its public narrative (Mandiant engaged, environments segmented, containment verified) goes to remediation, not to the antecedent question of whether the storage architecture met the contractual and Article 32 standard. That question is now in litigation.

The platform (Salesforce) was not exploited, and saying so plainly matters. Its exposure, if any, is the plaintiffs' theory that the ecosystem's trust model (standing OAuth grants to AppExchange integrations, with the platform's marketplace imprimatur) should carry some of the loss. The JPML's December 2025 refusal to centralise keeps those theories developing in parallel courts.

The deployers (the 700+ organizations) carry duties no vendor contract removes: they granted the agent its scopes, they owed their own data subjects the Articles 33/34 response, and the secrets harvested from their support tickets were put there by their own staff and customers. Pasting credentials into tickets is common industry practice rather than negligence in any individual case, but controllers' minimisation and storage-limitation duties under Article 5 apply to support channels exactly as they apply everywhere else, and this incident is the proof of why.

The threat actor bears primary responsibility for the unlawful access throughout; computer-misuse liability is uncontroversial here and unattributable in practice until someone is identified. Civil recovery runs against the chain above instead. That asymmetry, the wrongdoer absent and the contract chain present, is the recurring economics of agent-credential incidents.

What would have prevented it

• Treat the agent's credential store as crown jewels. Tokens conferring standing access to hundreds of customer estates warrant the controls of a secrets vault: hardware-backed storage, strict environment isolation from anything reachable via developer infrastructure, and monitored access paths.
• Short-lived, narrowly-scoped tokens. Long-lived bearer tokens with broad object access turned one vendor compromise into seven hundred. Scope reduction and aggressive token rotation cap the blast radius.
• Deployer-side grant review. Each organization chose the scopes Drift held. Quarterly review of third-party OAuth grants against actual need, with IP-restriction where the platform supports it, is procurement hygiene for any agent integration.
• Secret-hygiene in support channels. Credential-scanning on inbound case text, and rotation policies that assume support tickets are discoverable, would have blunted the second-order harvest.
• Vendor disclosure of root cause. The initial GitHub compromise method remains undisclosed a year on. Deployers re-papering their agent-vendor contracts should be writing root-cause disclosure obligations into the breach clauses.

Mapped controls

• OWASP Top 10 for Agentic Applications 2026: ASI04 Agentic Supply Chain (primary): the agent vendor's own infrastructure was the poisoned component, propagating to every downstream deployer. ASI03 Identity & Privilege Abuse (secondary): the exploitation step abused the agent's delegated OAuth identity, which bypassed MFA by design. Notably, no prompt injection or autonomous misbehaviour was involved; the agent was the credential-bearing pivot, not the decision-maker.
• Singapore IMDA Model AI Governance Framework for Agentic AI: the framework's upfront risk-bounding dimension (what the agent can access, and through what identity) is the control class this incident validates; agent identity management with a traceable accountable party maps directly to the standing-grant review above.
• Runtime/identity tooling: non-human identity governance for agents (scoped credentials, rotation, anomaly detection on integration queries) is the control family the incident has pushed up enterprise roadmaps.
• NIST AI RMF: primarily a MAP and GOVERN failure. The supply-chain and non-human-identity risk of an agent holding standing OAuth credentials across hundreds of estates went unmapped (MAP), and accountability for that credential store across the vendor chain went ungoverned (GOVERN).

Sources

• Google Threat Intelligence Group, "Widespread Data Theft Targets Salesforce Instances via Salesloft Drift," 26 August 2025 with 28 August update — checked June 2026 [primary]
• FINRA, "Cybersecurity Alert – Salesloft Drift AI Supply Chain Attack," circa September 2025 — checked June 2026 [primary]
• Cloudflare, "The impact of the Salesloft Drift breach on Cloudflare and our customers" (published as "Response to the Salesloft Drift incident"; Zaman, Strubhart, Bourzikas), 2 September 2025 — checked June 2026; URL verified July 2026 [primary]
• Salesforce security advisory 005134951, "Salesforce Security Response: Drift App (Salesloft) Unauthorized Access Incident" — checked June 2026 [primary]
• JPML, MDL No. 3164 order denying centralisation, filed 16 December 2025 — checked June 2026; URL verified July 2026 [primary]
• Help Net Security, "Salesloft Drift data breach: Investigation reveals how attackers got in" (Zeljka Zorz), 8 September 2025 — the Mandiant-supported root-cause disclosure — checked June 2026; URL verified July 2026
• The Register on proposed Salesforce class actions (Lindsay Clark), 26 September 2025 — checked June 2026; URL verified July 2026
• Salesforce Ben, "Salesloft Takes Drift Offline to 'Build Security' Following Hack Targeting Salesforce Customers" (Henry Martin), 4 September 2025 — checked June 2026; URL verified July 2026
• Krebs on Security, "The Ongoing Fallout from a Breach at AI Chatbot Maker Salesloft," 1 September 2025 — checked June 2026; URL verified July 2026
• OWASP Top 10 for Agentic Applications 2026 (published 9 December 2025) — checked June 2026 [primary]

Cite this entry as AIR-2026-002 (https://companyscope.io/register/air-2026-002). Entry IDs are stable; corrections publish as dated addenda on this page.

This analysis is the work Janus Compliance does for clients before the incident. For a fixed-scope read of your own EU AI Act Article 50 exposure, see the Article 50 teardown; for ongoing agent governance, Janus DPO-as-a-Service. Browse the full register or the vendor compliance index.