What ForcedLeak Actually Exploited in Agentforce
ForcedLeak is the name given to a disclosed weakness in Salesforce Agentforce, the AI agent layer that sits on top of standard CRM objects and can read, summarise and act on records without a human typing every step. The weakness did not come from broken authentication or a cracked password. It came from chaining two ordinary, individually unremarkable features: a public-facing Web-to-Lead form that accepts free text from anyone, and an AI agent that later reads that free text as part of doing its job. Neither piece is unusual on its own. Web-to-Lead forms have existed for years, and agents summarising leads is exactly the kind of task Agentforce is built for. The problem sits in the seam between them.
Salesforce’s platform behaved correctly by its own rules throughout. Data went in through an approved form, sat in an approved object, and was read by an approved agent. The failure was not that the CRM did something it shouldn’t. It was that the CRM could not tell the difference between a lead’s genuine enquiry and an instruction planted inside that enquiry by someone who never logged in at all.
How Indirect Prompt Injection Differs From a Normal Exploit
Most security teams have a mental model for classic exploits: an attacker sends malformed input, a parser or interpreter mishandles it, and code runs that shouldn’t. Prompt injection follows a different logic. A large language model does not distinguish “data I have been asked to read” from “instructions I have been asked to follow” unless the system feeding it text has gone out of its way to separate the two. Both arrive as plain text in the same context window. If a lead record contains a sentence written to look like a system instruction, an agent summarising that lead has no reliable internal signal telling it the sentence came from an anonymous website visitor rather than the person who configured its task.
This is called indirect prompt injection because the attacker never talks to the agent directly. They plant the instruction somewhere the agent will read it later, as part of a task a legitimate user requested. A sales rep asking Agentforce to draft a follow-up email for a new lead is the trigger. The rep did nothing wrong. The instruction was never addressed to them at all; it was addressed to whatever eventually processed that field.
The Web-to-Lead Attack Path, Step by Step
The mechanism reported in ForcedLeak followed a specific chain worth understanding in full, because each link is where a control either works or does not. An attacker submits a lead through a public Web-to-Lead form, placing a hidden instruction inside a free-text field such as Company or Description rather than anywhere a human would normally scrutinise. The lead saves as an ordinary record, indistinguishable in a list view from any genuine enquiry. Later, an internal user or an automated flow asks Agentforce to summarise the lead or draft a response, and the agent reads the field containing the planted text as part of that task, treating the embedded instruction as something to act on rather than something to report on.
The instruction typically asked the agent to include a reference to an external destination, for example as a tracking link or embedded image, as though this were a normal part of drafting a reply. Salesforce’s trusted URL allowlist exists precisely to stop an agent from sending content to unapproved external domains. Researchers who reported ForcedLeak found that a domain previously on that allowlist had lapsed and become available for anyone to re-register. Re-registering it turned an entry that should have been dormant into a live, approved destination the agent was permitted to reach, giving the injected instruction somewhere real to send data to.
Why RevOps and Sales Ops Feel It First
Lead intake sits at the front door of revenue operations. Routing rules, lead scoring, first-response automation and SDR assignment all fire off the same records an attacker could touch through a public form. An agent nudged by a planted instruction does not need to cause a dramatic outage to do damage. A small shift in how a lead gets scored, or which rep it gets routed to, produces a wrong assignment nobody flags because nothing looks broken. Forecasts built on top of that data carry the distortion forward without any alert firing, since the CRM never logged an error, only a slightly odd output.
Sales reps are also the group least positioned to notice. They trust CRM records by default, because that trust is the entire point of the system. An attack of this shape depends on exactly that trust holding, which is why it can sit undetected for far longer than a conventional breach that trips a firewall rule or a failed login alert.
There is a compliance dimension too. If personal data belonging to a prospect, such as a name or email address, leaves an organisation’s environment through a route like this without authorisation, it can meet the threshold for a personal data breach under UK data protection law, with its own notification obligations. The ICO’s guidance for organisations sets out what counts as a reportable breach and the timelines involved, and it is worth having read before an incident like this happens rather than during one.
What Salesforce Changed After Disclosure
Once ForcedLeak was reported, Salesforce tightened governance around the trusted URL allowlist itself, the exact control that had a stale entry sitting in it. The platform-level response addressed the specific gap: expired or unclaimed domains should not be able to sit on an approved list indefinitely, and default scopes for what an agent can read and act on were narrowed. Current advisories and status updates are maintained on Salesforce’s trust site, which is the right place to check for the latest state of any Agentforce-related advisory rather than relying on a static summary in a blog post.
A platform patch closes the specific hole that was found. It does not close the category of weakness. The same pattern, an agent reading unauthenticated free text and treating part of it as instruction, can reappear anywhere else text reaches an agent from outside your org: inbound email parsing, chat widget transcripts, support ticket descriptions, even file uploads with embedded metadata. Reading the ForcedLeak fix as “problem solved” rather than “one instance closed” is the mistake most likely to leave a team exposed to the next variant.
Building a Defence Layer Salesforce Cannot Provide
Platform vendors can close specific holes faster than any individual customer could. They cannot decide, on your behalf, which of your own intake points should be feeding an AI agent in the first place, or how tightly that agent’s permissions should be scoped. That design work sits with whoever owns the CRM configuration and the automation stack around it.
Field-Level Input Hygiene
Treat every field a public form writes into as untrusted input addressed to a machine, not just to a human reader. Before that text ever reaches an agent’s context, flag or strip content that reads like an instruction rather than a lead enquiry, phrases such as “ignore previous”, embedded system-style prefixes, or unexpected URLs. Tools such as n8n’s workflow documentation describe how to insert a validation or transformation step between an inbound webhook and whatever downstream system consumes it, which is the natural place to run this kind of check before a record ever reaches Salesforce or an agent built on top of it.
Trusted URL Governance
Audit the Remote Site Settings and any trusted URL allowlist on a recurring schedule, not as a one-off setup task ticked off during implementation. An expired domain should be removed from an allowlist the moment it lapses, since a domain nobody controls any more is not “probably fine to leave in place”, it is an open slot for anyone to claim. This is the exact control that failed in ForcedLeak, which makes it the first thing worth putting on a calendar rather than a wiki page nobody revisits.
Agent Permission Scoping
Scope each agent to the minimum objects and fields its task actually requires, separate from the permissions of whichever human user triggers it. An agent built to summarise inbound leads has no legitimate reason to hold write access to opportunities, contracts or financial records. If an injected instruction does succeed in manipulating an agent’s output, permission scoping limits how far that manipulation can reach, turning a potential platform-wide exposure into a contained, single-object problem.
Detection and Logging for Agent Behaviour
Standard user login and access logs will not show an agent quietly following a planted instruction, because from the platform’s point of view the agent was doing exactly what it was authorised to do. Separate logging is needed for what agents read and which external destinations they attempt to reach, with alerts on outbound requests to anything outside a small, explicitly approved set of domains. A sudden change in the volume or shape of an agent’s output, such as unusually long replies or unexpected attachments, is often the first visible signal something upstream has gone wrong. Equanax has recorded an 86 percent reduction in fixable sync errors across its automation work; disciplined logging and validation of this kind is one of the general mechanisms that tends to drive results like that, without any single technique here being the specific cause of that particular figure.
A Practical Rollout Order for Locking Down Agentforce
Teams starting from scratch rarely need every control above at once. A sensible sequence, in order:
- Inventory every entry point where free text from outside the organisation can reach an agent’s context: web forms, email-to-case, chat transcripts, uploaded documents.
- Audit and prune the trusted URL allowlist, removing any domain that is no longer actively owned and controlled by a known party.
- Scope each agent’s object and field permissions down to what its specific task requires, independent of the permissions held by the human who triggers it.
- Add input sanitisation or flagging at the point of intake, before untrusted text ever reaches an agent’s context window.
- Stand up agent-specific logging and alerting, distinct from standard user activity logs.
- Run a controlled injection test against your own intake forms, so the first person to find a gap is on your own team rather than an attacker.
Frequently Asked Questions
What made ForcedLeak different from a typical Salesforce data breach?
No credentials were stolen and no login was compromised. The weakness came from an AI agent reading a hidden instruction planted inside a public lead form field, combined with an expired domain still sitting on the trusted URL allowlist that could be re-registered by an attacker.
Does patching Agentforce mean the risk is gone?
The patch closed the specific expired-domain gap that made ForcedLeak work. The same injection pattern can still appear anywhere else an agent reads unauthenticated free text, such as inbound email or chat transcripts, so ongoing input hygiene and allowlist governance are still needed.
Which team should own this, IT security or RevOps?
Both. RevOps typically owns the intake forms and workflow design where untrusted text first enters the system, while security typically owns agent permissioning and logging. Prompt injection exploits the gap between the two, so a joint review works better than either team handling it alone.
Could a lead capture form injection trigger a UK GDPR breach notification?
If personal data belonging to a prospect leaves the organisation’s environment without authorisation as a result of this kind of attack, it can meet the threshold for a reportable personal data breach under UK data protection law. The ICO’s guidance for organisations sets out the relevant notification obligations.
What is the fastest first step for a team that has not audited this yet?
Inventory every entry point where public free text reaches an AI agent’s context, such as web forms, email-to-case and chat widgets. That inventory is the first step in the rollout order above and determines where the remaining controls need to be applied.
Related Reading
For more on this, see the Salesforce archive, including Automating Lead Enrichment with ZoomInfo, Salesforce, and N8N, Automate Salesforce Deal Stage Updates Using Google Sheets and n8n, and Automate Salesforce Quote-to-Contract Workflows with n8n and PandaDoc.
Leave a Reply