AIAgentic AIPrompt InjectionData Protection

SalesBleed: A Contact Form Talked Salesforce's AI Agent Into Leaking the CRM

October 15, 2026 · Brian Deitch

Zenity Labs disclosed SalesBleed in late September: three vulnerabilities in Salesforce Agentforce that let an anonymous attacker plant instructions in a public web form and have Salesforce's own AI agent quietly ship CRM data out the door. Salesforce has fixed all three, and says it has no evidence the issue was exploited against any customer. It's still the cleanest example I've seen of why AI agents are a brand-new attack surface.

The Attack, Step by Step

Here's the flow, per Zenity's write-up:

  1. The attacker submits a lead through a public, unauthenticated Web-to-Lead form. Hidden in the lead is a prompt injection.
  2. Nothing happens. The payload just sits there, waiting.
  3. An employee asks their Agentforce agent to do something completely normal, like review new leads.
  4. The agent reads the poisoned lead and follows the hidden instructions. It queries the Accounts table, pulling things like company names and deal sizes.
  5. The agent tucks that data into the subdomain of an attacker-controlled URL.
  6. The interface renders it as an image tag, or Slack unfurls the link. Either way, a DNS lookup fires automatically, and the attacker's nameserver logs the stolen data.

Nobody clicked anything. That's the zero-click part.

Two of the bugs were bypasses of Salesforce's Trusted URLs mechanism, which is supposed to stop agents from talking to untrusted destinations. One used a top-level domain that wasn't on the list, and the other used malformed URLs that confused the parser. The third bug was in the Slack integration, which Zenity said could also turn the agents into a social-engineering mechanism for phishing employees.

The Line That Matters

"The injection didn't need to escalate privileges, the permissions were already there."

— Zenity Labs

That's the whole story. The agent that read leads could also read Accounts. Nothing was hacked in the traditional sense. The attacker didn't break the agent's permissions. They borrowed them.

Why This Keeps Happening

Every agent that combines these three things is exposed:

  • It reads untrusted input. A web form, an email, a support ticket, a document.
  • It has access to sensitive data. Because that's the point of the agent.
  • It can reach the outside world. A URL, an image, a link preview, a DNS lookup.

Put all three in one agent and a stranger's text can become your agent's instructions. Prompt injection isn't a bug you patch once. It's a property of how these systems read.

What to Do About It

  • Scope agent permissions like you'd scope a user. An agent that triages leads shouldn't be able to read every account.
  • Treat everything an agent reads from outside as hostile. Forms, emails, and tickets are attacker-controlled input.
  • Control egress, including DNS. If an agent can resolve any domain, it can leak data one subdomain at a time.
  • Require a human confirmation for outbound actions. Salesforce did exactly this for Slack messages by default after the report.

Bottom Line

We spent years teaching people not to trust what shows up in their inbox. Now we're deploying agents that read everything, trust everything, and act on it with real permissions. Zero trust has to apply to the agent too: least privilege, inspected traffic, and no automatic path to the internet. Otherwise your contact form is an admin console with extra steps.

Sources: Zenity Labs: SalesBleed, SecurityWeek

salesforceagentforcesalesbleedzenityprompt-injectiondns-exfiltrationslackai-agents
All postsDiscuss on LinkedIn