Salesforce did not get breached because someone broke into Agentforce. It got breached because an AI agent did exactly what it was configured to do, and nobody was watching what data moved while it did it. That is the uncomfortable lesson inside SalesBleed, the set of three vulnerabilities Zenity Labs disclosed in Salesforce's Agentforce platform this September, and it is a lesson every enterprise wiring AI agents into CRM, ERP, and collaboration systems needs to sit with before its own version of this story breaks.

Key Takeaways

  • Zenity Labs found three flaws in Salesforce Agentforce, collectively called SalesBleed, that let attackers steal CRM data without logging in, without touching the target's Salesforce tenant, and without any employee clicking anything.
  • The attack began with a poisoned lead submitted through a public Web-to-Lead form, embedding a hidden prompt injection that an internal employee's Agentforce agent later read and followed while performing a routine task.
  • Agentforce's Trusted URLs allowlist, meant to stop the agent from visiting or generating unapproved external links, failed to catch a malformed URL placed inside an HTML image tag, and that gap let CRM data leak out over DNS.
  • Salesforce has since fixed the specific Trusted URLs bypass Zenity used, but the underlying pattern, an agent with broad data access acting on unvetted external input with no independent check on what it retrieves, remains common across enterprise AI deployments.

What Happened: Inside the SalesBleed Exploit Chain

Zenity's research, published at labs.zenity.io and covered by SecurityWeek and Infosecurity Magazine, describes an attack that required no credentials, no network access to the victim's Salesforce org, and no action from the person being targeted. An attacker filled out a public lead form, the kind every sales team keeps open for inbound prospects, and hid an instruction inside one of the text fields. That instruction sat dormant in the CRM as an ordinary-looking lead record.

The trigger came later, when a real employee asked their Agentforce agent to do something mundane, such as reviewing recent leads. The agent pulled the poisoned record into its working context and, following the hidden instruction, began acting on it. Zenity found that Agentforce's Trusted URLs control, designed to block the agent from generating or following links to unapproved domains, did not consistently catch certain top-level domains and specially crafted characters. A malformed URL slipped through the allowlist while still working as a live link when placed inside an HTML image source tag. When the client rendered that image, it reached out to an attacker-controlled hostname and encoded stolen CRM fields, including company names and deal sizes, directly into the subdomain it requested. No file left the building through email or a download link. The data left through a DNS lookup nobody was inspecting.

A third flaw in the same disclosure let attackers hijack the trusted identity of an Agentforce-connected Slack agent to send convincing phishing messages from inside the company. Salesforce has confirmed a fix for the Trusted URLs bypass, and Zenity verified the patch in August. The vulnerability class it exposed did not go away with that patch.

Why Agent Permission Configuration Is Not the Same as Data Flow Visibility

Every write-up of SalesBleed converges on the same root cause: Agentforce's access controls governed what the agent was allowed to be configured to do, not what it did with any given request. The agent had legitimate access to lead records and legitimate ability to render rich content. Both permissions were, on paper, correct. The exploit lived entirely in the gap between those static permissions and the dynamic, per-request behavior of the agent once it encountered adversarial input it was never designed to recognize.

This is the same gap Bonfy was built to close, and it is worth stating plainly: most AI security tooling on the market today asks a configuration question, checking whether an agent is allowed to reach a data source, and stops there. Bonfy asks a different question. Most tools ask what an agent is configured to do. Bonfy asks what data is actually flowing through it. That distinction is not academic. SalesBleed shows exactly how an agent can stay inside its configured permissions the entire time while a completely unintended data flow happens underneath.

Salesforce is not a system Bonfy or Kiteworks sits in front of today, so neither product was in this incident's data path, and no honest reading of the disclosure lets us claim otherwise. What SalesBleed demonstrates is the mechanism, not a specific product gap. If an equivalent lead-intake-to-agent pipeline sat behind Bonfy's Contextual Data Enforcement instead of relying solely on Agentforce's native Trusted URLs allowlist, the inspection point would sit between the agent and the data it retrieves mid-task, evaluating the actual content flowing through that DNS-encoded image request rather than trusting a static domain list to catch every malformed variant an attacker might try.

The Blind Spot Every AI Agent Platform Shares

SalesBleed is a Salesforce story this month. It will be a different vendor's story next quarter, because the architecture pattern it exploits is close to universal across enterprise AI agent deployments. An agent gets broad read access to a data store because narrower access would break half its use cases. The agent gets some kind of allowlist, redaction filter, or content policy meant to keep it from doing anything unapproved. And the policy enforcement happens at the boundary of what the agent is configured to reach, not at the boundary of what data is in motion during a live task.

Kiteworks has documented this same structural problem across the broader AI agent ecosystem: Microsoft named seven distinct ways AI agents can be hacked, and indirect prompt injection through untrusted content, exactly the SalesBleed vector, sits near the top of that list because it requires no compromised credential and no direct network access to succeed. A Kiteworks review of AI agent security incidents found that a majority of firms already reported an AI agent security incident in 2026, and the pattern behind most of them looks less like a hacked account and more like an agent doing what it was configured to do, at the wrong moment, with the wrong input.

The deeper issue is that allowlists, redaction rules, and static access grants are all forms of configuration. They describe intent. They do not observe behavior. An agent that is perfectly configured can still be manipulated into a data flow nobody intended, because the manipulation happens inside a request the agent was always allowed to make. Bonfy has made this same argument about frontier AI clients directly: trusting a model like Claude is the easy part; governing what it does with enterprise data once it is connected to real systems is the part most organizations have not solved.

From Configured Access to Actual Behavior: How Contextual Data Enforcement Works

Bonfy's answer to this gap is an inspection layer that sits between the AI client, whether that is Claude, Copilot Studio, ChatGPT, or a custom agent built on the Model Context Protocol, and the enterprise data stores it touches, such as SharePoint or Google Drive. Rather than relying on the agent's own configuration to decide what is safe, Contextual Data Enforcement evaluates what the agent is retrieving and transmitting mid-task, against policy, in real time.

Applied to a SalesBleed-shaped pipeline, that means the enforcement point would not depend on catching every possible malformed URL variant in a static Trusted URLs list. It would instead evaluate the content the agent was about to render or transmit, including a request encoding company names and deal figures into a DNS lookup, and apply policy to that actual data flow rather than trusting that the destination domain had already been vetted. This is the difference between a system that trusts its own configuration and a system that verifies its own behavior on every request.

Bonfy's entity awareness work and its research into what it calls the out-of-body execution problem, where an agent's actions drift from the intent that launched them, both describe versions of the same failure mode SalesBleed exposed at Salesforce's scale. The judgment layer piece makes the point most directly: agents inherit data access from the systems they connect to, but they do not inherit the judgment a human employee would have applied about which requests were reasonable. Contextual Data Enforcement is built to supply that missing judgment at the point where data moves.

salesbleed-ai-agent-data-risk_inline-crop_720x480 (1)

Governing Agents and Humans Under One Policy Model

SalesBleed also illustrates why splitting AI agent governance from human data governance creates exactly the seam attackers look for. The poisoned lead sat in the CRM as ordinary data until a human employee's routine request activated it. The exploit required both a human-facing workflow and an agent-facing one, and it succeeded because no single policy model governed both.

This is the architectural argument behind pairing Bonfy with Kiteworks. Bonfy provides inline, runtime classification and enforcement at the point where AI agents and human users generate, request, or transmit content. Kiteworks provides the control plane for secure data exchange, the system of record for who can access what, under what policy, with what audit trail, whether the requester is a person or an agent. Kiteworks Compliant AI is built on that premise: one policy engine, one audit log, and one security architecture covering both human and agent workflows, rather than a separate, thinner layer of controls bolted onto AI activity after the fact.

Kiteworks' own AI governance research has found that organizations with the weakest audit trails run tens of points behind on every other AI maturity metric, including purpose binding and human-in-the-loop controls. SalesBleed is what that gap looks like in production: an agent operating with real access, a policy control that only checked configuration, and no unified trail connecting the poisoned lead to the DNS exfiltration until Zenity's researchers reconstructed it by hand.

What Security and Compliance Teams Should Do Now

Security and compliance leaders do not need to wait for their own SalesBleed to act on what this disclosure shows. Three steps apply regardless of which AI agent platform an organization runs. First, inventory every public-facing intake form, whether a lead form, a support ticket submission, or a customer feedback field, that eventually feeds content into an AI agent's context window, since each one is a potential injection vector. Second, treat allowlists and redaction filters as necessary but not sufficient, and pressure-test them against the same malformed-URL and encoding tricks Zenity used rather than assuming a vendor's default configuration will hold. Third, ask whether the organization has one governance model covering both human and agent data access, or two separate, disconnected ones, because SalesBleed succeeded in exactly that seam.

Kiteworks' guidance on AI agent security at the data layer walks through this inventory and pressure-testing process in more detail, and it is a reasonable starting point for any team that has not yet mapped where its own agents touch unvetted external input. Bonfy's own reflections on a year of building at the intersection of AI and data security reach a similar conclusion from the vendor side: the organizations that fare best treat agent behavior, not agent configuration, as the thing worth watching.

FAQs

1. What is SalesBleed, and how is it different from a typical data breach?

SalesBleed is a set of three vulnerabilities Zenity Labs found in Salesforce Agentforce that allowed attackers to steal CRM data through a hidden prompt injected into a public lead form, with no login, no direct tenant access, and no employee interaction required. It differs from a typical breach because no credential was stolen and no perimeter was broken; the agent's own legitimate access was manipulated into an unintended data flow.

2. Did Bonfy or Kiteworks stop the SalesBleed attack?

No. Salesforce is not a platform Bonfy or Kiteworks sits in front of, so neither product was in this incident's data path, and Salesforce has already remediated the specific bypass Zenity used. The relevant point is architectural: the same failure mode, an agent acting on unvetted input within its configured permissions, appears across many enterprise AI deployments, and Contextual Data Enforcement is designed to catch that pattern at the point where data moves.

3. How would Bonfy and Kiteworks divide the work in a scenario like this?

Bonfy would sit inline between the AI client and the data store, inspecting what the agent retrieves or transmits on each request against policy in real time. Kiteworks would provide the control plane underneath, the unified access policy, audit log, and identity model that governs both the human employee who triggered the request and the agent that acted on it. Neither replaces the other; Bonfy enforces at the moment of use, Kiteworks governs the system of record around it.

4. Do organizations need both Bonfy and Kiteworks, or does one replace the other?

They solve adjacent but distinct problems. An organization relying only on a control plane without runtime content inspection can still be exposed to the kind of in-context manipulation SalesBleed used, since the request never violates any static access rule. An organization relying only on runtime inspection without a unified control plane can end up with fragmented audit trails across human and agent activity. Kiteworks describes this combined model as Compliant AI: one policy model covering data in motion, at rest, and in use, for humans and agents alike.

5. What should a security team check first after reading about SalesBleed?

Start with every public intake form that eventually feeds an AI agent's context, including lead forms, support tickets, and feedback fields, and confirm what happens when that content reaches the agent. Then test the platform's own allowlist or redaction controls against malformed URLs and encoding tricks rather than assuming the default configuration holds.

Enterprises are not going to slow down AI agent adoption, and they should not have to. What SalesBleed demands is a governance model that assumes agents will encounter adversarial input and checks what actually happens when they do, rather than trusting that correct configuration is the same thing as safe behavior. If your organization is wiring AI agents into CRM, file storage, or collaboration platforms and cannot yet answer what those agents are retrieving mid-task, that is the conversation to have this quarter, not after your own version of SalesBleed makes the news. Talk to Bonfy about Contextual Data Enforcement to see how runtime inspection applies to your own agent deployments.

Gidi Cohen is VP Product at Kiteworks and co-founder and former CEO of Bonfy.AI, which Kiteworks acquired in September 2026. He writes about AI agent security, data governance, and the gap between what enterprise systems are configured to allow and what happens inside them.