AIDEFEND in Action AIA-0091 Validated Research Published: Oct 1, 2026

SalesBleed: Agentforce in Slack Sends Attacker-Shaped Phishing Replies

Zenity Labs tested two routes against Agentforce in Slack. An external attacker could plant instructions in a CRM lead later read by an employee's agent; an internal caller could directly ask the agent to post. In the tested Slack Knowledge template, Reply to a Slack Thread lacked confirmation and invoker attribution, and a crafted URL survived redaction. Salesforce fixed the reported defaults and bypass by September 2026.

Indirect Prompt InjectionSocial EngineeringHuman-in-the-LoopSaaS Security
7 applicable AIDEFEND defenses
Source: SalesBleed: Hijacking Agentforce in Slack for Anonymous Phishing Attacks 
Authors: João Donato, Alex Apostolov, Avishai Efrat, Ayush RoyChowdhury
Original article: Sep 24, 2026

Threat Analysis

SalesBleed had two tested entries. An external actor could seed a CRM lead that an employee's agent later read; an internal actor could ask the same agent directly. Both converged on Reply to a Slack Thread, whose tested default lacked confirmation and invoker attribution.

  • An external actor submits a lead containing instructions and a crafted phishing link through a public CRM intake such as Web-to-Lead.
  • An employee asks for help with a lead; the agent reads the record and treats its text as instructions to post in Slack.
  • An authorized internal user directly requests the same Slack reply with phishing content. This is a separate, tested insider route.
  • Reply to a Slack Thread sends the crafted message without an independent user confirmation; the tested URL bypass lets the link remain visible.
  • The reply appears under the agent identity in a relevant thread without showing which user initiated it, making the phishing message more credible.

Zenity also tested a URL-redaction bypass, so a crafted phishing link could survive into the reply. Salesforce confirmed fixes by September 21, 2026. A team that later disables confirmation can reopen the same class of risk; the research does not document an actual phishing victim.

Applicable AIDEFEND Defenses (7)

AID-H-018.002
Policy-Based Access Control
High
Authorize the Slack write from the authenticated invoker and the current task, not from the CRM record's text: a lead-assistance task cannot authorize posting to an arbitrary thread. In Agentforce the customer cannot insert a policy check between the planner and the standard Reply to a Slack Thread action, so the deployment precondition is to remove the standard Slack write actions from the agent and expose the write only as a customer-owned custom action (Apex, Flow or External Service) that calls this policy before posting. The insider route passes the same policy when the employee is entitled to post, which is why this control constrains destinations but does not decide the outcome alone.
AID-H-018.003
High-Impact Independent Validation & Approval Gate
High
Treat broad or link-bearing Slack publication as high-impact. In a customer-owned action replacing the standard write action, require independent approval bound to exact message, destination, links and authenticated invoker before sending. Confirmation by the requesting employee can stop an unintended external-lead action, but cannot by itself stop an intentional insider who approves their own phishing post; policy must require a separate authorized approver for that risk class.
AID-H-017.002
Least-Privilege Tool Architecture
High
The Slack Knowledge template adds Reply to a Slack Thread as a general-purpose write that can reach any thread the Search Slack results expose. Give the lead-assistance agent no Slack write action at all, or replace the template action with a customer-owned custom action whose thread parameter is fixed to the invoking conversation and whose message schema forbids markdown links. A planted lead can then at most produce a reply in the employee's own thread, and the broadcast to numerous channels that Zenity demonstrated has no tool to run on.
AID-H-006.002
Text, Markup & Structured Output Sanitization and Release Gate
High
In the customer-owned Slack send action, parse the message that Slack will actually receive, normalize every visible and markdown-hidden URL, and check its final destination against policy and a current reputation source. Hold the entire message when a URL cannot be verified. This can block known bad destinations and formatting bypasses; a new attacker domain with no reputation signal still needs an explicit destination allowlist or independent approval.
AID-H-017.007
Dual-LLM Isolation Pattern
Medium
Let a separately isolated Q worker with no Slack tools parse raw CRM leads; send only a broker-validated, bounded domain schema to the privileged P worker. Enforce separate identities, credentials and network paths and prevent P from reading raw leads. A prompt template or a free-text summary is insufficient: schema-valid strings can still carry malicious instructions. Treat projected text as untrusted and independently authorize every Slack action. This requires a customer-owned integration with measurable isolation; do not assume stock Agentforce supplies that boundary.
AID-H-018.005
Value-Level Capability Metadata & Data Flow Sink Enforcement
Medium
A customer-controlled Slack action can enforce sensitive or untrusted URL values only when the integration supplies complete, authenticated provenance for the message and every derived link. Labeling a CRM record at ingress does not track arbitrary model rewriting. Deny unknown provenance and remove standard/direct write bypasses. A conservative alternative forbids all links or writes in the isolated lead-processing task; this is not the published value-level tracking method. Neither architecture is established by stock Agentforce configuration.
AID-D-005.004
Specialized Agent & Session Logging
Medium
Record, for every Reply to a Slack Thread, the authenticated invoking user, the goal the agent was working on, a hash of the tool arguments and the policy decision. When a phishing-shaped post appears under the agent identity, security can answer which employee's request or which CRM record read caused it, which also gives the insider route accountability. Recipients still need product-level attribution to see the invoker.

What Defenders Should Do Now

  • Inspect every Agentforce Slack write action, especially Reply to a Slack Thread. Where publication has high impact, replace the standard action with a customer-owned action that verifies independent approval for the exact rendered message, URL, destination and invoker before sending.
  • Record the authenticated invoker for investigation; if recipients must see that identity, add product-level attribution to the Slack message. A forensic log alone does not change what recipients see.
  • At the final send action, test normalized and Markdown-hidden destinations against policy; retest after template or configuration changes.

1 additional consideration

Evidence and deployment boundary

The currently fixed default reduces this specific chain, but confirmation and attribution can be changed by customer configuration.
Recommendation: Inspect every Agentforce Slack write action, especially Reply to a Slack Thread; require confirmation bound to the exact text, URL, thread and invoker where publication is high impact.

Conclusion

AIDEFEND  points to the final Slack write boundary: the send action must verify who requested the post, where it will appear and which URL the rendered text actually opens. The signed pre-send gate requires a customer-owned action; ordinary logs provide attribution after the fact.

Last updated: