SalesBleed: when a single untrusted lead can hijack your AI agent
Research published in late September 2026 by Zenity Labs, and reported by The Register on 24 September, described three vulnerabilities in Salesforce Agentforce that together allowed an attacker to hijack a trusted enterprise AI agent using nothing more than a submitted lead. Salesforce has addressed the issues. The reason the research matters is not that one vendor had a bug; it is that it demonstrates, concretely, what goes wrong when an agent treats untrusted input as instruction.
What the researchers found
Zenity Labs grouped three issues under the name SalesBleed. Two of them enabled zero-click exfiltration of sensitive CRM data to attacker-controlled infrastructure — no employee had to click a link or approve an action for the data to leave. The third allowed an attacker to borrow the trusted identity of an Agentforce-connected Slack agent and deliver phishing messages to staff from inside the organisation, arriving with all the credibility of an internal system.
The underlying weakness sat in Salesforce's Trusted URLs control, the allow-list that is meant to restrict where an agent can send data. According to the research, the mechanism did not register hostnames ending in an unrecognised top-level domain, and certain characters interfered with how URLs were parsed — so destinations that should have been blocked were not.
Zenity says it disclosed to Salesforce on 1 June 2026 and that Salesforce worked with the researchers and addressed the reported bypasses within roughly two weeks. If you use Agentforce, this is a fixed issue rather than a live one.
- Entry point
- An untrusted lead submitted from outside the organisation.
- What made it work
- The agent acted on attacker-supplied content, and the destination allow-list could be bypassed.
- Status
- Disclosed to Salesforce on 1 June 2026 and remediated; published publicly in September.
Why this is a governance problem, not just a product bug
An AI agent is different from a chatbot in one respect that governs everything else: it acts. It reads records, calls systems and sends messages using permissions your organisation granted it. That makes two old security principles newly urgent.
The first is that untrusted input must never become instruction. A lead form, a support ticket, an inbound email and a scraped web page are all attacker-controllable. An agent that reads them as context is fine; an agent that follows them as direction is a confused deputy with your credentials.
The second is that an agent's identity is a trust asset. Staff who have been told to expect messages from an internal assistant have been trained, in effect, to trust whatever that assistant says. Phishing delivered through it bypasses the scepticism people apply to external mail.
Questions worth asking about every agent you run
- What can it reach, and why that much? Agents are frequently given broad read access because narrowing it is fiddly. Scope is the control that limits the blast radius of everything else.
- Where can it send data? If there is an allow-list, someone should have tested it adversarially rather than assuming it holds. SalesBleed was, in essence, an allow-list parsing failure.
- Which of its inputs are attacker-controlled? Map them explicitly. Anything a stranger can write into is in that category.
- What does it log, and who reads it? Zero-click exfiltration produces no user-visible event. The only trace is in the agent's own activity log.
- Who approves actions with consequences? Reading a record and emailing 400 customers deserve different thresholds.
The compliance angle
Under the GDPR, an agent that exfiltrates CRM records is a personal data breach like any other, with the same notification clocks and the same expectation that you can explain how it happened. The organisations that will struggle are not the ones with an incident — they are the ones that cannot say which agents were running, what data those agents could reach, or who signed them off. A live registry of AI systems in production, with scope and owner recorded against each, turns that from a research project into a lookup.
Put governance around your AI agents before they act on something they shouldn't.
Talk about agentic AICommon questions
No. Zenity Labs reported the issues to Salesforce on 1 June 2026 and says Salesforce addressed the Trusted URLs bypasses within about two weeks. The research was published later, in September 2026, which is why the coverage is recent.
Data leaving the organisation without any user clicking or approving anything. In this research two of the flaws allowed CRM data to be sent to attacker-controlled infrastructure purely as a consequence of the agent processing a malicious lead, so there was no user action to spot or block.
Limit what each agent can read and where it can send data, treat every attacker-controllable input as untrusted content rather than instruction, require approval for consequential actions, log agent activity somewhere a human reviews, and keep a registry of which agents are in production and who owns them.
Sources
- Salesforce Agentforce vulns allowed 0-click CRM data theft, anonymous phishing — The Register, 24 September 2026
- Vulnerabilities in Salesforce Agentforce Expose Wider AI Agent Risk — Infosecurity Magazine, 24 September 2026
- Zenity Labs Uncovers SalesBleed, 3 Salesforce Agentforce Flaws Enabling Zero-Click CRM Data Theft and AI Agent Impersonation — Zenity Labs (Business Wire), 24 September 2026
