TL;DR

Zenity Labs disclosed SalesBleed, a set of attack chains against Salesforce Agentforce in which attacker controlled data entering Salesforce through a public Web-to-Lead form could later act as an indirect prompt injection when an employee asked Agentforce to process that lead. The employee's request itself could be entirely benign; the malicious instructions resided in the CRM record.

Zenity demonstrated two major outcomes. First, the hijacked agent could query CRM data available through its existing permissions and exfiltrate it through attacker controlled URLs. By exploiting discrepancies in Salesforce's Trusted URLs redaction and downstream URL handling, the researchers demonstrated zero-click DNS based exfiltration, including through Slack's automatic URL unfurling. Second, the same injection path could cause Agentforce to use its Reply to a Slack Thread action to distribute phishing links. At the time of Zenity's testing, that action did not require user confirmation and did not identify the invoking user, allowing the message to appear under the trusted agent's identity.

Salesforce investigated and remediated the reported issues. Zenity confirmed the Trusted URLs bypass fix on August 19, the Slack attribution fix on August 20, and all fixes, including requiring confirmation by default for the affected Slack action, by September 21, 2026. Salesforce told SecurityWeek that it had no evidence that the reported issue had been exploited against customers.

What Happened

The external attack path began with Salesforce's Web-to-Lead functionality. Because Web-to-Lead is intended to accept externally submitted information, an attacker did not need an authenticated Salesforce account to submit a lead containing malicious instructions. Zenity placed an indirect prompt injection inside a lead field. The malicious record then remained stored in Salesforce until an internal employee interacted with it through Agentforce.

When the employee later made a normal request such as asking Agentforce to review recent leads, the agent retrieved the poisoned record and interpreted the embedded instructions as instructions to execute. In Zenity's data exfiltration demonstration, those instructions caused Agentforce's Query Records capability to access information in the Accounts table and place retrieved values into an attacker controlled hostname. Importantly, Zenity states that no privilege escalation was required: the General CRM subagent already had access to both Leads and Accounts.

The attacker still needed the generated URL to survive Agentforce's Trusted URLs protection. Salesforce describes Trusted URLs as an administrator-controlled allowlist intended, among other things, to prevent agents from generating unapproved URLs following prompt injection. Zenity found parsing discrepancies: the redaction mechanism used a fixed set of recognized TLDs and interpreted some URL termination characters differently from the downstream renderer. This allowed specially constructed URLs to escape redaction while still being interpreted as network-reachable URLs downstream.

Zenity demonstrated two zero click exfiltration paths. An HTML image reference could cause the client to resolve an attacker controlled hostname automatically; alternatively, when Agentforce was used through Slack, Slack's URL unfurling behavior could automatically retrieve the URL. Because sensitive information was encoded into the hostname, the DNS lookup itself delivered the data to the attacker's authoritative DNS server. No malicious link had to be clicked.

Agentforce to Slack Phishing

The second SalesBleed report demonstrated a different objective using the same underlying trust problem.

Agentforce's Slack integration provides actions including Slack search and Reply to a Slack Thread. Salesforce documentation confirms that Slack subagents can perform actions such as searching Slack and replying to threads.

Zenity found that, during its testing, Reply to a Slack Thread differed from other Slack write actions it examined in two security-relevant ways:

• No user confirmation was required before the reply was sent.
• The resulting reply did not identify the user whose interaction invoked the action.

Consequently, an indirect prompt injection stored in a malicious CRM lead could direct Agentforce to find Slack conversations and post phishing messages into them. The internal employee who triggered the chain by asking Agentforce about the lead did not need to approve the resulting Slack message, while recipients saw the message originating from the Agentforce agent without attribution identifying the invoking user.

Zenity also demonstrated that the previously identified URL redaction bypass could allow the attacker controlled phishing URL to survive filtering. The researchers additionally found that URLs could be hidden behind benign looking Markdown link text.

This is significant because the initial attacker controlled content entered through Salesforce, while the resulting attacker directed action occurred in Slack. The agent effectively bridged the two trust domains.

Core Attack Pattern

The SalesBleed chain demonstrates a compound agentic security failure rather than reliance on a single vulnerability: Untrusted external data → persistent CRM record → agent retrieval → indirect prompt injection → authorized tool access → security control bypass → cross application action/exfiltration.

The critical distinction is that the attacker did not directly compromise the employee's Salesforce credentials or escalate Agentforce's privileges. The agent already possessed the capabilities required to read the relevant CRM data and, when configured for Slack, interact with Slack. The prompt injection redirected those legitimate capabilities toward an attacker-selected objective. Zenity explicitly notes that its exfiltration chain did not require privilege escalation because the relevant permissions were already present.

The attack also demonstrates why agent security cannot rely solely on model level resistance to prompt injection. Salesforce documents prompt injection detection as one component of the Einstein Trust Layer, while permissions and agent guardrails form additional security layers. In SalesBleed, the consequential security boundary ultimately depended on what the compromised reasoning path was allowed to read, generate, and execute.

Attack Across The AI Kill Chain

Based strictly on the demonstrated external-attacker Slack-phishing chain, the following stages are materially present.

1. Reconnaissance — Active. Through agent input surface discovery, the attacker identified Salesforce's public Web-to-Lead interface as an external data path, giving attacker controlled content a way into CRM data that Agentforce would later consume.
2. Trust Manipulation — Active. By abusing implicit trust in the data context, the attacker stored malicious instructions as ordinary CRM lead data, which Agentforce then processed when it retrieved that record during a legitimate employee interaction.
3. Input / Instruction Weaponization — Active. Using indirect prompt injection, the attacker embedded instructions in a Web-to-Lead field rather than supplying them directly to the agent.
4. Reasoning-Time Execution — Active. Through premise control and goal redirection, the malicious lead steered Agentforce to follow attacker supplied instructions rather than remaining constrained to the employee's benign lead processing request.
5. Tool Invocation — Active. In an abuse of tool execution, the hijacked agent used legitimate capabilities, including CRM queries and, in the phishing chain, Slack search and thread reply functionality, to carry out actions the invoking employee never intended.
6. Privilege Escalation — Bypassed entirely. Zenity explicitly reports that privilege escalation was unnecessary: the General CRM subagent already possessed access to Leads and Accounts.
7. Lateral Movement — Active. Through cross-environment trust domain pivoting, attacker controlled instructions that originated in Salesforce caused Agentforce to perform attacker directed actions in Slack.
8. Persistence — Active. As a form of RAG and data-source persistence, the malicious lead remained stored in the Leads table and could trigger again whenever an agent reviewed it. Zenity explicitly describes the stored record as a durable foothold.
9. AI-Native C2 — Bypassed entirely. The disclosed phishing chain does not establish an interactive or sustained command and control channel between the attacker and the compromised agent.
10. Action on Objectives — Active. Through data exfiltration via AI, Zenity separately demonstrated attacker directed phishing messages posted into Slack and zero click extraction of CRM information through DNS requests generated from agent output.

Mitigation Strategy

Treat externally sourced data as untrusted agent input

Web forms, CRM records, support tickets, email, documents, and similar sources should not become trusted instructions merely because they have entered an enterprise datastore. Content entering an agent's context from these sources should be inspected for embedded instructions and other prompt injection patterns before ingestion or before being provided to the model.

For SalesBleed specifically, inspecting Web-to-Lead content for embedded prompts before Agentforce consumed the record could have provided an earlier opportunity to break the chain at Stage 3.

Enforce URL allowlisting at the action boundary

Salesforce's Trusted URLs mechanism is specifically intended to restrict unapproved external URLs, and Salesforce recommends explicitly defining required domains rather than relying on broad wildcard permissions.

Organizations should apply URL allowlisting to outbound agent actions and content, but SalesBleed demonstrates an important requirement: validation and enforcement must use the same canonical interpretation of a URL as the downstream component that will render, resolve, or fetch it. Zenity's demonstrated bypass depended on the redactor and renderer interpreting the same string differently.

For the Slack phishing path, a correctly enforced URL allowlist that excluded the attacker controlled domain would have prevented the malicious link from reaching recipients even after the agent had been hijacked.

Require confirmation for consequential write actions

Salesforce documentation supports requiring user confirmation before agent actions, and Salesforce has previously described confirmation as a security measure against prompt injection risk.

For actions such as sending messages, modifying records, publishing content, transferring files, or interacting with external systems, confirmation provides a deterministic checkpoint between compromised reasoning and real world execution.

In SalesBleed, requiring confirmation for Reply to a Slack Thread would have given the employee an opportunity to detect that the proposed Slack message did not correspond to the original request.

Preserve human attribution

Agent generated actions in collaborative environments should retain the identity of the human interaction that caused them.

Zenity confirmed that Salesforce added proper invoker attribution to the affected Slack action on August 20. Attribution does not prevent prompt injection itself, but it removes the anonymity property demonstrated in the insider scenario and gives recipients additional provenance for evaluating an agent generated message.

Minimize tool and data scope

SalesBleed's exfiltration demonstration worked without privilege escalation because one subagent could process attacker controlled Leads while also querying sensitive Accounts information.

Organizations should therefore evaluate permissions not simply as "Does the agent legitimately need this tool?" but as the combination of untrusted inputs, accessible sensitive data, and available actions.

Reducing any one of these capabilities can reduce the blast radius after successful prompt injection.

Monitor intent-to-action divergence

Runtime monitoring should correlate the user's original request with subsequent agent actions. A request to review a new sales lead followed by broad CRM queries and Slack messages to unrelated channels represents a meaningful behavioral divergence even when every individual tool invocation is technically authorized.

This provides an important defense beyond simple tool allowlisting: Query Records and Reply to a Slack Thread may both be legitimate Agentforce capabilities. The security signal is the context in which they are invoked and the sequence connecting them.

UnifAI

Prompt Injection / Untrusted Content Policy — inspect externally sourced CRM/RAG content for embedded instructions before that content is supplied to the LLM.

URL Allowlist Policy — prevent agent generated output or downstream actions from resolving, rendering, unfurling, or communicating with destinations outside explicitly approved domains. Canonicalization must occur before allowlist evaluation.

Sensitive Action Confirmation Policy — require HITL confirmation before agent initiated sensitive actions like delete, purge.

Trusted Agent, Untrusted Lead

SalesBleed illustrates a central problem in agentic security: trusted execution can amplify untrusted data.

The external attacker in Zenity's demonstration did not need Salesforce credentials, direct access to Slack, or additional Agentforce privileges. Attacker controlled instructions entered through a legitimate public data ingestion path, persisted inside the CRM, and were later incorporated into the context of a trusted enterprise agent. The agent then had legitimate capabilities capable of crossing application and data boundaries.

The incident also demonstrates why preventing prompt injection alone is insufficient. Agentic systems need multiple independent boundaries around what enters the model, what data it can access, what destinations it can communicate with, and what consequential actions it can execute without human approval. If reasoning integrity fails, these deterministic controls become the remaining barriers between compromised reasoning and enterprise impact.

Salesforce has remediated the specific vulnerabilities Zenity reported. Zenity states that the demonstrated Slack chain no longer works by default, while warning that administrators can disable confirmation. Salesforce separately says it has no evidence that the reported issue was exploited against customers.