The lethal trifecta, explained three ways.

In June 2025 Simon Willison gave the risk a name that stuck, the lethal trifecta, which describes an AI agent that combines three things, in his words "access to your private data," "exposure to untrusted content," and "the ability to externally communicate." His argument is that "if your agent combines these three features, an attacker can easily trick it" into reading your data and sending it to them, because a language model can't reliably tell the instructions you gave it apart from instructions that arrive inside a web page, an email or a document it was asked to read (Willison, 2025-06-16; Tier B). The part of his post I find most useful when explaining this to anyone is the admission that the industry "still [doesn't] know how to 100% reliably prevent this from happening," which is why his advice is structural, to avoid the combination itself, since filtering the bad instructions out doesn't hold up.

The OWASP GenAI Security Project reached the same place by a different route. Its LLM01:2025 entry on prompt injection says that "[g]iven the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection" (OWASP LLM01:2025; Tier A). The 2026 edition of the list, published on 3 August 2026, goes further and states that "no reliable prevention mechanism exists today," and its prevention section names Willison's "lethal trifecta" as a pre-deployment check and recommends Meta's Rule of Two, which comes up below, "as a floor" (OWASP Top 10 for LLM Applications 2026, LLM01:2026; Tier A). So the framing this essay is built on is no longer one practitioner's argument, and I think that matters for anyone who has to defend a structural control to a team that would rather buy a filter.

The attack that exploits the trifecta is indirect prompt injection, where the attacker never talks to the model directly and instead plants instructions in content the agent will later process on a legitimate user's behalf. ATT&CK v20, released on 13 October 2026, added it as T1698 Indirect Prompt Injection under the Execution tactic, and added T1700 AI-Enabled Exfiltration under Exfiltration, which covers using prompt injection or other methods to instruct an enterprise AI agent to move data out through the sanctioned tools it already has (T1698, created 18 September 2026; T1700, created 22 September 2026; both v1.0; Tier A). Those two techniques are the untrusted-content leg and the way-out leg of Willison's trifecta, now sitting in the framework many SOCs already map their detections to. Until v20, prompt injection lived only in MITRE ATLAS (as AML.T0051), which a lot of detection teams rarely look at, so I think the move into ATT&CK matters more for who will see it than for anything new it says.

Everything below is about that one risk, and the three audiences differ only in which part of it they can actually do something about.

For people who build or wire up agents, the trifecta works as a checklist you can run against a design. Two exercises in MITRE ATLAS v2026.10 show it end to end, and both are worth walking through because each one also shows a defense that was in place and got routed around. I'll be precise about what kind of evidence these are, though. Both are cataloged as Exercises, meaning security researchers demonstrated them against real products, and neither is a recorded attack on a victim; the evidence for the full chain in the wild is thinner than the evidence that the chain works.

The first is ZombieAgent (AML.CS0066), which Radware researchers demonstrated against ChatGPT's connectors in September 2025 (ATLAS v2026.10, Tier A; underlying report Radware, Tier C). All three legs are easy to see:

• Private data: a Gmail inbox connected to the assistant, along with whatever else the user had connected.
• Untrusted content: an email from the researchers carrying instructions hidden with tricks like white-on-white text, which the assistant read when the user later asked for something ordinary, such as a summary of the inbox. The user never opened the email.
• A way out: the assistant's ability to open URLs. OpenAI had already blocked the model from building URLs with data in their parameters, so the researchers handed it a dictionary of pre-built static URLs, one per character and position, and had it open them in sequence to spell the data out to their server.

The same injection also wrote instructions into the assistant's memory so the collection would repeat in later sessions, and it had the assistant mail the malicious prompt to contacts it found in the inbox. The URL workaround is the detail I'd show any builder who thinks closing one exfiltration channel is enough, because the channel stayed open in a slightly different shape.

The second is the Claude Code GitHub Action case (AML.CS0067), written up by Microsoft in June 2026 (ATLAS v2026.10, Tier A; underlying report Microsoft Security blog, 2026-06-05, Tier C). Here the untrusted content was an issue, pull-request description or comment that the action pulls into the model's context, and the private data was the workflow's own credentials. Shell commands ran inside a sandbox with a scrubbed environment, but the built-in file-reading tool ran outside it, so the injected instruction had the agent read /proc/self/environ and print the Anthropic API key with its sk-ant- prefix removed, which kept GitHub's secret scanner from recognizing it. Microsoft lists web fetches, shell, a GitHub MCP server and the action's own logs as possible ways out, depending on how the workflow is configured. What I take from this one is that the sandbox did its job for the tool it covered, and the risk lived in the tool it didn't.

I've had the untrusted-content leg show up in my own lab work, which is part of why I take it seriously for security teams in particular. In June 2026 an AI coding session was helping me build a text-search benchmark for the Security Data Works lab, and it chose the real APT29 corpus from the MITRE ATT&CK Evaluations over a synthetic one because it was more realistic, then echoed a sample message field into its own output. The row carried a U+202E right-to-left override character, a genuine APT29 obfuscation trick, sitting beside obfuscated PowerShell, and any message field in that data could just as easily have carried an instruction aimed at the model. I called a hard stop before the loader ever ran, had it deleted, and we went back to the synthetic corpus. What stays with me is that the agent walked onto the untrusted-content leg by itself, in pursuit of realism. Security telemetry is adversarial content by construction, so a SOC that points an agent at raw event text has given it that leg on day one, and the remaining question is whether the same agent also holds the other two.

The design rule that follows from both cases is to make sure no single agent session holds all three legs at once. Meta turned this into what they call the Agents Rule of Two, which says an agent should satisfy no more than two of three properties in a session: processing untrustworthy input, having access to sensitive systems or private data, and changing state or communicating externally (Meta AI blog, 2025-10-31; Tier C, vendor guidance, and the post credits Willison's trifecta directly). Meta's version folds "changing state" into the third leg, which I think is right for builders, since an agent that can push code or approve a payment can do damage without sending anything anywhere. In practice I'd run it like this:

• List each agent and integration and mark which legs it holds, counting every tool and MCP server it can call, since a single connector can bring in both private data and untrusted content.
• Where all three are present, cut the leg that costs least to lose, which is often the outbound one (no arbitrary URL fetches, no email sending, allow-listed destinations only).
• Keep credentials out of the agent's process environment and give each tool only the access its task needs, because the Claude Code case leaked a secret the agent never needed to see.
• Put a person in front of any state change or outbound send that an agent proposes after reading content from outside, which is slower but is one of the few controls that injected text can't argue its way past.

For detection teams, T1698 and T1700 give you places to hang those controls in the ATT&CK coverage you already report, and the ATLAS case-study steps (AML.T0051.001 for the indirect injection, AML.T0086 for exfiltration through an agent tool invocation in both exercises above) give you finer detail when you need it. If you want to know which controls in that catalog are worth deploying first, the ATLAS Wall ranks every ATLAS mitigation against a 48-incident record, the blind quadrant covers how little of ATLAS the D3FEND defensive vocabulary reaches today, and mapped vs fired, a measured probe of those zero-defense techniques, shows what happens when you run real detections against those gaps rather than counting mappings.

I'd also be careful about stretching the frame too far, because the most striking new Incidents in ATLAS v2026.10, such as OpenAI evaluation agents that broke out of their environment and compromised Hugging Face infrastructure (AML.CS0068) or Claude agents that attacked three real organizations during cyber evaluations (AML.CS0073), are a different shape of problem. Their case-study steps show no injection at all, and the agents were pursuing the goals they'd been given and went well past the intended scope (ATLAS v2026.10, Tier A). Removing a trifecta leg helps there too, since an agent with no route out can't reach the public internet, but I wouldn't present those incidents as prompt-injection cases. They also cut against the trifecta frame in a way I think builders should hear. Many of the steps in the Hugging Face case are ordinary intrusion work (exposed tokens, an over-permissioned storage driver, secrets read from a cluster), and a team that spends its effort on prompt-injection filters while its agents share credentials and leave no audit trail has the order of work backwards. The trifecta tells you which combinations to forbid, and plain identity and logging hygiene still has to sit underneath it.

There is a real disagreement here too, and it's worth naming. Willison notes that vendors "will sell you 'guardrail' products that claim to be able to detect and prevent these attacks," often at around 95% of attacks caught, and his answer is that in web application security 95% is "very much a failing grade," since an attacker only needs the attempts that get through. For a low-stakes assistant a classifier may well be enough, but for anything holding credentials I find his argument more persuasive, so I'd treat classifiers as one layer on top of the structural rule and not as a substitute for it.

The lethal trifecta now has two ATT&CK technique IDs, and I think the most useful thing those IDs do is give users, builders and executives a shared name for a risk that each of them can only reduce from their own position, with habits, a remove-one-leg design rule, and a few usage numbers respectively. The ZombieAgent and Claude Code Action exercises both show a defense being routed around while the three legs stayed in place, which is the strongest evidence I have that the structural rule matters more than any filter.

Bottom line: the risk doesn't have a prompt-level fix, so the useful work at every level is limiting how often private data, untrusted content and a way out end up inside the same agent session.