In Salesforce Agentforce, the recommended way to make an agent respond to events is a Flow: a record is created or a case is updated, and the Flow passes data into the agent's prompt. Separately, Email-to-Case and Web-to-Case turn inbound customer messages into case records; it is how airlines and hotels run support intake. Both are standard, documented, as-designed features. Chained together, they produce this path:

public internet → email → case record → agent prompt → agent action → case comment → outbound reply

An unauthenticated outsider now has a route into an internal agent's instructions, and the agent's reply leaves through the same door. Nothing was misconfigured. The finding, documented by researchers in August 2026, is a clean example of how agents that arrive inside existing platforms fail: through the application around them, not the model inside them.

Which intake features are enabled, which triggers fire, which objects are exposed to guest users, which automation passes untrusted data where, and which model version the agent is quietly calling underneath: these are the variables that decide whether the Agentforce chain is a support-queue nuisance or a data exposure. A vendor risk review performed once at procurement sees none of them, because the agent did not exist at procurement. A prompt filter watching the agent's inputs does not know that a particular input originated from a stranger, because prompt filters do not understand Email-to-Case.

Securing an inherited agent therefore means understanding its host application at the depth its own admins do.

Source link