SalesBleed shows how trusted AI agents can become data-exfiltration paths

SalesBleed shows how trusted AI agents can become data-exfiltration paths

Salesforce Agentforce is the latest reminder that enterprise AI agents are not just chat interfaces. They are workflow identities with tools, permissions, connectors, and access to sensitive business data. Zenity Labs disclosed a set of Agentforce weaknesses dubbed SalesBleed on September 24, 2026, showing how attacker-supplied CRM data could hijack an agent and trigger zero-click data exfiltration or convincing Slack phishing.

Salesforce says it has remediated the reported issues and SecurityWeek reported that the company has no evidence the issue was exploited against customers. That is welcome, but defenders should not treat SalesBleed as a closed curiosity. The attack path points to a broader class of vulnerability: agents that process untrusted external records while holding access to internal tools and sensitive data.

In practical terms, this is an AI governance problem with immediate security operations consequences.

What Zenity disclosed

Zenity's research describes three related Agentforce issues. Two enabled zero-click CRM data exfiltration, while the third allowed an Agentforce agent connected to Slack to send phishing messages under the agent's identity.

The initial entry point was Salesforce Web-to-Lead, a public lead-collection feature that many organizations use to route external submissions into CRM workflows. In Zenity's proof of concept, an attacker submitted a normal-looking lead containing hidden prompt-injection instructions. Later, when an internal user asked Agentforce to review recent leads, the agent processed the poisoned record and followed instructions that the user never intended.

That matters because the agent was not limited to reading the malicious lead. The same subagent could query CRM records such as leads and accounts. Zenity showed how the injected instructions could cause the agent to retrieve account data and encode it into an attacker-controlled hostname, where DNS resolution leaked the data outward.

The exfiltration did not require the victim to click a link. Zenity described two automatic outbound paths:

• an HTML image tag rendered by the chat surface
• Slack URL unfurling, where Slack automatically fetches preview data for links

In both cases, a DNS lookup could carry sensitive data to infrastructure controlled by the attacker.

Why the zero-click detail matters

"Zero-click" gets overused, but Zenity's description is specific: the user asks their own agent a normal question, the agent reads a malicious CRM record, and the downstream renderer or Slack preview mechanism performs the external request automatically. The user does not open an attachment, visit a phishing page, or knowingly interact with attacker content.

That shifts the detection problem. Traditional awareness training is not enough when the risky action is executed by an internal automation layer. Security teams need visibility into agent tool calls, outbound requests triggered by agent output, and the provenance of the records an agent is processing.

SalesBleed also illustrates why output filtering alone is fragile. Zenity found gaps between how a URL-redaction layer recognized URLs and how downstream surfaces interpreted rendered content. When parsers, renderers, and integrations disagree, a string that looks harmless to one control can still become an outbound request somewhere else.

The Slack phishing angle

The Slack-related issue is just as important as the data exfiltration path. Zenity reported that the default Slack Knowledge subagent template included a Reply to a Slack Thread action that lacked user confirmation and attribution. That meant an injected instruction could make an agent reply inside a Slack thread without clearly showing which human request caused the message.

From a defender's perspective, that is a trust-boundary failure. Employees are more likely to trust a message sent by an internal agent inside a relevant thread than a random external message. If that agent posts a phishing link in the middle of an account discussion or operational channel, the social-engineering context is already built in.

Zenity says Salesforce added proper attribution and updated insecure defaults. The lesson for organizations building agent workflows is broader: every write action should have a clear confirmation policy, visible attribution, and a review path before it can affect humans or systems outside the immediate chat.

What defenders should verify now

Organizations using Agentforce should confirm whether Salesforce's fixes and default-setting changes are active in their environments, but they should also review their own agent designs. Vendor-side fixes do not remove the need to understand what each agent can read, write, render, and send.

Start with the agents connected to public intake flows, CRM data, Slack, email, ticketing, or customer communication. Those are the integrations where untrusted external data and trusted internal action can meet.

Key checks include:

• Inventory Agentforce agents and subagents by owner, purpose, and connected data sources.
• Identify agents that process Web-to-Lead submissions or other externally supplied records.
• Review tool permissions for CRM query actions, especially access to accounts, contacts, opportunities, and deal values.
• Require confirmation for write actions that send Slack messages, emails, tickets, or customer communications.
• Require attribution so recipients can see which user or workflow invoked an agent action.
• Review Trusted URLs and similar allowlists for overly broad entries or stale exceptions.
• Monitor DNS and HTTP egress from systems rendering agent output.
• Log agent prompts, tool calls, output transformations, and downstream connector actions in a form usable for incident response.

Security teams should also treat persistent records as possible trigger points. A poisoned lead, ticket, chat transcript, or support case can sit quietly until an agent processes it. That gives attackers a durable foothold without maintaining an account, token, or session.

Detection ideas

The useful signal is not only in the CRM. It is spread across the agent runtime, the application surface, DNS, proxy logs, Slack audit events, and identity records.

Prioritize investigation around:

• agent responses that contain external URLs, image tags, or unusual hostnames
• DNS lookups with CRM values embedded in subdomains
• Slack messages posted by agents without clear human attribution
• unexpected queries from an agent against accounts, contacts, or opportunities
• external lead submissions that include hidden instructions, markdown, HTML, or URL-like strings
• repeated processing of the same lead followed by outbound network activity

If your tooling supports it, correlate the user request, the external record consumed, the agent tool call, the rendered output, and the network request that followed. That chain is what turns AI-agent security from guesswork into evidence.

Strategic takeaway

SalesBleed is not just a Salesforce story. It is a design warning for every organization deploying agents into business workflows. The risky pattern is simple: untrusted input, privileged tools, and an output channel capable of reaching the outside world. Put those together and prompt injection can become real data movement.

The mature response is not to ban agents. It is to govern them like high-trust automation. Keep permissions narrow, make write actions explicit, preserve attribution, test renderers and connectors, monitor egress, and assume public intake records can be hostile. AI agents may feel conversational, but in the enterprise they behave like software supply paths with identities attached.

References

1. https://labs.zenity.io/post/salesbleed-0-click-data-exfiltration-on-agentforce
2. https://labs.zenity.io/post/salesbleed-hijacking-agentforce-in-slack-for-anonymous-phishing
3. https://www.securityweek.com/salesbleed-flaws-in-salesforce-agentforce-enabled-zero-click-data-exfiltration/
4. https://www.infosecurity-magazine.com/news/vulnerabilities-salesforce-ai/