Summary
- Zenity demonstrated a zero-click Agentforce attack beginning with a public, unauthenticated Web-to-Lead submission containing malicious instructions.
- The prompt could use the agent’s existing CRM permissions to query account data and encode that information into DNS requests.
- Salesforce fixed the Trusted URLs bypass before publication, closing the specific attack chain described by the researchers.
Researchers found an indirect prompt-injection chain in Salesforce Agentforce that allowed an unauthenticated attacker to plant instructions in a public lead submission and later use a trusted agent to extract CRM information through DNS.
The research against Salesforce Agentforce was published by Zenity Labs on 24 September. Zenity said Salesforce investigated and remediated the reported issue before publication.
The attack began with Web-to-Lead, Salesforce’s public lead-capture mechanism. An attacker could submit a seemingly ordinary lead containing hidden instructions without authenticating to the target Salesforce organisation.
The payload remained in the CRM until an internal user later asked Agentforce a routine question about recent leads.
At that point, according to Zenity’s technical analysis, the agent could process the attacker-controlled content as instructions rather than simply as data.
The injected prompt directed the General CRM subagent to query the Accounts table using permissions the agent already possessed. Zenity’s proof of concept extracted fields such as company names and deal sizes, although the researchers said other data available through the same tool could also have been targeted.
The information was then placed into a subdomain controlled by the attacker and returned in an HTML image tag.
Zenity found that Salesforce’s Trusted URLs redaction layer and the browser rendering the response disagreed over whether certain malformed strings constituted valid URLs. That allowed a crafted value to survive the redaction process while still causing the browser to attempt DNS resolution.
The resulting DNS request carried the selected CRM information to an authoritative server controlled by the attacker. Zenity noted that the subsequent HTTP request did not need to succeed because the information had already left through the DNS lookup.
The victim did not have to click a link, open an attachment, or interact directly with anything submitted by the attacker. The employee only had to perform a routine action that caused the agent to inspect the poisoned lead.
The attack therefore combined three distinct trust decisions: accepting externally submitted business data, giving an agent access to internal CRM records, and allowing rendered output to trigger external network activity.
The agent did not need a separate privilege-escalation vulnerability because the default General CRM subagent used in Zenity’s test already had access to both Leads and Accounts data.
That distinction is important for enterprise-agent security. A system can remain within its assigned technical permissions while still performing an action that the user who invoked it never intended.
Indirect prompt injection is consequently not just an input-filtering problem. Agents increasingly consume records, emails, tickets, documents, collaboration messages, and other content produced by people outside the organisation. If those inputs can influence tool use, the boundary between data and instruction becomes part of access control.
Salesforce fixed the URL-redaction bypass, and Zenity said the complete attack chain described in its research no longer works.
The broader architecture remains relevant beyond Salesforce. Any agent that consumes externally supplied records, has access to sensitive internal data, and can cause outbound network interactions contains the same categories of dependency even where the specific SalesBleed vulnerabilities are absent.
The incident provides a concrete example of agent security moving beyond model behaviour alone. Tool permissions, input provenance, rendering, network egress, and the scope of the identity under which the agent operates all form part of the effective security boundary.
