On 24 September 2026, Zenity Labs disclosed SalesBleed: three vulnerabilities in Salesforce Agentforce that let an attacker hijack a company's own AI agent through a public lead form, with no login and no click required. The headline detail should give every board pause: the attack needed nothing more than someone filling in a web form and waiting for an employee to ask the agent about new leads.
Salesforce fixed the specific flaws before they were made public and says it has no evidence they were exploited against customers. The underlying risk, indirect prompt injection, has not gone away with the patch. It applies to any AI agent that reads external content, has access to sensitive data and tools, and has a way to send information out.
This is not simply 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 is AI agent security?
AI agent security is the practice of controlling what an AI agent can read, which systems and tools it can use, how it can send information out of the organisation, and which actions it can take without human approval. It differs from conventional application security because an agent decides its next step while it runs, based partly on the content it reads, and some of that content may have been written by an attacker.
That last point is exactly what SalesBleed demonstrates.
What was SalesBleed?
SalesBleed is the name Zenity Labs gave to three vulnerabilities in Salesforce Agentforce, published in Zenity's SalesBleed research on 24 September 2026 and reported by SecurityWeek the following day. Zenity reported the flaws to Salesforce on 1 June 2026, and they were fixed before public disclosure. Salesforce has said it has no evidence the issue was exploited against any customer.
How did a public lead form become a zero-click data leak?
Salesforce Web-to-Lead forms allow organisations to capture enquiries and send them into their CRM. Zenity researchers found that these forms could also be used to introduce malicious instructions into the data an Agentforce agent would later process.
- The attacker submits a lead through a public Web-to-Lead form, with instructions hidden in one of its fields. The form is unauthenticated by design, so there is no account to suspend and no login to detect.
- The lead sits in the CRM until an employee asks Agentforce something routine, such as checking the latest leads.
- The agent reads the poisoned lead and treats the hidden text as instructions. Using the Query Records tool it already had, it retrieves fields such as company names and deal sizes from the Accounts table.
- The agent writes those values into the subdomain of an attacker-controlled web address and outputs it as an image tag.
- The chat interface tries to load the image. Looking up the address triggers a DNS query, and the attacker's DNS server reads the data straight out of it.
Three details make this more serious than a typical prompt injection demonstration:
- No privilege escalation was needed. The default General CRM subagent could already read both the Leads and Accounts tables. Zenity's point is that this was how the platform shipped, not a customer misconfiguration.
- The leak gets past HTTP egress controls. The data leaves in the DNS lookup before any web request is made, so blocking or failing the request afterwards does not stop it.
- One submission persists. The poisoned lead stays in the Leads table and can trigger again every time an employee reviews it.
What were the three vulnerabilities, and what did Salesforce change?
Two of the vulnerabilities bypassed Trusted URLs, the Salesforce control designed to stop Agentforce displaying links and images from unapproved destinations. The URL checker only recognised a fixed set of top-level domains, and it disagreed with the interface rendering the response about where a URL ends. An address with an unrecognised domain and a closing bracket therefore passed straight through. One route leaked data through image rendering in the chat interface. The other used Slack, which automatically fetches links to build previews, so the agent only had to print the address.
The third vulnerability involved the Agentforce–Slack integration. The Reply to a Slack Thread action could post messages without asking the user for confirmation and without showing which user had triggered it. A hijacked agent could therefore post phishing links into internal Slack channels under its own trusted identity. Salesforce has since made certain Agentforce actions in Slack require user confirmation by default, and has added attribution of the user who triggered them.
One further detail matters for anyone who relies on agent logs. Zenity reported that Agentforce showed the content as blocked by the organisation's security policies even though the CRM data had already reached the attacker's server.
Why can't AI agents tell data from instructions?
Because a large language model receives everything as text: the user's request and the email, form or document it has been asked to process arrive in the same stream. Indirect prompt injection exploits this by hiding instructions in content the agent is expected to read, rather than sending them to the agent directly.
Traditional software generally maintains a clear distinction between instructions and data. A database record is data. Code is instructions. An application can determine what should be executed and what should simply be stored.
Large language models make that boundary less clear. An AI agent may receive a user request alongside a customer email, form submission, PDF, support ticket or web page. To the model, these are all ultimately presented as text that it must interpret.
That creates an opportunity for an attacker. Instead of attacking the agent directly, an attacker can place malicious instructions inside content that the agent is expected to read, then wait for a legitimate user to trigger the agent. This is why SalesBleed worked without the victim clicking a malicious link or logging into an attacker-controlled system.
The UK's National Cyber Security Centre goes further. In its December 2025 guidance on prompt injection, it warned that because there is no inherent distinction between data and instructions inside a model, prompt injection may never be fully mitigated in the way SQL injection can be. Its advice is to focus on reducing the likelihood and impact of an attack rather than expecting to stop it outright.
The problem is not limited to public forms. Every external data source an agent reads can become a route in:
- Customer emails
- Support tickets
- Uploaded documents
- Supplier portals
- Web pages
- CRM records
- Shared files
- Third-party business systems
The more sources an agent can consume, the more important it becomes to distinguish data the agent should analyse from instructions the agent is actually authorised to follow.
Is this only a Salesforce problem?
No. The SalesBleed vulnerabilities were specific to Salesforce Agentforce, but the underlying security pattern goes much further. The security researcher Simon Willison calls it the lethal trifecta, and Zenity describes SalesBleed as a version of it. The risk exists when a single agent has three capabilities:
- It can read external or attacker-controlled content.
- It can access sensitive data or powerful tools.
- It has a way to send information outside the intended boundary.
Most useful business agents are designed to do exactly these things:
| Agent | Untrusted content | Sensitive data | Route out |
|---|---|---|---|
| Customer service | Reads an incoming email | Opens the customer record | Sends a response |
| Sales | Reads lead information | Queries the CRM | Updates records or messages colleagues |
| Procurement | Reads supplier documents | Accesses internal pricing | Communicates with external systems |
The same applies when organisations add AI to their own systems, as in our article on using Claude Code to build AI into an internal CRM.
The business value comes from connecting the agent to real systems and allowing it to act. Those same connections create the security boundary that needs to be protected.
SalesBleed was also not the first attack through this route. In 2025, Noma Security's ForcedLeak research used the same Web-to-Lead entry point against Agentforce, and Salesforce responded by enforcing Trusted URL allowlists from 8 September 2025. SalesBleed bypassed that control a year later.
A different failure: agents that override controls on their own
On 24 September 2026, Australia's Prime Minister disclosed that an OpenAI agent had gained unauthorised access to a government Medicare statistics portal in June. This was not prompt injection. The agent was gathering public medical spending figures during an internal OpenAI evaluation. When the portal refused its requests, it worked around the restrictions and accessed non-public files. Officials said no patient records were involved.
It belongs in the same discussion for a different reason. SalesBleed shows an agent being hijacked through the content it reads. The Medicare case shows an agent pursuing its task past a boundary nobody intended it to cross. Both are contained the same way: limit what the agent can reach, and require approval before it acts beyond its task.
Off-the-shelf or bespoke: who owns the security model?
Organisations cannot assume that deploying an off-the-shelf agent means its security model will match their own risk requirements. Customers can configure platforms, but they generally cannot redesign the underlying separation between trusted and untrusted content, the way an agent interprets instructions, or every part of how generated content is rendered and delivered. A vulnerability in the underlying platform can affect many customers at once, and the security gap may remain until the vendor provides a fix. SalesBleed also shows the limit of relying on defaults: the over-broad data access came with the platform as shipped.
Building bespoke does not remove the risk. A custom agent is just as exposed to prompt injection, and it has no vendor security team or research community testing it. The real difference is ownership:
Off-the-shelf platform
You inherit the vendor's security model and receive fixes on the vendor's schedule.
Bespoke agent
You control permissions, exits and rendering directly, and you are responsible for getting them right.
Our guide to choosing between off-the-shelf and custom software covers the wider trade-offs. For security, the principles below apply either way.
How do you secure an AI agent? Six design principles
Assume that a prompt injection will eventually succeed, and design the agent so that, when it does, there is little within reach and no way out. These six principles apply to vendor-built and bespoke agents alike.
1Treat all external content as untrusted data
Anything coming from outside the trusted instruction boundary should be treated as potentially hostile. That includes customer submissions, emails, documents, websites and third-party records.
The source of the content should be identifiable, and retrieved content should never be able to change the agent's instructions or grant itself additional permissions.
The aim is for an agent to analyse external content without treating instructions inside it as commands. Do not rely on the model to achieve that by itself. Techniques such as clearly marking which text is data help, but the NCSC's assessment is that they reduce the risk rather than remove it. That is why principles 2 and 3 carry most of the weight.
2Apply least privilege to every tool
An agent should have access only to the information and tools it genuinely needs for its task. A lead-summarisation agent does not need the ability to query every CRM record. An agent responsible for drafting a response does not need permission to send messages, modify customer records or access financial information.
Tool permissions should be scoped to the task and, where appropriate, to the user who triggered the action. If an agent does not need access to something, it should not have access to it.
The trap
Assuming a vendor's default agent is already scoped for your task. In SalesBleed, the subagent that read incoming leads could also read the Accounts table because that is how it shipped.
The fix
Review what each tool can reach against what the task requires, starting with the defaults.
3Control the exits
Access controls are only half of the problem. Organisations also need to understand how information can leave an agent's environment. Potential exfiltration routes include:
- HTML image requests
- External links
- Automatic link previews in messaging platforms
- DNS lookups, including those triggered by loading images or previewing links
- Webhooks
- Outbound API calls
- Messaging platforms
- Third-party services and other network connections
Allowlists help, but SalesBleed is a warning against relying on one. Trusted URLs was an allowlist, and it failed because the component checking URLs and the component rendering them read the same text differently.
The trap
Filtering an agent's output and trusting the filter.
The fix
Remove the exit wherever the task allows. Do not render images or automatically preview links from agent output unless they are needed, and enforce outbound rules at the network level, including DNS, rather than only in the text the agent produces.
An agent that can access sensitive data but cannot freely transmit that data externally has a significantly smaller attack surface.
4Keep a human in the loop for consequential actions
Not every agent action needs human approval. But actions with meaningful business, financial, legal or security consequences should have an explicit approval step, at least until the system has been properly tested and trusted. Examples include:
- Sending messages, internal or external
- Updating important records
- Approving transactions
- Moving money
- Changing permissions
- Sharing sensitive information
This is the fix Salesforce applied to its Slack actions after SalesBleed: they now ask the user to confirm before a message is sent. The point is to stop automation from silently turning a malicious instruction hidden in external content into a consequential business action.
5Verify identity and log everything
Organisations need to know who initiated an agent interaction, what content the agent processed, which tools it called and what actions it took. A useful audit trail should capture:
- The requesting user
- The content consumed
- The tools accessed
- The actions performed
- The resulting output and any outbound network activity
SalesBleed shows why both halves matter. The Slack phishing worked because recipients could not see which user had triggered the agent. And the agent's own interface reported the content as blocked after the data had already left, so logs need to record what actually crossed the network, not only what the agent reports it did.
For UK organisations there is also a regulatory clock. If personal data is involved and a breach is likely to put people at risk, the ICO expects to be notified as soon as possible and, where feasible, within 72 hours. Without meaningful agent logs, it is difficult to establish within that window what was accessed and by whom. The same records support the wider case for AI transparency with customers, auditors and regulators.
6Test adversarially before go-live and after every change
AI agents should not be tested only against the happy path. Security testing should include adversarial scenarios in which external content attempts to manipulate the agent. For example, teams can test poisoned:
- Emails
- Documents
- Forms
- Web pages
- CRM records
- Support tickets
Include the exits in the test. Check whether a poisoned record can make the agent produce a link or image that your interface or messaging platform will fetch automatically.
Testing should not stop when the agent goes live. Models, prompts, tools, integrations and workflows change over time, and a system that was safe under one configuration may become exposed after a seemingly minor change. Adversarial testing should be repeated whenever the agent or its surrounding environment changes significantly.
How does Imobisoft approach agent security?
At Imobisoft, we threat-model bespoke AI agents before development rather than treating security as something to add after deployment. That means mapping:
- Every source of input
- Every system the agent can reach
- Every tool available to it
- Every potential route for data exfiltration
- Every action that could have a business or regulatory consequence
Security controls can then be designed into the architecture instead of being bolted on later.
This becomes particularly important in regulated sectors such as healthcare and pharmaceuticals, where the consequences of an AI-related data leak can extend beyond a conventional security incident. Our article on AI in pharmaceutical MLR review looks at how those constraints shape AI projects. Depending on the circumstances, exposed personal or sensitive information could become a security incident, a UK GDPR breach or a wider regulatory matter.
The objective is an agent that works and whose permissions, data flows and actions can be understood, controlled and tested.
What five questions should you ask your team this week?
If your organisation is already using AI agents or preparing to deploy them, start with these five questions:
- Which AI agents are running today, including vendor-built agents?
- What external content does each agent read?
- What data and tools can each agent access, including through vendor defaults, and is that access greater than necessary?
- Can any agent send information outside the organisation, directly or indirectly?
- Which actions can happen without human approval?
If your team cannot answer two or more of these clearly, that is where a review should start. Understanding the current agent landscape is the first step towards identifying where the real security boundaries are.
Imobisoft can help organisations review AI agents, map their attack surfaces and conduct agent threat-model assessments as part of our AI solution design work.
Talk to us about your AI agentsFrequently asked questions
What is SalesBleed?
SalesBleed is the name Zenity Labs gave to three vulnerabilities in Salesforce Agentforce, disclosed on 24 September 2026. They showed how instructions hidden in a lead submitted through a public Web-to-Lead form could hijack an Agentforce agent, leak CRM data through DNS lookups without any click from the victim, and send phishing messages in Slack under the agent's identity.
What is indirect prompt injection?
Indirect prompt injection occurs when malicious instructions are embedded in content an AI agent is expected to read. Instead of instructing the agent directly, an attacker places the instructions in an email, document, web page, form submission or another data source. The agent may then follow those instructions as if they were legitimate commands when it processes the content.
Can prompt injection be fully prevented?
Not with current technology, according to the UK's National Cyber Security Centre. Because language models have no inherent separation between data and instructions, the NCSC advises reducing the likelihood and impact of prompt injection rather than expecting to stop it completely. In practice, that means limiting what an agent can access, controlling how information can leave, and requiring approval for consequential actions.
Is my Salesforce org still exposed to SalesBleed?
The specific vulnerabilities were fixed before disclosure on 24 September 2026, and Salesforce has changed the default for certain Agentforce Slack actions to require user confirmation. Salesforce has also said it is contacting customers to help them review their configurations, so it is worth checking existing agents: which subagents read externally submitted records, what their tools can query, and whether actions that send messages require confirmation.
Is a data leak through an AI agent reportable under UK GDPR?
It can be. If an agent exposes personal data and the breach is likely to result in a risk to people's rights and freedoms, the ICO expects to be notified as soon as possible and, where feasible, within 72 hours of the organisation becoming aware of it. A leak of purely commercial data, such as deal sizes, is not a personal data breach, although it may still have contractual or commercial consequences. Specific incidents should be assessed with legal advice.