Your Salesforce Agent Could Have Sent the Phish in Slack
Salesforce has changed the defaults for a demonstrated phishing path through Agentforce and Slack. Zenity’s SalesBleed research shows how malicious instructions in a public CRM lead could make an agent send a phishing link into an internal Slack thread.
Untrusted content crossed into a trusted write action
The demonstration combined indirect prompt injection, a URL-filtering bypass and a reply action that lacked confirmation and invoker attribution. An employee’s legitimate request to review the poisoned lead could bring those instructions into the agent’s context.
Zenity confirmed URL handling and attribution fixes in August, followed by default action confirmation on 21 September. It says the demonstrated chain is no longer possible by default, although administrators can disable confirmation. This is a disclosed research demonstration; the reviewed primary report does not establish a malicious campaign.
Check the configuration behind the assurance
A safer default is useful, but an administrator still needs evidence about the deployed agent. Review what its connectors can write, when a person sees the proposed action and whether the resulting message identifies that person. A test in a new tenant cannot substitute for reviewing an older customised workflow.
For recipients, the sender name alone should not confer authority. An agent can relay material from outside the organisation. Approval should expose the destination and meaningful content of a message, giving the reviewer enough context to recognise a request that departed from their original task.
What Agentforce and Slack administrators should review
- Inventory agent write actions. Record which agents can send direct messages, reply to threads, post across channels or invoke other systems.
- Require confirmation for consequential writes. Treat a disabled confirmation prompt as a deliberate security exception with an owner and review date.
- Preserve invoker attribution. Recipients need to know which human interaction caused the agent to act.
- Separate untrusted data from instructions. Web forms, email, cases and CRM records should be treated as attacker-controlled content when an agent reads them.
- Review trusted URL controls. Use Salesforce’s current settings and test Markdown, redirects and unusual URL forms rather than checking only obvious links.
- Monitor agent-to-Slack activity. Look for unusual thread replies, large fan-out, messages that do not match the initiating task and repeated actions tied to the same CRM record.
BlackTree has argued that AI agents need better boundaries more than more intelligence. SalesBleed makes that architectural point concrete: a public input, a trusted model and a write-capable workplace connector formed one path across three systems.
Sources
- Zenity Labs, original SalesBleed research, published 24 September 2026. The page provides no publication time.
- Salesforce, guidance for trusted Agentforce actions, accessed 25 September 2026. The documentation page provides no publication time.
