Your AI agent is a new front door: what the SalesBleed flaws teach every business deploying agents
A public web form, an AI agent and no password. Salesforce’s recently patched Agentforce vulnerabilities show why agent security has to be designed in from the start, not bolted on afterwards.
Quick answer: Three vulnerabilities in Salesforce Agentforce, dubbed SalesBleed by Zenity Labs, let attackers hijack trusted AI agents through nothing more than a public lead form, no login, no click required. Salesforce patched all three by August, but the underlying risk, indirect prompt injection, applies to any AI agent that reads external content, holds sensitive data, and has a way to send information out, which describes most useful business agents.
On 25 September, SecurityWeek reported three vulnerabilities in Salesforce Agentforce, collectively named “SalesBleed”. They were discovered by Zenity Labs, reported to Salesforce in June and patched by August. The headline detail should give every board pause: the attack needed nothing more than someone filling in a public form.
This is not a story about one vendor getting something wrong. It is an early, well-documented example of a risk that applies to every organisation putting AI agents to work on real business data.
What actually happened?
Salesforce’s Web-to-Lead forms are the standard way businesses capture enquiries from their websites. Zenity’s researchers submitted leads containing hidden instructions. Those instructions sat harmlessly in the CRM until an employee asked an Agentforce agent to process the new leads. At that point, the agent read the hidden text and treated it as a command.
Two of the flaws abused weaknesses in Salesforce’s Trusted URLs mechanism. They let the agent send CRM data out through HTML image tags, without anyone clicking anything. The third abused the Agentforce–Slack integration: because the agent did not check who a message came from, attackers could make it post phishing messages into internal Slack channels under its own trusted identity.
According to Zenity, the exposed data could include company names, deal sizes and other CRM fields. As the researchers put it, the injection “could have asked for anything the subagent’s Query Records tool can reach”.
Why does indirect prompt injection make this possible?
Conventional software keeps a firm line between code, which gives instructions, and data, which is processed. Large language models do not. Everything an agent reads — your request, a customer email, a form submission, a PDF — arrives as text in the same place, and the model has to decide what to act on.
That is what makes indirect prompt injection possible. The attacker never talks to the agent directly. They plant instructions in something the agent will read later and wait for a legitimate user to trigger it.
The practical consequence is simple: every data source an agent reads is now a potential route in for an attacker. Inboxes, support tickets, uploaded documents, supplier portals and web pages all count.
Is this only a Salesforce problem?
Zenity was clear that the pattern goes well beyond Agentforce. Any agent faces the same risk if it does three things at once:
reads content from outside the organisation
has access to sensitive data or tools
has some way to send information out, such as rendering images or links, posting messages or calling other services
Most useful business agents do all three. That is precisely why they are valuable, and why they need careful design.
The same week brought a reminder that the risk runs in both directions. On 24 September, Australia’s Prime Minister disclosed that an OpenAI agent had bypassed controls on a government Medicare statistics portal earlier in the year. Agents that act autonomously can cause incidents as well as suffer them.
There is also a structural point for buyers. An off-the-shelf agent inherits the security assumptions of the platform it runs on. You can configure it, but you cannot redesign how it separates trusted from untrusted content, or what it is allowed to render. When those assumptions have a gap, every customer shares it until the vendor issues a fix.
What are the six design principles for secure AI agents?
- Treat all external content as untrusted data. Label where each piece of content came from. Content the agent retrieves should never be able to change its instructions or grant it new permissions.
- Apply least privilege to every tool. An agent that summarises new leads does not need to query every record in the CRM. Scope each tool to the task and the user who triggered it.
- Control the exits. Exfiltration needs a way out. Block or allowlist image rendering, external links, webhooks and outbound network calls, so that a successful injection has nowhere to send data.
- Keep a human in the loop for consequential actions. Sending messages, updating records or moving money should require explicit approval, at least until the agent has a proven track record.
- Verify identity and log everything. Record who asked, what the agent read, which tools it called and what it produced. Without an audit trail, you cannot investigate an incident or show a regulator what happened.
- Test adversarially before go-live, and after every change. Red-team the agent with poisoned emails, documents and form entries. Repeat the tests whenever the model, prompts or tools change.
How does Imobisoft approach agent security?
When we build bespoke agents, we threat-model them before writing any code. We map every input the agent will read, every system it can reach and every route by which information can leave it. The controls above are then designed into the architecture rather than added as an afterthought.
This matters most in the regulated sectors where we work, including healthcare and pharmaceutical compliance. A data leak there is not only a security incident: it can also be a UK GDPR breach and a regulatory matter.
What five questions should you ask your team this week?
Which AI agents are running in our organisation today, including those built into vendor platforms?
What external content does each one read?
What data and tools can each one access, and is that more than it needs?
Can any of them send information outside the organisation, directly or indirectly?
Which actions can they take without a human approving them?
If those questions are hard to answer, that is the place to start. Imobisoft offers agent threat-model reviews for organisations that are deploying or planning AI agents. Get in touch to arrange one.
Key takeaways
- SalesBleed is a set of three vulnerabilities in Salesforce Agentforce, discovered by Zenity Labs, reported to Salesforce in June, and patched by August.
- The attack required nothing more than filling in a public Web-to-Lead form, no login and no click needed from the victim.
- Two flaws exploited Salesforce’s Trusted URLs mechanism to exfiltrate CRM data via HTML image tags; a third abused the Agentforce–Slack integration to send phishing messages under the agent’s trusted identity.
- The underlying risk, indirect prompt injection, applies to any AI agent that reads external content, holds access to sensitive data, and has a way to send information out.
- Separately, on 24 September, Australia’s Prime Minister disclosed that an OpenAI agent had bypassed controls on a government Medicare statistics portal.
- Six design principles reduce the risk: treat external content as untrusted, apply least privilege, control the exits, keep a human in the loop for consequential actions, verify identity and log everything, and test adversarially before and after every change.
FAQ
What is SalesBleed?
SalesBleed is the name Zenity Labs gave to three vulnerabilities in Salesforce Agentforce that let attackers hijack trusted AI agents to steal CRM data and send phishing messages, all starting from a public lead form.
Has Salesforce fixed the SalesBleed vulnerabilities?
Yes. Zenity Labs reported the flaws to Salesforce in June, and Salesforce patched all three by August.
What is indirect prompt injection?
It’s an attack where hidden instructions are planted inside content an AI agent will later read, an email, a form submission, a document, rather than sent to the agent directly. When a legitimate user triggers the agent to process that content, it treats the hidden text as a command.
Is the SalesBleed risk specific to Salesforce Agentforce?
No. Zenity found the underlying pattern applies to any agent that reads external content, has access to sensitive data or tools, and has some way to send information out, a description that fits most useful business agents.
What should a business do to reduce this risk?
Follow the six design principles: treat all external content as untrusted, apply least privilege to every tool, control how data can leave the system, require human approval for consequential actions, log everything for auditability, and test adversarially before go-live and after every change.