On September 24, 2026, the security firm Zenity Labs disclosed SalesBleed, a set of three vulnerabilities in Salesforce Agentforce that could let a single untrusted lead hijack a trusted AI agent, silently pull sensitive CRM data out to attacker-controlled infrastructure, and turn an enterprise agent into a phishing vehicle. Salesforce has patched the reported bypasses. The reason SalesBleed is worth understanding is not that one product had a flaw. It is that the flaw is the textbook failure mode of AI agents, and every company deploying them is exposed to the same category of problem. This piece walks through what happened and why this keeps happening.
SalesforceWhat SalesBleed actually is
Two of the three flaws enable zero-click data exfiltration: sensitive Salesforce data transmitted to attacker infrastructure without an employee clicking or approving anything. The third lets an attacker weaponize the trusted identity of an Agentforce-connected Slack agent to send phishing messages to employees from inside the organization. "Zero-click" is the phrase that should catch the eye. Most enterprise attacks still need a human to take the bait. These did not.
The entry point is a feature almost every Salesforce customer uses. Web-to-Lead lets external users submit data through a public form that flows directly into CRM records. It is designed to accept input from strangers, which is the whole point of a lead form. Zenity found that an attacker could plant hidden prompt injection payloads inside those submissions. When a trusted Agentforce agent later processed the record, it read the attacker's instructions as if they were legitimate content and acted on them.
How a lead form became a data-exfiltration path
No employee had to click anything. The agent's own authority did the work once it treated attacker text as instructions.
Salesforce patched the reported Trusted URLs bypasses within about two weeks; the underlying pattern applies to any agent that reads untrusted content.
The exfiltration itself exploited Agentforce's Trusted URLs mechanism, an allowlist meant to control where the agent can send data. Zenity discovered the mechanism did not properly recognize top-level domains and that certain character sequences could tamper with URL parsing, letting data slip past the allowlist to a destination the attacker controlled. Salesforce addressed those specific bypasses within roughly two weeks of the June 1 disclosure.
Why this is not really a Salesforce story
It is tempting to read SalesBleed as a Salesforce problem. It is more accurate to read it as a demonstration of the structural weakness in giving a language model tools and untrusted input at the same time. Security researchers call the dangerous combination the lethal trifecta: an agent that has access to private data, is exposed to untrusted content, and has a way to send data out. When all three are present, a prompt injection buried in the untrusted content can turn the agent's own capabilities against its owner.
The lethal trifecta: all three at once is the danger
Any one of these is fine on its own. Together, a prompt injection in the untrusted content can use the private-data access and the outbound channel to exfiltrate. Breaking any single leg blunts the attack.
Framing after security researchers' "lethal trifecta" for LLM agents; the Agentforce mapping is this article's analysis of the disclosed facts.
Agentforce hit all three at once. It had access to private CRM data. It ingested untrusted content, the lead form. And it could reach external URLs. The injection did the rest. Crucially, the model behaved exactly as designed. It read text and followed instructions. The vulnerability lived in the assumption that text arriving through a lead form is data to be processed rather than instructions to be obeyed, and a language model does not natively draw that line.
The model behaved exactly as designed. It read text and followed instructions. The flaw was assuming lead-form text was data, not instructions.
On why prompt injection keeps recurring
The confused-deputy problem, in modern clothes
This is an old idea in a new form. A confused deputy is a program tricked into misusing its own legitimate authority on behalf of an attacker. The Agentforce agent was a highly capable deputy: trusted, connected to the CRM and to Slack, and authorized to act. The attacker never needed their own access. They only needed to get instructions in front of a deputy that could not tell whose instructions they were.
That framing explains why patching one allowlist bug does not close the category. Salesforce fixed the Trusted URLs bypasses, which is the right and necessary response to the specific report. But the underlying tension, that an agent with real authority is reading text from people who do not have that authority, is present wherever agents are deployed against real business data. The next entry point might be an email the agent triages, a support ticket it reads, a document it summarizes, or a calendar invite it processes. Each is untrusted content flowing toward a trusted deputy.
What defenders can actually do
There is no single switch that removes prompt injection, but the trifecta framing points at concrete mitigations, because breaking any one leg helps.
Constrain where data can go. The exfiltration needed a path out. Strict, correctly parsed allowlists for outbound destinations, and treating URL handling as a security boundary rather than a convenience, remove the easiest exit. SalesBleed showed how fragile that parsing can be, which is the argument for making it strict by default.
Keep agents least-privileged. An agent that can read the entire CRM and reach arbitrary URLs is a bigger deputy than most tasks require. Scoping data access and tool permissions to the job at hand shrinks the blast radius when, not if, an injection lands.
Put a human in front of consequential actions. Zero-click was the severity multiplier here. Requiring explicit approval before an agent sends data externally or messages staff turns a silent compromise into a visible prompt someone can decline.
Separate instructions from data. The root cause is that models blur the two. Designing pipelines so that content ingested from untrusted sources is clearly demarcated, and never elevated to command status, is the harder but more durable fix.
These are the same principles behind the approval gates and scoped credential boundaries that careful agent platforms, Metir AI among them, build in as defaults: an agent should authenticate to only what a task needs, and consequential steps should pass a checkpoint rather than run silently. SalesBleed is a clean illustration of why those defaults matter, not decoration.
The honest takeaway
Zenity's disclosure and Salesforce's quick patch are how the process is supposed to work: a researcher finds a serious flaw, reports it privately, and the vendor fixes it before wide exploitation. The uncomfortable part is what SalesBleed represents rather than what it was. Enterprises are wiring capable agents into their most sensitive systems faster than the security models for those agents have matured, and the failure mode is consistent and predictable. Treating every agent as a deputy that will, at some point, be handed hostile instructions is not pessimism. On the current evidence, it is the realistic design assumption.
Sources:
- SalesBleed: 0-Click Data Exfiltration in Agentforce | Zenity Labs
- Zenity Labs Uncovers SalesBleed, 3 Salesforce Agentforce Flaws Enabling Zero-Click CRM Data Theft | Yahoo Finance
- Zero-Click Vulnerabilities in Salesforce Agentforce Expose Wider AI Agent Risk | Infosecurity Magazine
- 'SalesBleed' Flaws in Salesforce Agentforce Enabled Zero-Click Data Exfiltration | SecurityWeek
- Salesforce Indirect Prompt Injection Vulnerability Enables 0-click Data Exfiltration | Cyber Security News
Image credits
Header and in-body image: Salesforce Tower and neighboring towers, San Francisco, by The wub, via Wikimedia Commons, CC BY-SA 4.0. Illustrative of Salesforce as the vendor; not related to the vulnerability itself.