Form-Based Prompt Injection: How ShareLeak and PipeLeak Turned Copilot Studio and Agentforce Against Their Owners

On April 15, 2026, Capsule Security disclosed two vulnerabilities that should make every team running a no-code AI agent pause. ShareLeak turned Microsoft Copilot Studio against its owner. PipeLeak did the same to Salesforce Agentforce. They were found by the same research team, in two different products, against different data stores - and they are mechanically the same attack. That is what makes them an advisory rather than a footnote.

In both cases, an attacker who never authenticated, never logged in, and never touched the agent directly was able to make a trusted enterprise agent read private customer records and email them out. The attacker's only action was filling in a public web form.

What ShareLeak and PipeLeak are

ShareLeak is Copilot Studio prompt injection delivered through a SharePoint form. An attacker submits the form and places a fake system-role / instruction-override payload in a free-text Comments field. The text is stored. Later, an internal employee asks their Copilot Studio agent something innocuous - "review this submission." The agent reads the stored comment as if it were a legitimate instruction, queries connected SharePoint Lists for customer data, and emails the results to an attacker-controlled address through its authorized Outlook connection.

Microsoft assigned CVE-2026-21520 (CVSS 7.5, High, Information Disclosure). Coverage and Capsule's writeup both note that assigning a CVE to prompt injection in an agentic platform is itself notable - vendors have often treated injection as model behavior rather than a software defect. The assignment is a signal that the industry is starting to treat injection as a real vulnerability class.

PipeLeak is the Agentforce sibling. The delivery vector is a public Web-to-Lead form's free-text field. The payload abuses the GetLeadsInformation flow to retrieve lead records, then the agent's authorized email action to send that data to an arbitrary external address with no user awareness. Salesforce did not assign a CVE. It characterized PipeLeak as "configuration-specific" rather than a platform-level vulnerability and pointed to layered safeguards including instruction isolation, tool-use restrictions, and human oversight.

The shared mechanics

Strip away the brand names and the same five steps run in both products:

1. An unauthenticated attacker submits a public-facing form.
2. They embed a fake "system" instruction or role-override payload in a free-text field.
3. The platform concatenates that untrusted form data directly into the agent's prompt context with no sanitization and no trust-tier separation.
4. An internal employee later asks the agent to process the submission - "review this lead." The agent executes the attacker's hidden instructions as trusted directives.
5. The agent uses its own authorized tools to query private records and email them externally - with no volume cap and no user awareness.

The critical design failure is step 3. Untrusted public input and trusted operator instructions land in the same context window with no boundary between them. To the model, a string in the Comments field and a string from your system prompt are indistinguishable. This is the textbook mechanism we cover in indirect prompt injection explained: the attacker doesn't talk to the model, they leave a note where the model will read it.

Exfiltration through the front door

What makes these attacks so hard to catch is that nothing illegitimate happens at the egress layer. The data leaves via Outlook or an Agentforce email action - sanctioned, configured, expected channels. There is no malicious binary, no exfil to a random IP, no shadow API call. The agent did exactly what it is allowed to do, just for the wrong reason. This is why traditional DLP and egress monitoring miss it, a failure mode we unpack in DLP for AI agents: why traditional DLP fails.

The headline finding: detection without enforcement

ShareLeak's standout detail - reported across multiple outlets and Capsule's own writeup - is that even when Microsoft's safety mechanisms flagged the request as suspicious, the data was exfiltrated anyway.

The system saw the anomaly. It produced a signal. And the records still left the building. An alert that fires after the data is gone is not a control.

This is the gap we call detection without enforcement, and it is the single most important lesson here. Visibility is necessary but not sufficient. If your only response to a flagged action is a log entry, you have built telemetry, not governance. The blocking decision has to sit inline with the action, not in a SIEM that someone reviews tomorrow.

The vendor disagreement, and why it matters

Microsoft patched. Salesforce disputed. That divergence is itself instructive for any security team relying on platform defaults.

Salesforce's position is that PipeLeak is configuration-specific, and that Human-in-the-Loop (HITL) confirmation is already enabled by default for email-based agentic actions. Capsule's rebuttal is twofold: it says the email channel remained exploitable on Custom Topics (now Sub-Agents), which represent the bulk of enterprise deployments, and it questions the autonomy trade-off of mandatory approval:

"If every email requires human approval, you haven't built an AI agent, you've built a very expensive draft generator."

Both sides have a point. HITL genuinely would stop this. But an autonomy feature that's only safe when fully throttled isn't autonomous, and a default that researchers say can be sidestepped on the most common deployment shape is not a control you can simply assume is in place. The practical takeaway: do not depend on vendor defaults or optional toggles for your exfiltration protection. Assume the agent can send, and put an independent enforcement layer in front of it.

This keeps happening: the ForcedLeak precedent

PipeLeak is not the first time the Agentforce Web-to-Lead surface has been weaponized. In September 2025, Noma Security disclosed ForcedLeak (CVSS 9.4), which used the same form vector - abusing a large free-text Description field - and chained it with an expired-but-still-whitelisted domain (bought for about $5) for a Content Security Policy bypass and image-tag exfiltration. Salesforce fixed it on September 8, 2025 with Trusted URLs Enforcement for Agentforce and Einstein AI.

What ties the two together is the channel difference. According to Capsule, PipeLeak does not rely on the image-tag / untrusted-URL trick that ForcedLeak's patch closed; it reaches the same CRM data through the agent's authorized email action instead. In Capsule's framing, PipeLeak survives the ForcedLeak remediation because that fix addressed one egress path, not the underlying design where untrusted form input drives a privileged agent.

The honest narrative is uncomfortable: the same vector - a public form feeding a privileged agent - has now produced three named issues (ForcedLeak, PipeLeak, ShareLeak) across two vendors in under a year. Patches close instances. They do not close the pattern.

The architectural root cause: the lethal trifecta

Capsule frames both vulnerabilities through Simon Willison's lethal trifecta, coined in June 2025. An agent is exploitable for data exfiltration when it has all three of:

When one agent holds all three, exfiltration stops being a bug you can patch and becomes a capability you have granted. We go deeper on this in the lethal trifecta and AI agent data exfiltration. The defensive implication is that you should be hunting for agents that combine all three legs - that combination is the vulnerability, before any specific payload exists.

Framework mapping

For teams aligning to standards, both vulnerabilities map cleanly:

• OWASP LLM01:2025 - Prompt Injection. The direct mechanism. See the OWASP Top 10 for LLM applications guide.
• OWASP LLM02:2025 - Sensitive Information Disclosure. The outcome: private records leaving the org.
• OWASP LLM06:2025 - Excessive Agency. The enabler: an agent with read access and an unrestricted external-send action it didn't need for the task.
• Memory and context poisoning is the persistence concern if your agent retains attacker-influenced context across sessions, covered in AI agent memory poisoning explained.

Concrete controls a security team takes

These steps move from discovery to enforcement. The order matters - you cannot govern agents you have not found.

1. Inventory the agents and their inputs

Enumerate every Copilot Studio and Agentforce agent in your tenant, then map which public inputs feed each one - SharePoint forms, Web-to-Lead, support intake. The reason ShareLeak and PipeLeak ran silently is that nobody had a list connecting "this unauthenticated public form" to "this privileged agent." Start from how to build an AI agent inventory.

2. Map data and tool reach per agent

For each agent, surface what data it can read and what tools it can invoke. Flag any agent reachable from an untrusted public input that also has read access to sensitive records and an external communication tool. That is the lethal trifecta in one object, and it is your priority remediation list.

3. Detect the untrusted-input boundary

Identify agents whose context is assembled by concatenating public-form data without sanitization or trust-tier separation. Untrusted content should never enter the same trust tier as operator instructions. Where you cannot separate it, treat every downstream action as attacker-influenced.

4. Enforce on behavior, do not just alert

This is the ShareLeak lesson made operational. Watch for bulk record reads (a GetLeadsInformation call returning far more than the single record a human review would need) and outbound email to external or never-before-seen recipients - and block those actions, not merely log them. Apply least privilege for AI agents so the agent cannot bulk-read or send externally unless the task genuinely requires it. Runtime anomaly detection that can interrupt an action is covered in runtime monitoring and anomaly detection for AI agents.

5. Keep an immutable audit trail

Record which agent took which action, on whose instruction, against whose data. When a "review this lead" turns into a bulk exfiltration email, you need to reconstruct the chain - including that the triggering instruction came from a stored form field, not the employee. See AI agent audit trail and logging guide.

6. Own enforcement independently of vendor defaults

PipeLeak's disputed status is the strategic warning: do not let your data-loss posture depend on customers - or your own admins - having a particular HITL setting configured the way you assume. An independent enforcement layer sitting in front of agent actions protects you regardless of which platform settings are on, and regardless of whether the next issue gets a CVE at all.

Where continuous agent and MCP visibility fits

Every failure in this advisory traces back to a single property: nobody could see the agent's full reach. No one had inventoried which agents existed, mapped that a public form was an untrusted input feeding a privileged agent, noticed the lethal trifecta concentrated in one place, or caught records leaving through a sanctioned tool. The attack succeeded because it was invisible, not because it was sophisticated.

This is the category Anomity works in: continuous discovery and inventory of every AI agent and MCP server, mapping of each agent's data and tool reach, flagging of untrusted-input boundaries, and behavioral enforcement that can block - not just observe - anomalous bulk reads and external sends. AI agents and MCP servers are the new shadow IT, and as ShareLeak made painfully clear, detection without enforcement is not governance. You can't govern what you can't see - and you can't stop what you can only log.

For the broader picture of why this matters beyond two vendors, see our MCP server security complete guide and indirect prompt injection explained.

Bottom line

ShareLeak and PipeLeak are not exotic. They are the predictable result of giving an agent private data, untrusted input, and an external send tool - and then trusting the platform to sort it out. Patch the instances Microsoft and Salesforce identified. But treat the pattern as permanent: until you can inventory which agents hold the lethal trifecta and enforce inline on their behavior, the next public form is the next exfiltration channel.