The SalesBleed findings in Salesforce Agentforce show that an AI agent's real authority is decided by whoever can put words in front of it. Enterprises need to govern agent actions by the trust level of their inputs, and treat an agent's voice in internal channels as a credential.
Many enterprises accept text from anyone on the internet and store it inside a trusted system. A sales lead form is one of the oldest. Someone types a name, a company, and a note, and the record lands in the CRM. For years, the security concern with those fields was script injection. With AI agents reading the same records, the concern has changed shape. The risk is now malicious instructions.
An agent's effective authority in any given moment is not the authority in its role definition. It is whatever its tools permit, directed by whoever authored the least-trusted text in its context.
A Web Form Becomes a Requester
Researchers at Zenity Labs disclosed three vulnerabilities in Salesforce Agentforce on September 24, 2026, collectively named SalesBleed. In the first chain, an attacker planted instructions in a public Web-to-Lead submission. The instructions sat dormant until an employee asked an agent to help with recent leads. The agent then processed the poisoned record, queried account data using its own query tool, packed values such as a company name and deal size into a hostname, and rendered an image tag pointing at that hostname, which caused a lookup to attacker-controlled infrastructure without the employee noticing. A variant achieved the same result through Slack's link unfurling.
Two of the three findings were bypasses of Salesforce's Trusted URLs control that enabled zero-click data exfiltration. The third was in Agentforce's Slack integration, and it matters most for identity teams. Agentforce's Reply to a Slack Thread action did not require user confirmation before sending and did not show visible attribution to the invoking user. Combined with the URL bypass, an external attacker could use a poisoned lead to make the agent post phishing messages into internal Slack threads under the agent's trusted identity, and a malicious insider could do the same while remaining anonymous.
Salesforce Fixed It. The Pattern Remains.
Zenity reported the issues on June 1, 2026, and Salesforce confirmed the next day that it was working on fixes. Zenity verified the URL-filtering fix on August 19 and the Slack attribution fix on August 20. The last change, requiring user confirmation by default, was confirmed on September 21. Salesforce has said it has seen no evidence of exploitation.
In September 2025, Noma Security disclosed ForcedLeak, which used the same Web-to-Lead entry point to plant instructions. It exfiltrated data to an allow-listed domain that had expired, and which an attacker could have purchased for as little as $5. Salesforce responded by re-securing the domain and enforcing a URL allow list.
The recurrence points to a class of problem, not one vendor’s mistake. Two different research teams, a year apart, reached sensitive CRM data through the same public form by finding gaps in output filtering. Filtering was improved each time, and each time the underlying arrangement stayed the same: an agent with meaningful privileges was reading text written by strangers and acting on it.
Privilege Is Set by the Weakest Input
The standards community has already described this arrangement plainly. The OWASP Top 10 for LLM Applications (2025 edition) ranks prompt injection first (LLM01) and defines indirect prompt injection as instructions arriving in external content such as websites or files that the model later processes. It also states that, given how these models work, a guaranteed prevention method may not exist. Its companion entry on excessive agency (LLM06) attributes the damage to three root causes: excessive functionality, excessive permissions and excessive autonomy.
Read together, those entries lead to a conclusion that identity teams should adopt as a design rule. When a lead form is in the context, the author of that form is, functionally, the requester. The employee who asked the question supplied the trigger, but the anonymous submitter supplied the instructions. The full chain, from anonymous form to agent to tool to Slack post, is a privilege escalation path that no access review lists.
That reframing matters because it changes where controls belong. If untrusted inputs can influence how an agent exercises its privileges, then a guardrail that only tries to recognize malicious text is working on the wrong layer. OWASP's guidance points to the right one: enforce authorization in downstream systems rather than relying on the model to decide whether an action is allowed, and execute actions in the context of the specific user with the minimum privileges necessary.
This is also why conventional access reviews typically miss the risk. A review asks what an identity has been granted and whether the grant is still justified. For a traditional service account, that is the right starting point. For an agent, the grant is only half the picture. The other half is who can steer it, and that population is defined by data flows rather than by any entitlement a reviewer will ever see.
An Agent's Voice Is a Credential
The Slack finding adds a dimension that access reviews rarely consider. Internal messaging channels run on implicit trust. Employees act on messages from colleagues and from familiar service accounts because the platform has already authenticated the sender. An agent that can post into those channels without per-message attribution holds something more valuable than read access to records. It holds the organization's trust in its own communications. Zenity points out that an injection arriving through a CRM lead could affect Slack because the same agent could reach both, which widens the blast radius.
From an identity perspective, the ability to speak as a trusted internal principal should be governed the way organizations govern the ability to send email as an executive or to post as a corporate account. It is a privilege. Grant it narrowly, and make every use traceable to the human who asked for it.
Visibility Is Part of the Problem
The Slack finding shows the gap in practice. Recipients of the phishing replies saw the agent's identity and nothing that pointed to the person whose request triggered it. Zenity describes a malicious insider walking away with nothing tracing back to them. Incident responders cannot scope an agent-mediated exfiltration if the only record is the agent's own description of what it did. Closing the gap starts with identity visibility: knowing which agents exist and what they can reach.
The obvious objection: vendors are shipping controls, confirmation prompts are now the default for the riskiest Slack actions, and Salesforce says it has seen no evidence of exploitation. That is thin comfort when agents leave so little record of what they did. Some teams will reasonably conclude that the platform fix closes their exposure. The fixes address these three reported attack chains. The pattern remains: any agent that reads externally submitted records, renders links or images, and holds tool access to sensitive data has the same three ingredients in one place.
Where to Start Without Starting Over
Few organizations can pause agent deployments, and none should have to rebuild them. The practical path is to apply existing identity disciplines to a new kind of principal, starting where the exposure is concentrated.
- Inventory agents exposed to untrusted content. Identify which agents, including nobody registered, read content that originates outside the organization: lead forms, support tickets, inbound email, uploaded documents, web pages. Those agents process content from their least-trusted input and should be scoped accordingly. OWASP's recommendation to segregate and clearly mark untrusted content is a starting point, not a boundary.
- Separate reading from acting. An agent that summarizes leads does not need tools that query account tables beyond the records in scope, and it certainly does not need the ability to post into internal channels. OWASP's examples of excessive functionality, where a tool intended for one purpose carries capabilities for others, are a useful checklist for reviewing an agent's tool set. Least privilege for AI agents starts with this separation.
- Treat outbound actions in trusted channels as privileged operations. Require confirmation from the invoking human, attach visible attribution to every message, and log the triggering request alongside the action. Salesforce's change to require confirmation by default is the right direction, and customers should verify it is in force across their own configurations. Zenity notes that a single click can turn the requirement off, which brings the attack path back.
- Run agent actions under the invoking user's authority. Wherever the platform allows, ensure an agent cannot reach data the person who asked could not reach. That change limits what a poisoned record can accomplish because the attacker's instructions are constrained by the human's permissions rather than a service identity's. This is least privilege applied to the agent's session.
Legacy integrations and busy sales teams will make each of these steps uneven. Partial progress still reduces risk, because the attack needs all three ingredients: untrusted input, broad tool access, and an unattributed outbound action. Remove any one, and the chain loses much of its reach.
Conclusion
Zenity has confirmed the fixes for the reported SalesBleed chains, and the vendor and researchers handled the disclosure responsibly. The durable lesson is architectural. An AI agent does not have one privilege level. Its actions can be influenced by the authors of the text it reads, including the least trustworthy among them. Filtering that text has been a contest so far. Limiting what the agent is permitted to do, and ensuring every action in a trusted channel carries a human name, is one defenders can win. Control the privilege, control the risk. The principle that secures human administrators extends to.
About the Author: Len Noe is a Solutions Architect at BeyondTrust, Transhuman, Podcaster, International Cyber Security Speaker, Author, Technical Evangelist, and Biohacker with 11 implanted microchips. A former blackhat with more than 30 years in technology, he has presented in over 70 countries and is featured in the documentary I Am Machine, which premiered at DEF CON 2025.
About BeyondTrust
BeyondTrust is the global leader in privilege-centric identity security protecting Paths to Privilege™. Identity alone doesn’t create risk. Privilege does. As human, machine, and AI agent identities explode across every environment, BeyondTrust is the only company built to discover, control, and secure privilege across all of them from a single platform. Trusted by 20,000+ customers, including 75 of the Fortune 100, and recognized as a multi-category leader by top industry analysts, BeyondTrust reframes identity security from a management problem into a strategic advantage.
Learn more at www.beyondtrust.com.
Len Noe — Solutions Architect at BeyondTrust https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3PCr_xavQmiEMoyU85ZMpX_iG3zMpS9AycFSOHVSCUFYI1b17QDm5u6ShoRTN2QGLpY5rsraKPLztD8lwjAcHtlDe33pGsKT9BKZEtv71fRd8wS4Rbn4UhyY4vCKyXJlU91KzGJ28_Yuw66pggtlAt_-X-nuy8FV9UxA_7CygvmiKVD9B7ovrCjzaNwE/s1600/Len.png
