The Slack Message From the Bot Nobody Questioned

Most staff have learned to be wary of an email from a stranger. Far fewer have learned to question a message from the company's own Slack assistant. That gap is what a piece of research published on 24 September 2026 puts under the microscope, and it is a useful preview of how phishing will look as AI agents take on more everyday work.

Researchers at Zenity Labs, working with Salesforce, found that an AI agent in Salesforce Agentforce could be steered into posting phishing links into internal Slack threads. The message appeared under the agent's name, with no confirmation step and no sign of who had triggered it. Zenity says the attack path is closed by default, and Salesforce says it has seen no evidence of real-world exploitation. The lesson is still worth studying, because the weakness was in the trust around the agent rather than in any one line of code.

What did the researchers actually find?

Zenity's write-up, which they call Salesbleed, describes three separate weaknesses in how Agentforce agents behaved when connected to Slack:

• The "Reply to a Slack Thread" action sent messages without asking the user to confirm first. A different action, sending a direct message, did ask.
• Recipients saw only the agent's identity. Nothing showed which user had asked the agent to act.
• A filter meant to strip untrusted web addresses from the agent's output could be bypassed. Zenity attributes this to differences in how the filter and Slack handled certain domain endings and URL-ending characters, and notes that link text could also hide the real address.

Any one of these is a modest flaw. Together they produced something that looked, to a colleague, like a normal and trusted message.

How does a web form turn into a Slack message?

The route starts somewhere outside the company. Salesforce customers often run Web-to-Lead forms, which let anyone on the internet submit a record into the CRM. An attacker fills in such a form and hides instructions inside the text of the lead.

Nothing happens at that point. The trigger comes later, when an employee asks the agent for something routine, such as help with a recent lead. The agent reads the record, treats the hidden instructions as part of its job, and replies in Slack threads with a link of the attacker's choosing. The employee who made the request sees no prompt and no warning.

Zenity also points out that the poisoned lead stays in the database. Every later review of that record can fire the instructions again. This kind of attack is called indirect prompt injection: the attacker never talks to the agent directly, but plants text where the agent will eventually read it. The same family of weakness was shown against Agentforce a year earlier by Noma Security, as reported by Dark Reading, and Salesforce's first response then was URL filtering. Zenity found that the filtering could be got around.

Why does it work on sensible people?

Because the usual cues are missing. When a phishing email arrives, there are things to check: the sender address, the odd phrasing, the link preview. An internal tool posting in an existing thread skips all of that. The message sits among real conversation, carries the name of a system the company chose to deploy, and may be dressed up as a note from IT or a colleague.

That is not a failing on the reader's part. It is an ordinary and reasonable assumption that a company's own tooling has been vetted. If anything, the research shows why the checks should live in the product and the process, with people as one more layer rather than the only one.

What did Salesforce change?

According to Zenity's disclosure timeline, the findings were reported on 1 June 2026 and Salesforce confirmed them the next day. The URL-redaction bypass fix was confirmed on 19 August, and attribution of the invoking user in thread replies was confirmed on 20 August. Salesforce told Dark Reading it changed defaults so that certain Agentforce actions in Slack require user confirmation, replaced regex-based URL detection with proper URL parsing, and is contacting customers to review their configurations. Zenity confirmed all fixes on 21 September, three days before publication.

There is a caveat in the write-up that matters for administrators: user confirmation can be switched off with a single click, which would reopen the path. A secure default is only as durable as the people who can change it.

What should organisations do?

You do not need to be a Salesforce customer for this to apply. Any AI agent that can read outside content and post inside your workspace has the same shape of risk. The measures below are sensible practice for that pattern, rather than a list taken from Zenity's report, apart from its advice to watch write-action settings closely.

• Review the settings of every agent that can post to shared channels, and check that confirmation is still switched on after any configuration change.
• Treat anything that arrives from outside, including web forms, support tickets and inbound email, as untrusted input to any agent that reads it.
• Make sure agent messages carry clear attribution, so a colleague can see who or what asked for them.
• Do not rely on link filtering alone. Zenity's bypass shows a filter can fail quietly.
• Limit what each agent can reach. An agent that can read the CRM and write to many channels has a wide blast radius.
• Keep logs that go beyond summaries, so you can reconstruct what an agent read and what it did.

What should staff be told?

The message for people is short and calm. A link in a workplace chat deserves the same pause as a link in an email, whoever or whatever posted it. If a bot or a colleague asks you to sign in, approve something or open a document you were not expecting, check through a second channel before acting. And make it easy to report: a quick note to the security team about an odd message is a good outcome even when the message turns out to be harmless.

Practising that habit works best when it covers the places people actually work, which now include chat tools and AI assistants as well as the inbox.

The bottom line

Salesbleed was found and fixed before any known harm, which is how responsible disclosure is supposed to go. What it leaves behind is a pattern. As agents gain the ability to write into shared spaces, their messages inherit the trust people place in those spaces. Confirmation steps, attribution and careful scoping keep that trust earned, and staff who know to verify an unexpected request give you a second line of defence.

Sources: Zenity Labs, Salesbleed technical write-up (24 September 2026); Dark Reading coverage including Salesforce's response.

Phishing Tackle offers the tools businesses need to strengthen their human risk strategies, with multi-platform testing, real-time behavioural insights, and actionable data to keep your organisation ahead of modern cyber threats.

Contact us today to learn how Phishing Tackle can help safeguard your organisation from the growing array of cyber risks.