// 00
The count from edition 1 gets an update
I start by owning a mistake
In the previous edition I wrote that, of the five cases analyzed, only one had been a real attack that reached users. The other four were coordinated disclosure, proof of concept or operational failure, and I insisted that mixing up those categories destroys the credibility of anyone who writes about security.
That count is out of date. There is one more case, which did not make it into edition 1, and it is bigger than the only one I had counted.
In August 2025, an actor tracked by the Google Threat Intelligence Group as UNC6395, and by Cloudflare's intelligence team as GRUB1, exfiltrated data from the Salesforce instances of more than seven hundred organizations using tokens stolen from the Drift integration. Victims that confirmed it publicly include Cloudflare, PagerDuty, Palo Alto Networks, Proofpoint, SpyCloud, Tanium and Zscaler.
Confirmed by the victim's own forensics, with a minute-by-minute timeline published, and by an incident response investigation commissioned by the vendor, with a final summary published. It was not coordinated disclosure, it was not academic research and it was not an operational accident.
Drift is Salesloft's AI chat agent. It greets site visitors, answers questions, qualifies interest and captures the contact. For that contact to become a sales opportunity, it has to land in the CRM. So each company installed Drift from the AppExchange and authorized the connection to its own Salesforce. The credential for that connection is what the attacker stole.
THIS IS NOT A SALESFORCE BREACH
The Salesforce platform was not breached. Salesforce itself stated that the problem did not come from a vulnerability in the platform but from the compromise of the app's connection credential. The GTIG advisory says the same. Drift was a third-party app, published by Salesloft, that each customer installed on its own and connected to its own environment.
Calling it a Salesforce breach puts the responsibility in the wrong place. The lesson of the case is in what each company authorized inside its own house, and in who kept an eye on it afterwards.
Opening with my own mistake is the price of writing about a subject that moves. I would rather pay that price than keep a tidy count.
// 01
The AI agent was not tricked
the thesis of this edition, and it goes against almost everything in circulation
Edition 1 dealt with attacks that come in through the conversation. Someone writes something on a page, in an email or in a ticket, the agent reads it as if it were an instruction, and starts working for someone else.
In the Salesloft Drift case, none of that happened. Nobody wrote anything for the agent to read. The model was not manipulated, received no poisoned instruction and made no wrong decision. The agent did not even need to be running at the time of the attack.
What the attacker used was the identity that agent already had inside the systems of seven hundred companies.
THE SHIFT
I think this is the part of the AI security conversation that is furthest behind. The public discussion revolves almost entirely around what the model can be convinced to do. Almost nobody is looking at what the agent was authorized to do on the day someone connected it, or at who controls that authorization today.
// 02
What a token is, in plain English
without this, the rest of the edition makes no sense
Who authorized the connection
Someone, at some point, installed Drift and clicked authorize. Probably a marketing manager, probably in fifteen minutes, probably on a screen listing permissions nobody read. The connection stayed up for a year or two, working, and nobody looked at it again.
That connection is what was attacked.
Now the badge
When you log in to Salesforce, you type your username, your password and the second factor. The system checks who you are and opens the session.
An integration does not do that. It has no username, types no password, gets no text message. What it gets, only once, on the day it was authorized, is a token. A permanent badge issued by Salesforce saying that whoever presents it can read certain data.
Three features of that badge explain the whole incident.
- It has no photo. Salesforce does not check who is on the other end of the connection, only whether the badge is valid.
- It does not expire on its own. It was issued at some point in 2023 or 2024 and was still valid in August 2025.
- It already is the authorization. There is no login step for MFA to protect, because the login already happened, once, years ago, and the result of that login became a file stored on the vendor's server.
IN ONE LINE
Steal the badge and you never have to break down the door.
// 03
The chain was credentials from start to finish
the same mechanism repeats at three levels
Salesloft hired Mandiant to determine the root cause, and the result was published on Salesloft's own trust portal. It is worth reading slowly.
Between March and June 2025, the attacker accessed Salesloft's GitHub account. They downloaded content from several repositories, added a guest user and created workflows. The final summary of the investigation, completed on 30 September 2025, records that they used Salesloft's GitHub Personal Access Tokens for reconnaissance and secret enumeration, and exfiltrated secrets from environment variables and code repositories. A token again, one step up.
With what they found, they accessed Drift's AWS environment. Stored inside it were the OAuth tokens for every customer's integration. A file holding the badges of seven hundred companies.
At none of these three steps was there a vulnerability exploited, a password cracked or a system tricked. At each step there was a long-lived credential stored somewhere, waiting.
WHAT IS NOT KNOWN
Salesloft has never said publicly how the GitHub account fell. Mandiant's investigation records the intrusion window as 22 March to 5 September 2025 and describes what the attacker did, without establishing how they got in. Anyone who claims it was phone phishing is confusing it with the other campaign against Salesforce customers that same month, attributed to UNC6040, which is a different case with a different modus operandi.
// 04
What it looked like inside one victim
Cloudflare published the most detailed report that exists on this case
This is what turns the case from a statistic into a scene. All times below are UTC and come from the postmortem of 2 September 2025.
11:51
22:14
19:33
00:17
04:34
11:09
19:28
11:11
11:15
Two moments are worth stopping on
The first is 14 August at 11:09, when the attacker asks Salesforce what the API's operational limits are. They wanted to know where the ceiling was before deciding how much to pull, so they could steal without maxing out any counter or setting off any alarm. That defeats, by construction, any control that looks for abnormal behaviour.
The second is the duration. It took nine days of operation for a little over three minutes of theft. All of it presenting a valid badge, within the API's business hours, without generating a single suspicious login event.
Source: Cloudflare, The impact of the Salesloft Drift breach on Cloudflare and our customers, 02.09.2025. Detailed timeline published in the postmortem itself.
// 05
What was taken is worse than it looks
the support ticket became a vault without anyone deciding it should
It was not customer passwords or financial data. It was the text of support tickets: subject, message body and the contact details of whoever opened them. Attachments were not accessed.
The thing is, nobody treats support tickets as a sensitive system. When a customer has a technical problem at eleven at night, they paste the whole log into the ticket, the configuration, and sometimes the key.
Cloudflare states plainly that it does not ask for credentials in tickets. Even so, it scanned the stolen data with its own detection tools based on regex, entropy and pattern matching, and found 104 Cloudflare API tokens that customers had pasted in there. All of them were rotated, with no suspicious activity identified.
The attacker knew this before starting. The primary objective assessed by GTIG was credential harvesting, and the searches were for long-lived AWS key patterns, for mentions of Snowflake and for password strings. Exfiltrating Salesforce was the means. The target was what people had carelessly written inside Salesforce.
APPLY IT AT HOME
This changes the risk classification of a system that almost no company classifies as critical. And it applies to your service desk, to your contact form and to the transcripts of your own chatbot.
// 06
Nobody noticed on their own
the uncomfortable part
Cloudflare has one of the most mature security programmes on the market, publishes a postmortem for everything and runs its own threat intelligence team.
The exfiltration ended on 17 August. Cloudflare found out on 23 August, because Salesforce and Salesloft told it.
In between, on 20 August, Salesloft revoked the tokens of every customer and published a notice saying only that it had detected a security issue in Drift, asking administrators to re-authenticate the connection to Salesforce. The notice did not mention token theft. Cloudflare records in the report that, at that point, it had no indication this concerned its own environment.
I am not saying Cloudflare failed. I am saying that detecting this kind of access is structurally hard, for four reasons that add up.
- The traffic is legitimate and the credential is valid, so no authentication control fires.
- The volume stays within the platform's limits, because the attacker checked what they were.
- There is no login event, because there was no login.
- The log that would record the anomaly at the source sits on the vendor's side.
If it happened to you, you would find out by email.
THE MOST HONEST LINE IN THE CASE
Cloudflare closes the postmortem taking responsibility for its choice of the tools it uses, and saying it let its customers down. That comes from a company that was warned by third parties six days after the theft.
// 07
The pattern that repeats
putting the cases from edition 1 together with this one
Something shows up that I have not seen anyone write about.
In edition 1, the attacker supplies the instruction. They write in a place the agent will read, and the agent carries it out as if it were an order from its owner.
Here, the attacker supplies the credential. They present the agent's badge, and the system carries out the request as if it came from the agent.
Two paths lead to one destination. In both, an action is taken on the company's behalf without any person having approved it at that moment. The difference is which half of the agent was taken over, its behaviour or its identity.
The consequence is unpleasant for anyone investing today
A better model, better guardrails and a better prompt filter only address the first path. None of them touch the second. A perfect model, impossible to trick with any instruction, would have changed nothing in August 2025, because the model was not involved.
The same thing holds on both paths. Reduce the standing authority the agent carries. If the agent can only do what its function requires, being tricked becomes less dangerous and stealing its badge becomes less useful.
THE SYNTHESIS
The security of an AI agent depends less on what it thinks and more on what it can sign.
// 08
The question nobody could answer
three questions nobody was in a position to answer within a few hours
When the alert went out, every affected company had to answer three things within a few hours. Which AI integrations are connected to my systems. What permissions each one has. What credential sits behind each one, issued when and by whom.
Practically nobody had that list ready. GTIG's first recommendation is to review every third-party integration connected to the Drift instance, which assumes someone exists who can enumerate them. Salesloft's notice to integration partners asks them to revoke API keys proactively, which assumes they know which ones exist.
I could stop here and leave this as an inference from how the victims behaved. I prefer to bring measurement, and that is the next section.
// 09
What we measured
the only evidence in this document that did not come from a third-party source
A single run, at one client, with the fleet anonymised. It is not a sample and it does not generalise to the market. Read it as one measured observation, not as a statistic.
We ran the RADAR·AI discovery scan against a client's production Databricks fleet. This client had already done a manual survey, which puts them above average.
The automated inventory found two and a half times as many agents as the human check, and it surfaced an entire category nobody had mapped.
The gap between what a company thinks it has and what it actually has is the size of the surface it is not defending. In August 2025, seven hundred companies found out that number by email.
// 10
What would have held
sorted by level of assurance, from demonstrable to probabilistic
Almost everything recommended publicly after the incident is cleanup. Revoking tokens, rotating keys and reviewing integrations are the right actions, and all of them happen after the theft. It is worth separating what would have prevented it from what only limits the damage.
LEVEL 1
Deterministic and verifiable
does not depend on anyone paying attention
IP restriction on the connected app
This is the strongest control in the whole case, and it existed on both sides before the attack. Salesforce lets you set a connected app's IP policy to enforce restrictions, so the token only works if the request comes from an authorised address. Salesloft publishes the list of IPs that legitimate Drift traffic leaves from, and stated in its own advisory that any authenticated connection using a Drift token from outside that list should be treated as malicious.
The access to Cloudflare came from an AWS address and a DigitalOcean address. Neither belongs to Drift. What follows is my own inference, not a documented fact. With IP restriction switched on, the stolen token would have been valid and useless. Salesforce would have refused it before even looking at the badge.
It is deterministic because it does not assess intent or behaviour. It compares an address. And it is free.
Minimum scope on the connected app
Drift exists to capture a contact and push it into the CRM. For that it needs to write Lead and Contact. What the attacker took was the Case object, the text of support tickets, which has nothing to do with the job of a website chatbot. GTIG explicitly recommends reviewing connected app scopes and avoiding broad permissions such as full access. The token cannot do what the scope does not allow, no matter who is presenting it.
Secrets kept out of free-text fields
The 104 tokens Cloudflare had to rotate were not in a vault. Customers had pasted them into the body of support tickets. No identity control protects that, because the credential was already inside, in plain text, in a system classified as commercial.
Short-lived credentials instead of permanent ones
The remediation Mandiant imposed on Salesloft includes eliminating Personal Access Tokens and external collaborators as a way into GitHub. It was precisely the PAT that sustained the three months of reconnaissance on the first rung. A credential that expires on its own turns a permanent compromise into a compromise with a deadline.
LEVEL 2
Strong, but only works if someone looks
the assurance depends on configuration and on people
Event monitoring and bulk export alerts
Salesforce logs the queries executed and the number of rows returned. Cloudflare had those logs. That is how it reconstructed the entire attack, including the part the attacker tried to delete.
It reconstructed it afterwards. The control existed and the data existed. What did not exist was a trigger that turned a bulk export by an integration behaving out of pattern into a phone ringing. A badly tuned rule becomes noise nobody reads.
Frequent credential rotation
After the incident, Cloudflare began rotating integration secrets weekly. That narrows the window but leaves the door open. The reconnaissance lasted five days and the exfiltration lasted three minutes.
Secret scanning on data already stored
GTIG recommends running tools such as Trufflehog over Salesforce objects to look for keys and passwords. The irony is worth stating, because it is instructive. Trufflehog appears in Cloudflare's report as the attacker's User-Agent on the first day of reconnaissance. The same tool, on both sides, depending on who gets there first.
LEVEL 3
Does not hold this
and it is where most of the trust is placed
Multi-factor authentication
It does not come into play. There is no login to protect. MFA defends the moment when a person proves who they are, and here there was no person, no moment and no proof.
Vendor certification
I need to say this out loud because Jump lives off it. Salesloft holds ISO 27001, ISO 27701 and SOC 2 Type II, with the certificates published on the same trust portal I used as a primary source for this text. None of that prevented the incident.
Certification attests that a documented, reviewed and audited process exists. It does not attest that the process withstands a specific actor on a specific day. The real value of a certified vendor showed up afterwards. Salesloft had a trust portal, hired incident response, published a timeline, published indicators of compromise and published the final summary of the investigation. That is process maturity, and it is what allowed this edition to exist with a primary source.
Behavioural detection on integration traffic
On 14 August the attacker queried the API limits endpoint before deciding how much to pull. An adversary who calibrates their own volume to stay within normal defeats, by construction, a control that looks for the abnormal.
// 11
Checklist for builders
ordered from highest to lowest return
This week
- List every AI integration connected to your systems of record: CRM, email, storage, service desk, messaging. If the list does not already exist, that is the most important finding of the exercise.
- For each one, answer who authorised it, on what date, with what scope and which credential sits behind it. A scope inherited from an authorisation granted in 2023 is still in force today.
- Switch on IP restriction for every connected app whose vendor publishes its source range. Start with the ones that read customer data.
- Cut scope down to the minimum the function requires. If the agent captures leads, it does not need to read support tickets.
This quarter
- Replace permanent credentials with short-lived ones wherever the platform allows, and set dated rotation for the rest.
- Treat customer-facing free-text fields as a leak surface. Detect secrets on input and purge the history.
- Create alerts for bulk exports and for schema metadata queries originating from an integration account. The attacker's pattern was to enumerate objects, read the schema, count records and only then export. The first three steps are cheap to detect and happen days before the theft.
- Find out where each integration's access logs live. If the record of who used the token sits on the vendor's side and you do not receive a copy, you have no way to investigate.
In the contract
- Require notification within a deadline. Salesloft revoked every customer's tokens on 20 August and Cloudflare was notified on the 23rd. The gap between the vendor's action and the notice to the customer is a number that belongs in the contract.
- Require delivery of indicators of compromise and a timeline, not just notice that an incident occurred.
- Ask for the list of source IPs and the minimum-scope documentation before authorising, not after.
// 12
Where we differ from what circulates
six corrections, each with the source that supports it
Google was not a victim in this case
Victim lists in major outlets, including The Register and iTnews, put Google among the companies compromised through Drift. GTIG itself says otherwise in its 28 August update. Neither Google Workspace nor Alphabet was compromised, and Google was never a Salesloft Drift customer. What happened was access, on 9 August, to a very small number of Workspace accounts belonging to customers that had the Drift Email integration configured.
Google ended up on those lists through confusion with the other campaign against Salesforce customers, attributed to UNC6040 and disclosed on 05.08.2025.
There are three response dates, not one
On 20 August, Salesloft and Salesforce revoked all Drift access and refresh tokens, and Salesforce removed the app from AppExchange. On 28 August, Salesforce suspended all Salesloft integrations, which were restored on 7 September with the exception of Drift. Drift went offline on 5 September and came back on 16 September.
Source: the sequence of notices on the Salesloft Trust Center, 20.08 to 16.09.2025.
The number 700 does not appear in the GTIG advisory
The text Google published talks about numerous instances and gives no number. More than seven hundred organisations is what appears in the FINRA alert and in statements to the press. Attributing that number to the Google post repeats exactly the citation chain this series criticises.
The 8 to 18 August window is the envelope of the campaign
It does not describe any one victim's timeline. At Cloudflare, reconnaissance began on the 9th and exfiltration took place on the 17th.
The root cause of the GitHub access was never publicly determined
iTnews wrote that it was supposedly voice phishing. That is not in any primary source. Salesloft and Mandiant describe what the attacker did with the access without saying how it was obtained.
AI-generated analysis with invented dates is circulating
I found at least one professional-looking page that dates this campaign to June 2026 and claims every data point is backed by primary evidence from GTIG, Mandiant and Anomali. None of it matches the sources it cites. Dealing with this is now part of the job for anyone who writes about security. The intermediate layer between the incident and the reader now produces plausible, wrong text in volume.
What I did not verify
Four things that show up associated with this case, which I am stating as not confirmed in a primary source.
- The nationality of the actor. AppOmni describes UNC6395 as an actor assessed to be Chinese. GTIG does not attribute a nationality anywhere in the advisory. I go with GTIG.
- The later extortion phase and the appearance of a leak site associated with this data set. There are reports. I did not go to the source.
- Whether any of the stolen credentials was used in a subsequent attack. Cloudflare states it did not identify suspicious activity on the 104 tokens. For the other victims, there is no consolidated public data.
- The internal discrepancy in the dates Mandiant was engaged. The final investigation summary says 26 August 2025. The 6 September update, on the same portal, says 28 August. I am recording the inconsistency instead of picking one.
// 13
What this would require operationally
from here on I talk about what we do at Jump
Four questions came up along the way in this document, and none of them is about Drift.
- How many long-lived credentials exist in your company today, who issued each one, and on what date.
- How many keys and passwords are pasted inside your support tickets right now.
- How many days it would take you to know that one of your vendors was compromised, and through which channel.
- How many of your integrations that read customer data have IP restriction turned on.
If you answered all four without having to ask anyone, skip this section. It will not add anything for you.
Of the four, we handle three. The second one, about keys pasted inside tickets, depends on secret detection in text, which lives in the DLP product of whoever runs the operation. I would rather say this now than let you find out at the end.
If you did not, this is what we handle at Jump. From here on I talk about our product, separating what exists today from what is on the plan, because mixing the two is the mistake this whole text criticises.
Every control that would have held this attack back already existed. Salesforce, GitHub and AWS offered all three. What a company lacks is someone able to say, before the incident, which credentials exist, what they were for when they were created and what they can do today.
What RADAR·AI does today
answers 01 Multi-source discovery with thirty connectors covering code, cloud, identity, databases, data platforms, AI providers, vector databases, registries and Kubernetes. The coverage of each run is persisted, so whatever was not read is recorded as not read. In August 2025, the difference between finding nothing and being unable to look was the difference between being safe and thinking you were.
answers 01 Inventory with an owner. One row per AI asset, with owner, risk and status. An asset without an owner is critical by definition. This answers the question of who authorised it and when.
answers 01 Identity connectors, covering where non-human identity lives in most companies (Okta, AWS IAM and Azure AD). And code platform connectors, with GitHub at the highest maturity level, validated against a real environment. The first rung of the Drift chain was a GitHub account.
answers 04 Minimum scope guide consolidated for 26 enterprise connectors, with credential type, required permission and forbidden permission. We apply it to the access the platform itself asks for, which is the only honest way to recommend least privilege to a client.
What is on the plan, stated as a plan
Three roadmap items respond directly to what this case exposes, and I name them by the names they have in the product plan.
ANSWERS 04 · PHASE 2, LOW PRIORITY TODAY
Permission tied to the agent's declared intent. This is the exact answer to this case. The declared purpose of a website chatbot is to capture contacts, and the permission granted reached the support ticket object. Having the purpose documented, as ISO 42001 requires, and the scope in a console, with nobody comparing the two, is compliance on paper. This case is the argument for raising this item's priority, and that is my own position.
ANSWERS 03 · PHASE 2, HIGH PRIORITY
Cross-connector correlation, unifying signals from repository, cloud, provider, vector database, identity and runtime into a single asset. The Drift chain crossed repository, cloud and identity. Today each of those signals is read separately, and correlating them is what turns three isolated findings into a visible chain.
ANSWERS 03 · PHASE 1, HIGH PRIORITY, AT ZERO TODAY
LGPD and Brazilian AI Legal Framework (Marco Legal de IA) frameworks. It connects to this case through the duty to notify, which here had three distinct dates: revocation on 20 August, notification to Cloudflare on the 23rd, and communication to Cloudflare's customers on 2 September.
The limit, said out loud
GOVERNANCE DOES NOT PREVENT THIS INCIDENT
I need to say this before someone reads the section above and concludes the opposite. What would have prevented the theft was IP restriction on the connected app and scope reduced to the minimum. Both are deterministic configuration inside Salesforce, done by whoever administers Salesforce. We do not carry out that configuration and we will not suggest that we do.
What inventory changes is the moment you find out it was not there. Salesloft published the list of IPs that legitimate Drift traffic came from, and published it before the attack. The information existed. What did not exist was a place where someone compared each integration's expected posture with its actual posture, and an owner accountable for that gap.
Governance does not close the door. What it does is tell you which doors exist, which are open, who left them that way and since when. You are the one who closes them, in the vendor's console. The value lies in knowing this on your own, and not from a third party's email six days later.
What we do is answer the questions that seven hundred companies could not answer in August 2025.
And make the gap between what was authorised and what was intended show up before a third party finds it for you.
// 14
Primary sources
all read directly; no third-party summary went into this text
- Google Threat Intelligence Group e Mandiant · Widespread Data Theft Targets Salesforce Instances via Salesloft Drift · , updated
cloud.google.com
The 8 to 18 August window, attribution to UNC6395, the credential harvesting objective, the queries executed, indicators of compromise, recommendations, and the statement that Google was not a Drift customer. - Salesloft Trust Center · sequence of notices and the Mandiant investigation · to
trust.salesloft.com
Initial notice, the shutdown and restoration sequence, the integration partner FAQ, root cause and the final investigation summary. - Cloudflare · The impact of the Salesloft Drift breach on Cloudflare and our customers ·
blog.cloudflare.com
Minute-by-minute timeline, the 104 tokens, the exact scope of what was accessed, the recommendations and the indicators. - FINRA · Cybersecurity Alert: Salesloft Drift AI Supply Chain Attack
finra.org
The figure of more than seven hundred organisations and the equivalence between UNC6395 and GRUB1.
THE SERIES
- 01The agent cannot tell what it read from what it was told to dopublished 21.09.2026 · five verified cases
- 02The agent was not tricked. They used its badgeyou are here · non-human identity and the Salesloft Drift case
- 03Shadow AI: the AI use the company never authorisedin preparation
