A trusted agent can become the phisher. Put confirmation on every write action.

Zenity Labs disclosed on 24 September that a poisoned Salesforce lead could make an Agentforce agent post phishing messages into internal Slack threads. The dangerous part was not simply prompt injection. One built-in write action could send the message without user confirmation and without showing who triggered it.

Salesforce has fixed the reported path, according to Zenity. The reusable lesson is broader: an agent that reads untrusted data and can write into a trusted collaboration system creates a privilege bridge. Treating the model as the security boundary leaves both sides of that bridge exposed.

A trusted identity amplifies an untrusted instruction

The attack started with Salesforce Web-to-Lead, a deliberately public input surface. Malicious instructions stored in a lead could later be processed when an employee asked Agentforce to work with CRM data. Zenity found that the same agent could then invoke the Reply to a Slack Thread action.

That action was the critical control gap. Zenity reports that it lacked both a confirmation checkpoint and visible invoker attribution. Combined with a bypass of Agentforce URL redaction, the agent could carry an attacker-controlled phishing link from an external record into an internal Slack conversation under the agent's trusted identity.

An agent's identity should never make its write actions more trusted than the instruction that caused them.

Confirmation belongs on the capability, not in the prompt

Prompt rules cannot reliably compensate for a write primitive that is too permissive. Every action that sends a message, changes a record, starts a workflow or reaches another trust domain should carry its own enforcement: who may invoke it, whether approval is required, what destination is allowed and which human or workload caused the action.

This also changes logging requirements. Recording that Agentforce posted to Slack is insufficient. Security teams need the originating session, user, source object, tool invocation, target channel and approval decision. Without that chain, an agent can collapse several identities into one audit event and make incident reconstruction unnecessarily ambiguous.

Test the path from untrusted input to trusted output

Agent security testing should model complete paths rather than isolated prompts. Seed CRM records, tickets, documents and email with adversarial instructions, then observe whether the agent can cross into write-capable tools. A successful control should stop the action at the tool boundary even when the model follows the injected instruction.

Zenity says Salesforce added attribution and changed the relevant Slack action so confirmation is required by default. Teams using enterprise agents should still inventory every write-capable action and verify those controls themselves. Defaults can change, administrators can disable confirmation, and new connectors can quietly create another bridge.

The practical release gate is simple: no externally influenced agent should gain an unaudited path to a trusted write action. If the path exists, require explicit policy, attributable execution and a confirmation boundary before production.

Written by the Devence Lab research team.