Skip to content
PERMISSION/PROTOCOL
Back to incident tracker

2025-09-12

HighPrimary

ForcedLeak: Indirect Prompt Injection in Salesforce Agentforce Bypasses Safety Guards via Expired Trusted Domain to Exfiltrate CRM Data

Analysis of the ForcedLeak vulnerability where indirect prompt injection in Salesforce Agentforce exfiltrated CRM data via an expired trusted domain.

Salesforce AgentforceGovernance bypassIndirect Prompt Injection and Domain HijackingEnterprise CRM platform and integrated customer-facing AI agents

What happened

An customer-facing CRM agent accesses an expired trusted domain, ingests malicious instructions, and executes tools to package and exfiltrate internal customer directories.

Why it matters

Unauthorized exposure and exfiltration of corporate Salesforce CRM databases, containing sensitive customer accounts and pipeline values.

Missing authorization check

All bulk database reads and inter-system data transmissions must require an out-of-band human-signed cryptographic receipt.

Would PP block it?

Even if an attacker hijacks the Agentforce LLM using indirect prompt injection, any subsequent tool call attempting to query multiple CRM rows or post data to external servers is routed through PP's Tool-Call Gate. Since the injected prompt cannot generate a valid operator cryptographic signature, the tool call fails-close, blocking the leak.

Incident analysis

Timeline and technical read

Timeline

  1. 2025-09-12

    Noma discloses ForcedLeak vulnerability affecting Salesforce Agentforce deployments.

  2. 2025-09-15

    Salesforce releases patches restricting Agentforce domain-trust assumptions and adding prompt filtering.

Technical breakdown

  • The attacker registered an expired domain that was pre-approved in the Salesforce trust configuration.
  • When the customer-facing Agentforce agent parsed a ticket referencing this domain, it executed an automated web fetch, merging the domain's malicious injection payload directly into its execution thread.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Governance bypass. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
Tool-Call Gate, Salesforce API gateway
Still needs
PP does not block the agent's initial navigation to or rendering of the hijacked domain within its execution container.
Receipt required for
Accessing sensitive CRM database records, fanning out queries above a row threshold, or transmitting data to external domains

PP's Tool-Call Gate blocks any bulk CRM read or external exfiltration attempts that do not present a verified operator cryptographic signature.

Start small

Put the relevant gate at this action boundary.

This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop