Zenity Labs’ SalesBleed research demonstrated how malicious instructions placed in externally supplied Salesforce data could influence Agentforce and contribute to zero-click data exfiltration.
Salesforce has remediated the reported vulnerabilities. But the incident leaves Salesforce architects and security teams with a broader question that survives the patch:
That question moves the discussion beyond prompt security and into identity, permissions, least privilege and access governance.
1 What Happened in SalesBleed?
The SalesBleed research published by Zenity Labs demonstrated an indirect prompt-injection attack involving Salesforce Agentforce.
One of the most interesting parts of the attack was its starting point: public Web-to-Lead data.
An attacker could submit a Lead containing malicious instructions through a public Web-to-Lead form. Those instructions could remain stored as ordinary CRM data until an employee later asked Agentforce to work with the affected lead.
When Agentforce processed that data, the malicious content could influence the agent’s behaviour.
INPUT
INJECTION
ACCESS
DATA
2 The Permissions Were Already Legitimate
This is where SalesBleed becomes particularly interesting from an access-governance perspective.
The demonstrated attack did not depend solely on creating new privileges. The affected agent could use capabilities that had already been granted to it.
In other words, prompt injection influenced the agent — but the potential blast radius depended on the authority already available to that identity.
Prompt injection determines whether an agent can be manipulated.
Permissions help determine what a manipulated agent can reach.
That makes existing Salesforce access controls part of the AI security boundary.
3 Salesforce Already Treats Agent Permissions as a Security Boundary
Salesforce’s own Agentforce security guidance reinforces this point.
Employee agents operating in authenticated channels can execute in the context of the logged-in Salesforce user, meaning existing licences, Permission Sets, field-level security and sharing controls remain relevant.
Service agents operating in public-facing channels can instead use a dedicated Agent User whose Salesforce permissions determine what data the agent can read or edit.
Salesforce also warns that if an agent receives access to data it does not require, it can potentially expose proprietary information.
That makes least privilege more than an administrative hygiene exercise. It becomes part of the security architecture surrounding AI agents.
4 Prompt Security Is Not the Same as Access Governance
These controls solve different parts of the problem.
🛡️ Prompt & Runtime Security
Primary question:
Can we prevent malicious instructions from controlling the agent?
Guardrails, prompt-injection defences, trusted URL controls, confirmation requirements and runtime protections operate here.
🔐 Access Governance
Primary question:
If those controls fail, what authority does the identity possess?
Least privilege, approvals, entitlement management, expiry, accountability and certification operate here.
5 AI Agents Are Becoming Enterprise Identities
Traditional Salesforce access governance has largely focused on humans.
A user joins the organisation, receives access based on their role, accumulates or loses entitlements as responsibilities change, and eventually has that access removed.
Agentforce introduces another identity model into that environment.
Human Identity
User → Persona → Approved Access
AI Identity
Agent → Business Purpose → Approved Access
The execution context can differ by agent type. Some Agentforce experiences respect the logged-in user’s access, while others use dedicated agent-user records with explicitly assigned permissions.
But the governance requirement is similar: the authority should match the business purpose.
6 Five Controls That Matter for Agent Access
Identity clarity
Teams should understand whether an Agentforce action is executing using the logged-in human user’s access or a dedicated agent identity.
Least privilege
An agent should receive the minimum objects, fields, records, flows, Apex classes and other capabilities required for its defined purpose.
Controlled privilege elevation
Expanding an agent’s authority should be treated as an access decision: who requested the access, what business capability requires it and who approved the change?
Access lifecycle
Temporary requirements should not silently become permanent entitlements. Where elevated access has an end date, the access should have one too.
Audit and certification
As agents gain new actions and integrations, organisations should periodically validate whether those capabilities are still required.
7 Why Blast Radius Matters
Consider two agents exposed to the same successful prompt-injection technique.
Agent A
Can read only the Lead fields required for lead qualification.
Potential blast radius: constrained.
Agent B
Can access Leads, Accounts, Contacts, Opportunities and additional sensitive enterprise information.
Potential blast radius: materially larger.
The prompt-injection technique could be identical.
The consequences do not have to be.
Its purpose is also to constrain what becomes possible when another control fails.
8 What Salesforce Teams Should Review Now
SalesBleed has been remediated, so the useful response is not panic. It is to use the incident as an opportunity to review the access model surrounding existing and planned agents.
- Inventory Agentforce agents operating in the Salesforce environment.
- Identify whether each agent operates in user context or through a dedicated agent user.
- Review Permission Sets and Permission Set Groups assigned to agent users.
- Review object, field and record access against the agent’s actual business purpose.
- Review access to flows and Apex classes used by agent actions.
- Identify write actions and confirm whether human confirmation is appropriate.
- Review external data sources capable of introducing untrusted content into CRM records.
- Identify temporary or elevated permissions that should have an expiry date.
- Document who owns and approves changes to each agent’s access.
- Include AI identities in periodic access-review and certification processes.
9 From User Access Governance to Agent Access Governance
SalesBleed points towards a broader change in Salesforce identity governance.
Enterprises are no longer granting authority only to people.
They are increasingly granting authority to software identities capable of reasoning over information and taking actions on their behalf.
The governance principles do not need to change completely simply because the identity is an AI agent.
Where SFAI User Access Governance fits
SFAI User Access Governance (UAG) is designed around persona-based access, controlled approvals, provisioning, access lifecycle and accountability within Salesforce.
The same architectural principles create an interesting path for governing AI identities alongside human users — defining approved entitlement baselines, controlling privilege expansion, expiring temporary access and periodically certifying whether access is still required.
UAG is not a prompt-injection defence and does not replace Agentforce security controls.
Its role is different: govern the authority surrounding the identity.
SalesBleed Is Patched. The Lesson Remains.
Salesforce and Zenity worked through the reported vulnerabilities, and the disclosed attack path has been remediated.
But the architectural lesson survives the vulnerability.
AI agents can consume enterprise information, reason over it and increasingly take actions across systems.
That makes their permissions part of the security boundary.
Secure the agent.
Limit the blast radius.
This article is based on security research published by Zenity Labs, Salesforce’s Agentforce security documentation and public reporting on Salesforce’s remediation.
Zenity disclosed the findings to Salesforce beginning on June 1, 2026. Zenity confirmed Salesforce’s fix for the specifically reported Trusted URLs bypass on August 19 and states that all fixes associated with the disclosed Slack attack path were confirmed and tested by September 21, 2026.
Salesforce has stated that it has no evidence the vulnerabilities were exploited by real-world attackers. The vulnerabilities discussed here should therefore not be interpreted as an active, unpatched Salesforce vulnerability.
This article examines the broader identity and access-governance lessons arising from the research.
Further reading:
Zenity Labs — SalesBleed research
Salesforce — Agentforce Security and the Shared Responsibility Model
Salesforce — Configure Service Agent Access
Salesforce — Common User Access for Standard Agent Actions