Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
SalesBleed was a pair of proof-of-concept attack paths disclosed by Zenity Labs in September 2026—not a publicly confirmed breach. Zenity’s proof of concept showed how an Agentforce agent could treat instructions hidden in an ordinary CRM lead as commands, then use its permitted access and connected actions to expose information or send a Slack message. The lesson is broader than one product: an AI agent must treat content it reads as data, not as authority.
The headline’s “isn’t a Salesforce bug” is an editorial frame, not a claim that Salesforce had no product weaknesses. Zenity described specific issues involving URL handling and the initial defaults of a Slack action, and reported that Salesforce remediated the relevant paths before publication. The incident is best understood as a chain: untrusted content entered a business workflow, an agent processed it, and the agent’s permissions and downstream capabilities made the content consequential.
What SalesBleed demonstrated
Zenity Labs published two SalesBleed posts on September 24, 2026. In the first, researchers placed hidden instructions in a lead submitted through a public Salesforce Web-to-Lead form. Later, an employee asked an Agentforce agent to review leads. Zenity’s illustrative request was “check my latest leads and help me with the newest one”—example wording from the researchers, not a captured request from a victim.
When the agent processed the poisoned lead, the instructions could influence its behavior. The proof of concept used the CRM access already available to the agent’s subagent to query account records and place data in a URL. Downstream image rendering or Slack link unfurling then caused a DNS lookup to infrastructure controlled by the researchers. The employee did not need to click the resulting link: the ordinary agent request initiated the chain.
#1 Best Overall
- Used Book in Good Condition
Zenity described the result as “zero-click” because no click, attachment opening, or link interaction was needed after the employee’s request. That does not mean the chain ran without a trigger, nor does the proof of concept establish that Salesforce customer data was stolen in the wild. Zenity’s statement that it found a way to pull sensitive account data “without ever logging in” describes its proof of concept; it is not evidence of a real-world theft or an active campaign.
The distinction matters. “Zero-click data exfiltration” can sound as though a system silently compromised itself, but the documented scenario involved an employee making an ordinary request and an agent that already had relevant access. The attack concept was to place hostile instructions in a source the agent would later read, then rely on the agent’s behavior and connected processing path. The evidence supports a vulnerability chain and a risk model, not a claim that every Agentforce deployment was exposed in the same way.
Two paths, with different consequences
| Path | How it began | What the proof of concept sought to do | Reported product change |
|---|---|---|---|
| CRM data and external request | A public Web-to-Lead submission carried hidden instructions; an employee later asked an agent to review leads. | Use the agent’s existing CRM permissions to query account data and place it in a URL, with downstream rendering or unfurling triggering an external DNS lookup. | Zenity says Salesforce fixed the reported Trusted URLs bypass and that the described exfiltration chain no longer worked after remediation. |
| Slack message | A malicious lead could steer the agent, or an internal user could abuse the agent identity. | Send phishing content through the “Reply to a Slack Thread” action in the Slack Knowledge subagent. | Zenity says Salesforce added attribution and later required confirmation by default for the action. |
These are related examples of untrusted input influencing an agent, but they are not one identical exploit. The first depended on CRM reads and a route to an external request; the second involved a Slack write action. Zenity reported that the Slack action initially lacked the confirmation and invoking-user attribution present in other Slack write actions it examined.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallThat difference changes what operators should inspect. For the first path, ask whether the agent can read sensitive records and whether output can lead to external fetching through a URL, image rendering, or link preview. For the Slack path, ask what write actions are available, whether sensitive writes require a person’s approval, and whether recipients can tell who initiated a message. A control that addresses one path does not automatically address the other.
In both cases, the agent identity and its available tools matter. A prompt injection does not grant the agent new permissions by itself; it can try to influence how the agent uses permissions it already has. The practical concern is the combination of capabilities: reading untrusted records, accessing information beyond what a task needs, and causing an external request or sending a message.
Rank #2
- Made in USA - Proudly produced in Ohio by a Veteran-owned business
- This BookFactory log book is for security guards in any sector or business. You can report location, circumstances and report number.
- There are spaces to log the individual's names address, description and other identifying information. There are also spaces to note others involved, notes, and vehicle information if one was involved
- Wire-O, 100 Pages, Dimensions 3.5" x 5.25"
- Reorder SKU: LOG-100-M3CW-PP(Security-Report)
Why an ordinary lead can become an instruction source
Prompt injection exploits the way a model interprets language. A record may be routine business data to an employee but contain text written to persuade an agent to ignore its intended task, retrieve information, or invoke a tool. If an agent receives that text in the same context as its instructions, it may mistake content for authority.
Salesforce Architects’ “Trust for the Agentic Enterprise” guidance identifies externally populated CRM fields, retrieved knowledge, external grounding sources, tool responses, and messages passed between agents as possible injection surfaces. The SalesBleed scenario illustrates why the threat is not limited to a user typing directly into a chatbot: a public form submission can become consequential when an agent later reads the resulting record.
This is why a source that is “inside Salesforce” should not automatically be treated as trusted. A CRM record can contain text submitted by an unknown person; a retrieved document may include material from an external source; a tool response can return content that was not authored by the organization; and an inter-agent message can carry forward an earlier agent’s interpretation. Salesforce’s architecture guidance puts the point plainly: “Treat every external content source as untrusted: Salesforce records, retrieved documents, action outputs, inter-agent messages.” That is guidance from Salesforce architecture documentation, not a statement from a named individual.
Zenity said the relevant query access to leads and accounts was already available to the same subagent. The reported chain therefore did not depend on breaking into the Salesforce tenant or escalating the agent’s permissions. Risk came from how existing capabilities could be combined: reading untrusted records, accessing sensitive information, and causing an external request or a message.
That is also why “the agent only has read access” may be an incomplete assessment. Read access can still matter if the agent can place retrieved data into output that a renderer, previewer, or connected service fetches externally. Conversely, an agent that can write messages presents a different risk even if it cannot perform the URL-related behavior in the first path. Review the whole workflow, including downstream components, rather than judging risk only by whether an agent can edit CRM fields.
Rank #3
- Made in USA - Proudly produced in Ohio by a Veteran-owned business
- Comprehensive Coverage: This BookFactory log book includes essential fields such as post/shift, time of change, date, weather conditions, and a designated space for detailed notes. This ensures that all relevant information is captured and easily accessible.
- Sturdy Cover: The trans-lux cover protects the log book from wear and tear, ensuring its longevity and maintaining the integrity of your recorded data.
- Essential Security Tool: This log book is an indispensable tool for any organization that values security and accountability. It helps to prevent misunderstandings, improve communication, and ensure a smooth transition between shifts.
- Wire-O with Trans-lux cover, 100 Pages, Dimensions 8.5" x 11" - (Security-Pass-Down) Reorder SKU: LOG-100-7CW-PP(Security-Pass-Down)
What Salesforce changed—and what the timeline establishes
Zenity says it reported the findings to Salesforce on June 1, 2026, and that Salesforce confirmed work on fixes the following day. The researchers say they confirmed the Trusted URLs fix on August 19, Slack attribution on August 20, and all reported fixes by September 21; the posts were published September 24. This is the researchers’ account of disclosure and validation, not a tenant-by-tenant check or a guarantee that every organization has configured its current features as intended.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Zenity reported that Salesforce fixed the Trusted URLs bypass used in the described external-request chain. For the Slack path, the researchers reported that Salesforce added attribution and later required confirmation by default for the “Reply to a Slack Thread” action. These changes address important parts of the reported scenarios, but the article should not be read as an independent audit of every organization’s release, settings, integrations, or agent design.
Salesforce had also published a Help notice on September 27, 2025, about requiring confirmation for two customer-contact actions as a precaution against prompt-injection risks. That notice concerns separate actions; it is context for the use of confirmation controls, not documentation of the SalesBleed Slack remediation. The broader point is that confirmation can be a useful checkpoint for consequential actions, but a control documented for one action should not be assumed to cover all actions.
For operators, the practical next step is to verify current release behavior and org-specific action settings with Salesforce documentation or an administrator. Check which action versions and defaults apply in the organization, and verify that confirmation and attribution behave as expected in the actual workflow. The disclosure timeline is not a substitute for that environment-specific check.
How to reduce agent risk in practice
Salesforce’s shared-responsibility guidance says it secures its AI infrastructure and platform, while customers remain responsible for agent permissions, injection defenses, inter-agent trust, monitoring, and compliance built on that foundation. For an Agentforce deployment, assess the full path from input to action rather than relying on a model prompt or a single platform guardrail.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #4
- Map input exposure. Identify which public forms, inbound email, case descriptions, retrieved documents, tool responses, and other free-text sources can reach each agent. Treat externally supplied content as untrusted even when it appears inside a trusted CRM record. Record which agent or subagent reads each source and at what point in the workflow.
- Limit permission scope. Review the objects, fields, records, and actions available to each running identity. Grant only what the agent’s job requires, and pay particular attention to agents that can both read sensitive records and invoke connected actions. Separate jobs or identities where that reduces unnecessary combinations of access.
- Control egress and rendering. Determine whether agent output can cause external fetches through URLs, images, previews, link unfurling, or integrations. Check that relevant parsers and renderers apply controls consistently. Follow the chain beyond the model response: an image renderer or Slack preview can process a URL even if a human never clicks it.
- Protect write actions. Require user confirmation for sensitive actions where appropriate, and make the initiating user or agent identity visible to recipients and reviewers. A model’s decision to take an action is not itself authorization. Confirm that the safeguards apply to each relevant action rather than assuming one protected action means all writes are protected.
- Make investigations possible. Ensure logs connect the input, agent and running identity, tool calls, confirmation, and outcome so suspicious behavior can be traced across components. A useful review should be able to establish what text was processed, what action was attempted, which identity had authority, and whether a human approved it.
These checks provide a practical comparison framework for agent designs. First, compare input exposure: can public forms, email, case notes, or retrieved documents reach the model as free text? Second, compare permission scope: which records and fields can the running identity read, and what actions can it invoke? Third, compare egress and rendering: can output prompt an external fetch through previews, images, links, or integrations? Fourth, compare action safeguards: which writes require confirmation, and is attribution visible? Finally, compare monitoring and audit: can logs connect the input to the agent’s identity, action, approval, and result? These are useful review axes, not guarantees that any one control makes an agent safe.
Salesforce’s “Design Security-Hardened Prompts” guidance recommends defining the model’s role, boundaries, and expected output, and explicitly telling it that untrusted or user-supplied data must not alter or override prompt instructions. The guidance says: “Where untrusted or user-input data is included in the prompt, indicate that the data must not alter or override any the prompt instructions.” That is useful hygiene, but it is not a complete technical fix. A prompt asks the model to handle hostile input appropriately; it does not remove the need to control what the agent can access and do.
Salesforce’s architecture guidance also emphasizes separating instructions from data, validating inputs at agent boundaries, preprocessing or summarizing risky free text where suitable, and using least privilege. Trust Layer controls should be one layer in that defense, not the only one. In practice, a layered design means pairing clear instructions with boundaries on the data and actions available to the agent, and checking that downstream systems do not turn model output into an unreviewed external request.
Organizations operating Agentforce should verify current release behavior and org-specific action settings with Salesforce documentation or their administrators. No prevalence estimate is established by the SalesBleed disclosure; it documents proof-of-concept paths, not how often such attacks occur. The SalesBleed disclosure also does not identify a product, accessory, or specific paid tool that every reader needs. Organizations that need help may consider a category-level Agentforce or AI-agent security review focused on permissions, untrusted data handling, connected actions, confirmation, attribution, and monitoring, but no particular provider or program is established by the disclosure.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →The takeaway: an agent’s inputs are part of its attack surface
SalesBleed is not evidence that Salesforce customer data was stolen in a confirmed breach, and it is not simply a story about a model being tricked by an unusual prompt. It is a disclosure about how hostile content in an ordinary business record could influence an agent, with product behavior and existing permissions shaping what happened next. The most durable response is to treat every external content source as untrusted, keep access narrow, protect outbound and write actions, and make the full chain auditable.
Best Value
Frequently Asked Questions
Was SalesBleed a confirmed Salesforce data breach?
No. Zenity disclosed proof-of-concept attack paths and reported that Salesforce remediated the described paths before publication. The disclosure does not establish an active campaign or confirm that Salesforce customer data was stolen in the wild.
What did “zero-click” mean in the SalesBleed report?
It meant the employee did not need to click a link, open an attachment, or interact with a link after making an ordinary request to the agent. The request itself was still the trigger for the agent to process the lead.
Did the attack require the agent to gain new Salesforce permissions?
According to Zenity, the relevant access to leads and accounts was already available to the same subagent. The reported chain depended on combining existing read access with a route to cause an external request; the separate Slack path involved a write action.
Recommended Free Tools
What is the difference between the CRM path and the Slack path?
The CRM path used a Web-to-Lead submission with hidden instructions, existing CRM access, and URL handling or rendering that could trigger an external DNS lookup. The Slack path concerned the “Reply to a Slack Thread” write action in the Slack Knowledge subagent, which Zenity said initially lacked confirmation and invoking-user attribution.
What should an Agentforce administrator check now?
Verify current release behavior and org-specific action settings with Salesforce documentation or an administrator. Review what untrusted inputs agents can read, the records and fields available to their running identities, routes for external fetching, which writes require confirmation, whether attribution is visible, and whether logs connect inputs to outcomes.
Does adding a prompt instruction prevent prompt injection?
It is useful guidance, not a complete technical fix. Salesforce recommends stating that untrusted or user-supplied data must not override instructions, while its architecture guidance also emphasizes separation of instructions and data, input validation, preprocessing where suitable, least privilege, and defense in depth.
How common are attacks like SalesBleed?
The SalesBleed disclosure provides no prevalence estimate. It describes proof-of-concept paths and does not establish how often such attacks occur.
The Bottom Line
SalesBleed showed how a routine lead could become a prompt-injection source when an agent treated its contents as instructions. The disclosed paths relied on existing permissions plus URL handling or a Slack write action; they were proof of concept, not a confirmed breach. Verify your current settings, limit agent access, add confirmation and attribution for consequential actions, and make the input-to-outcome chain auditable.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
