The Lethal Trifecta: A Framework for Agent Data Exfiltration

The lethal trifecta is a framework, coined by security researcher Simon Willison on June 16, 2025, for reasoning about when an AI agent becomes capable of leaking data it should not leak. It names three properties that, together, create an exfiltration path: access to private data, exposure to untrusted content, and the ability to communicate externally. Any one or two of these properties on their own are usually manageable. All three present at once in a single agent, or a single reasoning context, is what turns prompt injection from an annoyance into a data breach.

The three legs, and why each one alone is manageable

Consider each property in isolation:

• Access to private data alone is just what most useful agents need — a customer support agent needs customer records, a coding agent needs your source, a research agent needs your documents. Nothing dangerous here by itself.
• Exposure to untrusted content alone is also normal — an agent that reads web pages, emails, or files that originated outside your organization is exposed to content it does not control, but if that agent has no private data and no way to communicate externally, there is nothing valuable for a malicious instruction embedded in that content to steal.
• The ability to communicate externally alone — sending emails, posting to APIs, writing to a shared location — is unremarkable if the agent never touches private data and never processes untrusted content that could redirect that communication.

The danger appears specifically at the intersection. An agent with private data and the ability to communicate externally, that also processes untrusted content, has everything an attacker needs: something worth stealing, a way to steal it, and a channel through which to inject the instruction to do so. This is why the trifecta framing is more useful than a generic "prompt injection is bad" warning — it tells you exactly which combination of capabilities to look for, and which single change removes the risk.

Why this is a framework, not a vulnerability

It is important to be precise about what the lethal trifecta is not. It is not a bug, a specific exploit, or a CVE — there is no patch for it. It is a way of reasoning about agent configurations: given an agent's toolset, does it simultaneously have all three properties? If yes, the trifecta predicts that a sufficiently motivated attacker who can get untrusted content in front of the agent — a web page it reads, an email it processes, a document it summarizes — can potentially direct that agent to exfiltrate whatever private data it can reach, through whatever external channel it has access to.

This connects directly to prompt injection itself, a term Willison also coined, drawing the analogy to SQL injection: the underlying problem in both cases is mixing trusted instructions and untrusted data in the same context, with no reliable way for the receiving system to tell them apart. For the mechanics of how that mixing happens and how to detect it, see how to detect prompt injection and prompt injection threats and defenses. The lethal trifecta is the framework for deciding which agent configurations turn that general problem into a specific, high-stakes exfiltration risk.

A worked example

A common real configuration illustrates the pattern clearly: a coding assistant agent with access to a private code repository (private data), configured to read GitHub issues to help triage them (untrusted content — anyone can open an issue), and with the ability to open pull requests or post comments (external communication). An attacker opens an issue containing text designed to look like an instruction to the agent rather than a bug report — for instance, text that instructs the agent to include the contents of a private configuration file in its next comment. If the agent cannot distinguish "instructions from my operator" from "text I am summarizing," it may comply, and the private data leaves through the very GitHub API access it was granted for legitimate work. Each of the three capabilities was individually reasonable to grant; the combination created the exposure. Independent security tooling has since built directly on this framing — test suites exist specifically to probe for trifecta configurations, and it appears in agent-security pattern catalogs as a named, recurring threat model, not a one-off observation.

Applying the trifecta: a mapping checklist

Use this as a first pass across any agent or workflow you are evaluating:

If an agent scores "yes" on all three rows, it satisfies the lethal trifecta and warrants the closest scrutiny in your environment — not because it is definitely compromised, but because it is definitionally exposed to the pattern that makes exfiltration possible.

Breaking the trifecta: remove a leg, don't just filter harder

The structurally sound response to a trifecta-satisfying agent is to remove one of the three legs, not to try to filter untrusted content well enough to catch every malicious instruction — content filtering helps, but it is a probabilistic defense against an adversarial input, and the trifecta framework exists precisely because that defense alone has repeatedly proven insufficient. Removing a leg is a structural fix instead of a detection race:

• Remove private data access — give the agent read access only to what it needs for the specific untrusted-content-processing task, not broad standing access to sensitive systems. This is the general principle behind least-privilege access for agents.
• Remove untrusted content exposure — if an agent truly only needs to operate on trusted, internally-generated data, don't also route external content through the same context or the same session.
• Remove or gate external communication — require a human approval step before an agent's output leaves the system via email, API call, or public post, particularly when that agent has also processed content from outside the organization. See human-in-the-loop approvals for agents.

In practice, most real agents need some version of all three capabilities to do useful work, which is why the more common mitigation is scoping and separating them rather than eliminating any one outright — a research agent that reads the untrusted web can be denied direct access to the customer database and instead pass findings to a separate, privileged agent that has no external-communication tool of its own. This kind of capability separation across multiple cooperating agents is covered generally in orchestration patterns for multi-agent systems and in the broader AI agent security guide.

The trifecta and data exfiltration risk more broadly

The lethal trifecta is a lens for reasoning about one specific exfiltration pathway — the one that runs through prompt injection and an agent's own legitimate tool access. It sits inside the broader landscape covered in data exfiltration risks in agentic AI, which addresses exfiltration through other paths as well, including compromised credentials, over-broad tool scope, and misconfigured logging. Teams building an incident-response playbook should treat "does this agent satisfy the trifecta" as one specific, checkable question within that larger threat model, not the whole of it.

Common questions

Who coined the lethal trifecta, and when? Simon Willison, an independent security researcher, published the framing on June 16, 2025. He also coined the term "prompt injection" itself, drawing the analogy to SQL injection.

Is the lethal trifecta a specific vulnerability I can patch? No. It is a reasoning framework for identifying which agent configurations are structurally exposed to prompt-injection-driven data exfiltration — private data access, untrusted content exposure, and external communication ability present together. There is no single patch; the fix is removing or scoping one of the three capabilities for the specific agent in question.

Does content filtering solve the lethal trifecta problem? Not reliably on its own. Filtering untrusted content for injected instructions helps reduce risk, but it is a probabilistic defense against adversarial input crafted specifically to evade it. The structurally sound fix is removing or scoping one of the three legs — private data, untrusted content, or external communication — rather than relying solely on catching every malicious instruction.

Can an agent satisfy the trifecta across a delegation chain, not just individually? Yes, and this is a common oversight. An orchestrator agent with no direct trifecta exposure can still create risk if it delegates to a sub-agent with private data access and a sub-agent with untrusted content exposure and external communication ability, and information flows between them. Evaluate the trifecta at the level of the overall workflow, not only per individual agent.

How is this different from general prompt injection defense? General prompt injection defense focuses on detecting or resisting malicious instructions embedded in content. The lethal trifecta is a prioritization framework layered on top: it tells you which agents' prompt injection risk actually translates into a data-exfiltration risk worth treating as urgent, because they hold all three properties simultaneously.