A Public Lead Form Could Hijack Salesforce's AI Agent

A public lead form can become input for an AI agent with access to a private CRM and workplace chat. Zenity Labs’ September 24 report, SalesBleed, showed how a poisoned Salesforce Web-to-Lead submission could steer Agentforce toward account data or a Slack reply sent under the agent’s identity. Salesforce told Dark Reading it had no evidence the reported issues were exploited against customers and said it had fixed the paths.

For a small B2B team, the risk sits in a familiar chain. Marketing captures a lead, the CRM stores it, and an agent qualifies or follows up. If that agent can read more than the submitted record or write to connected channels, the public form sits inside the agent’s security boundary. HubSpot’s work to bring CRM context into multiple AI tools shows how quickly that access is spreading across marketing workflows.

Nicholas Lorizio, founder of AstuteTechnologists, put the problem plainly in a public LinkedIn post. “A public web form just became a way to steal CRM data.”

The line summarizes Zenity’s demonstrated exposure. It doesn’t report a customer breach. The researchers disclosed the issues to Salesforce on June 1. Salesforce confirmed on June 2 that it was investigating. Zenity published its first report on September 24, after confirming that all reported fixes were in place by September 21.

A lead became an instruction

Salesforce’s Web-to-Lead tool lets a company collect prospect information on its website and create lead records in Salesforce. That keeps a sales process moving, and it means the CRM accepts text from people outside the company.

Zenity’s first report described an attacker placing hidden instructions in a form submission. Later, an employee asked Agentforce to review a lead. The agent could treat the text as a direction, then use existing CRM access to query lead and account data. A crafted image or URL could trigger a DNS request that carried data out of the environment. In the researchers’ demonstration, the attacker needed no login and the employee needed no click.

The important detail for marketing operations is that Agentforce used the CRM permissions already assigned for the employee’s task. The injected lead changed what the agent tried to do with that access.

Zenity’s second report followed the path into Slack. Before the fix, the default “Reply to a Slack Thread” action could send a message without asking the user to confirm it or showing which user had invoked the agent. Combined with the URL-filtering gap, a poisoned lead could prompt a message that looked like it came from a trusted workplace agent. SOAM has covered Slack’s new controls for agent access; SalesBleed shows the risk when a trusted agent also consumes untrusted CRM data.

Tamir Ishay Sharbat, Zenity’s director of security research, told Dark Reading, “The more power you give agents, the more dangerous they are.” His comment points to permission design. Each extra data source or write action gives a compromised instruction more places to go.

The CRM’s old trust boundary has moved

Marketing teams already treat lead forms as a source of spam, fake identities, and low-quality data. SalesBleed adds a new question: what can an AI agent do with whatever arrives through that form?

The issue reaches beyond Salesforce. Any workflow that feeds public text into an agent with access to private records or communication tools creates a similar trust boundary. A marketing team may not own the agent platform, but it often owns the form, campaign fields, enrichment rules, and the handoff that sends a lead into automated follow-up.

Michael Bargury, Zenity’s co-founder and CTO, told Dark Reading that “the entire market is building black boxes.” That creates a logging problem. If the only record is a short agent summary, a team may struggle to learn which lead triggered an action. It may be unclear which records the agent read or why it sent a message.

The fix requires reviewing the whole workflow, including the form. Limit an agent to the lead fields it needs. Keep account-wide data out of lead-triage tasks unless there’s a clear reason to expose it. Require a person to approve messages and other external actions. Make sure logs show the user, the records read, and the tools called.

Then test the form itself. Submit a harmless instruction-like string in a test environment and confirm that the agent treats it as untrusted lead content. Check that it can’t use a lead to send Slack messages, query unrelated accounts, or route data to a destination the company hasn’t approved.

Salesforce says it strengthened Trusted URLs and changed default Slack actions to require confirmation. Zenity says the reported attack paths were closed and tested by September 21. Those changes matter, but configuration still matters too: Zenity warns that an administrator can disable confirmation with a single setting.

For marketers, the takeaway is practical. When a lead goes into an AI workflow, the form is no longer just a conversion point. It’s an input to software that may hold customer data and speak inside the company. That deserves a place in the CRM and campaign security review.