The lethal trifecta in production: how enterprise copilots became data exfiltration tools

The article develops an analytical framework — the "lethal trifecta", coined by Simon Willison — to explain why several enterprise AI copilots and agents ended up leaking private data during 2025 without any traditional security flaw in the code. The core idea is simple: a system based on a language model becomes a data-theft risk when three conditions coincide: (1) it has access to private data, (2) it is exposed to untrusted content (an email, a support ticket, a web form, a public issue) and (3) it has a route out to the outside world. The underlying problem is that the model processes instructions and data through the same channel: any text that reaches the context — a database row, a ticket, an email — is, to the model, a candidate instruction. When the three conditions come together, a leak is only a matter of time; removing any one of the three legs leaves the attack with nowhere to go.

The author illustrates the pattern with concrete, documented cases. The first is EchoLeak (CVE-2025-32711, CVSS 9.3), a "zero-click" vulnerability against Microsoft 365 Copilot, disclosed by Aim Labs in June 2025. An attacker sends a single crafted email; when the user later makes any query to Copilot, the retrieval pipeline pulls that email into the context and executes the hidden instruction, allowing Copilot to access content from OneDrive, SharePoint and Teams and exfiltrate it. Aim Labs called the technique "LLM Scope Violation". What stands out about the case, according to the article, is the number of reasonable controls the attack managed to bypass in a chain: it evaded Microsoft's own injection classifier, sidestepped link redaction using reference-style Markdown, triggered the outbound request through an image the client loaded automatically, and sent the data via a Microsoft Teams proxy that was already trusted by the content security policy. Each control was reasonable on its own, but the full chain defeated them all, leading to the conclusion that prompt injection is already a practical, high-severity class of vulnerability in production, and that the defence must be architectural — least privilege, scoping the data before the model can reach it, continuous adversarial testing — and not simply a better filter.

The second case, ForcedLeak (CVSS 9.4), identified by Noma Security, affected Salesforce Agentforce with the Web-to-Lead feature enabled. An attacker submits a public lead-capture form with a hidden instruction in the Description field (which accepts up to 42,000 characters, enough room for a full payload). When an internal user asks the agent to process the leads, it executes the embedded instruction, queries CRM data and exfiltrates it. The most-cited detail of the case is that the data went out to a domain that still appeared on Salesforce's list of trusted destinations but whose registration had expired; the researchers bought it for five dollars, demonstrating that a domain allowlist verifies where a request is going, but never whether that request should be happening at all. It is the so-called confused deputy problem in production, made worse by the lack of maintenance of those lists.

Two further cases, both tied to the Model Context Protocol (MCP), carry the same pattern into software development. In Supabase MCP, demonstrated by General Analysis, a developer using Cursor with the Supabase connector authenticated via the service_role key — which by design bypasses row-level security and sees every row in the database — asks the agent to review support tickets. An attacker plants a hidden instruction in a ticket asking it to read the integration_tokens table and paste it into the reply; the agent, unable to tell a ticket's content from an instruction, does exactly that. Supabase responded by shipping a read-only, project-scoped mode, which removes the ability to write, but Willison notes that read-only helps and is not enough: a model that can read private data and is exposed to injection will leak it anyway through its own response. In GitHub MCP, exposed by Invariant Labs in May 2025, an attacker opens an issue in a public repository with a hidden instruction; when the victim asks their agent to review open issues, it follows the instruction, pulls content from a private repository and writes it into a pull request in the public repository, where the attacker can read it at leisure. Invariant dubbed it a "toxic agent flow": an architectural problem that does not depend on a specific provider but on any model connected to that MCP server.

From these cases, the article draws a set of common defensive lessons, framed within what it calls the Containment Ladder. First, since the model cannot distinguish data from instructions, the separation must be structural, because no classifier catches every possible phrasing (EchoLeak beat one designed for exactly that). Second, all retrieved or ingested content must be treated as hostile, designing the system so that even if an injection succeeds, it reaches nothing of value. Third, it is worth deliberately breaking one of the trifecta's three legs: if an agent handles untrusted content, it should not also have broad read access to private data and a route out. Meta's "Agents Rule of Two" sums it up: without a human in the loop, an agent should hold at most two of the three conditions, something that can be encoded in cloud permissions, network rules and admission controllers. Fourth, outbound access should be something explicitly granted, not something that comes by default: ForcedLeak, EchoLeak and the MCP cases all needed a route out, and several of them used a destination that was already trusted. Fifth, read-only mode is a real but incomplete control: it prevents theft by writing while leaving the leak through the agent's own response untouched.

The article closes by stressing that none of the copilots analysed deleted anything; for a window of time, several of them worked as a data-theft tool with a recognizable corporate brand. Any organization running an enterprise copilot or an MCP-connected agent with access to private data and the ability to reach the outside world already has the ingredients of one of these incidents. The author's conclusion is that the remedy is structural and lies in each organization's hands, without depending on the vendor to solve it: scope the accessible data, deliberately cut one of the three legs, make outbound access something explicitly granted, and stop asking a domain allowlist for a guarantee it was never designed to provide.