What happened
On June 1, 2026, Zenity Labs reported the Agentforce findings to Salesforce. On September 21, 2026, Zenity Labs confirmed that all reported fixes had been tested. On September 24, 2026, Zenity Labs publicly disclosed SalesBleed. The agent framework was Salesforce Agentforce using the Slack Knowledge subagent and its Reply to a Slack Thread action. The underlying model and version were not identified in the cited sources.
Operators could add Slack Knowledge, and the remediated user-confirmation requirement for Reply to a Slack Thread can be disabled with one configuration change. When instructed, Agentforce mechanically invoked Reply to a Slack Thread to post a message into Slack; the research also chained untrusted CRM content into that action. The cited sources did not publish a CVE, product version range, tenant indicator or evidence of real-world exploitation. Attribution posture: SalesBleed was controlled security research; the cited sources did not establish real-world exploitation or name a threat actor.
Why this matters now
The research exposes a control-plane problem rather than a conventional software patch problem. An enterprise agent can inherit broad data access, consume attacker-controlled business records and act through a trusted collaboration identity. If security reviews each connector separately, the dangerous combination remains invisible. The relevant unit of risk is the entire execution path from input source, through agent permissions and tool selection, to the destination action.
Salesforce fixed the demonstrated defaults and URL-handling paths, but Zenity noted that confirmation can be disabled again through configuration. That makes tenant posture and change governance decisive. Organisations using any agent platform should identify combinations of untrusted content, private data and outward communication, then impose human approval, attribution and constrained permissions where the combination cannot be removed.
The decision for security leaders
Treat enterprise agents as privileged identities with delegated tools, not as user-interface features. Assign the AI platform owner to document the agent’s input sources, run-as identity, accessible objects, subagents, actions, approval controls and communication destinations. Security should approve the combined execution path and record exceptions where an agent retains all three high-risk properties.
Make confirmation and attribution centrally governed controls. A platform default is insufficient when builders can disable it. Require change logging, periodic configuration export and a test that demonstrates sensitive write actions stop for human approval and record the invoking identity. Where the platform cannot provide that evidence, narrow permissions or remove the action.
Evidence of closure
- A current inventory maps each agent to its owner, identity, inputs, data and tools.
- Configuration evidence shows confirmation enabled for every sensitive write action.
- A controlled test verifies Slack messages include the invoking-user attribution.
- Change controls prevent unapproved disabling of confirmation or attribution.
The Security.io assessment
The demonstrated paths were fixed before publication, and the cited sources provide no evidence of production exploitation. The material finding is therefore architectural: trusted agents can translate untrusted business data into privileged actions across systems. URL filtering and model-level guardrails are insufficient when permissions, tool invocation and human approval remain loosely governed.
The September disclosure belongs in this edition because it turns a broad AI-security concern into a checkable enterprise control decision. It also adds a distinct Monday agenda item beyond vulnerability remediation: security leaders need an agent inventory tied to identities, tools and configuration authority. Closure depends on tenant evidence and tested action boundaries, not an assurance that the SaaS provider fixed the researcher’s exact bypass.
Questions for the morning meeting
- Which agents combine public input, sensitive data access and external communication tools?
- Can an operator disable confirmation without security approval?
- Do logs identify the human, agent, source record and tool behind every write action?