A poisoned lead could make Salesforce's AI agent leak data. It is patched, but the pattern is not.

What the researchers found

Give an AI agent access to your customer database and the ability to read whatever strangers type into your website, and you have built something powerful. You may also have built a door. Researchers at Zenity Labs just showed how wide that door can swing.

In research published on 24 September 2026 under the name SalesBleed, the Zenity team demonstrated a chain of three weaknesses in Salesforce Agentforce, the company's flagship AI agent platform, that let an attacker quietly pull sensitive customer-relationship-management data out of a company without ever signing in and without any employee clicking a thing. "We found a way to pull sensitive account data out of Salesforce Agentforce without ever logging in, or requiring the victim to click anything," the researchers wrote. A separate part of the same work showed how a trusted agent wired into Slack could be turned into an anonymous phishing machine, posting messages to employees using the agent's own identity.

How the attack worked

The elegance, and the danger, is that every ingredient was a normal feature doing its job. The entry point was a Web-to-Lead form, Salesforce's standard tool for letting anyone on the public internet submit their details straight into a company's CRM. Instead of a sales inquiry, the attacker submits hidden instructions. Those instructions sit dormant in the record until an employee does something entirely routine: asks their Agentforce agent to look at the new lead.

At that moment the agent reads the poisoned text and treats it as a command. This is indirect prompt injection, the now-familiar failure in which an AI system cannot tell the difference between data it is supposed to process and instructions it is supposed to obey. Salesforce had built a defense for exactly this, a redaction layer called Trusted URLs that strips untrusted links out of an agent's output. Zenity got around it by exploiting parsing gaps, using top-level domains the filter did not recognize, such as .fun, and stray termination characters like brackets that the redaction and the browser interpreted differently.

With the guardrail bypassed, the data left through channels no one thinks of as exits. The agent's response included HTML image tags pointing at attacker-controlled servers, and Slack's automatic link-preview feature fetched them. The stolen records, company names and deal sizes, were encoded into the subdomains of DNS lookups, so the information leaked out one hostname query at a time. As Zenity put it, "our payload asked for company names and deal sizes, but the injection could have asked for anything the subagent's Query Records tool can reach."

The reassuring part

Before anyone panics, the important context: this is not a live breach. Zenity disclosed the findings privately to Salesforce on 1 June 2026. Salesforce investigated, hardened the Trusted URLs mechanism, and the fixes were confirmed by 18 August, more than a month before the research went public. There is no evidence anyone exploited SalesBleed in the wild, and the specific holes Zenity reported are closed. By the standards of the field this is responsible disclosure working as designed: find it, report it, fix it quietly, then explain it once users are protected.

So the alarming name oversells the current risk. SalesBleed is a proof of concept and a warning, not an ongoing emergency, and Salesforce comes out of it looking cooperative rather than careless.

Why it is bigger than Salesforce

The reason to pay attention anyway is in the shape of the problem, not the specific bug. Zenity is blunt that the pattern is not Salesforce-specific. Any AI agent that does three ordinary things at once, reads records submitted by outside parties, renders links or images back to a user, and holds tools that can reach sensitive data, has the same three ingredients sitting in the same place. That describes a very large share of the enterprise agents companies are racing to deploy this year.

It also lands squarely on a debate playing out in public. Just this week the US Federal Trade Commission chair argued that when an AI agent causes harm the developer is liable, not the tool, because audit trails show agents doing what they were told. SalesBleed is a clean illustration of the same principle from the attacker's side: the agent was not rogue, it was obedient, and it obeyed the wrong person. The failure was not the model developing a will of its own. It was a system that could not tell whose instructions to trust.

What to do if you run agents

The practical lessons are unglamorous and immediate. Treat any content an agent ingests from outside the organization, form submissions, emails, uploaded files, as untrusted input, not as trusted instructions. Scope an agent's tool permissions to the minimum it needs, so a hijacked agent cannot reach the whole database. Watch the exits, including exotic ones like DNS queries and link-preview fetches, because exfiltration rarely uses the front door. And do not treat a vendor's built-in filter as the last line of defense, since SalesBleed was, at its heart, a story about a filter that could be parsed around.

Our take

SalesBleed is the good kind of scary. Nobody lost data, the flaws are patched, and the disclosure was handled the way it should be. What makes it worth reading is that it turns an abstract worry, prompt injection, into a concrete, end-to-end theft using nothing but standard features. The enterprise AI agent boom is built on giving software both broad data access and the habit of reading whatever the world sends it, and those two things in one place are a security posture, not just a convenience. The specific door is shut. The architecture that opened it is being shipped everywhere. Companies deploying agents should assume a researcher, or someone less friendly, will go looking for their version of this, and build as if the agent will eventually be told to betray them.