What is the lethal trifecta, and where does the name come from?
The term was coined by independent researcher Simon Willison on his blog in June 2025, describing a common structure he observed recurring across several agent security incidents. He found that data exfiltration incidents that looked independent and had different apparent causes, when traced down to their root, all pointed to the same set of conditions holding at once: the agent could reach something worth stealing (private data access), the agent processed content an attacker could influence (untrusted content), and the agent had the ability to send whatever it stole out (external communication or side effects). The name chose "lethal" rather than gentler terms like "risk" or "weakness" precisely because once all three hold at once, data exfiltration becomes nearly certain — not a matter of probability.
This framework matters not because it uncovered any new technical vulnerability, but because it converted a vague risk that was hard to communicate internally into something a team can check off directly, item by item — the naming was later adopted and cited directly by industry organizations like Meta, evidence of its practical value as a communication tool.
Why did the lethal trifecta become a problem needing a specific name, and what drives it?
The core reason is that each of these three properties, taken individually, is almost a prerequisite for an agent to have any practical value at all — an agent that can't reach any data has no use; an agent that never processes external content, only answering questions the user types directly, has extremely limited application; an agent that can never take any external action stays stuck at the suggestion level, unable to actually help complete a task for the user. This means that in the process of pursuing agent usefulness, businesses and developers have an almost natural incentive to let all three properties converge on the same agent, because each property, viewed in isolation, is a reasonable requirement for "making the agent more useful."
The problem is that once all three properties are present together, they form a complete, usable attack chain: the attacker only needs to get the agent to read an instruction hidden inside untrusted content, and the agent will use its own legitimate private-data access to find something worth stealing, then use its own legitimate external-communication ability to send it out — throughout the entire process, the agent is using capabilities it was authorized to have, with no link showing the "unauthorized access" signal traditional security tools are good at detecting.
How does the lethal trifecta actually play out in real cases, and what known examples exist?
In January 2026, security research team PromptArmor publicly disclosed two independent incidents within five days, both fitting the lethal trifecta pattern exactly. The first involved IBM's coding agent Bob: an attacker hid an instruction disguised as "phishing training" (untrusted content) inside a README file in an open-source project. When Bob read it, it began repeatedly requesting the developer's approval for a seemingly harmless command; once the developer, worn down by repeated prompts, clicked "always allow," Bob chained subsequent operations onto that now-approved permission, accessing and downloading malware (private data access / external communication), without any further human approval. The second involved Notion AI: a timing flaw in its document-editing feature let an attacker use indirect prompt injection to get Notion AI to read a disguised document (untrusted content), exfiltrating a user's confidential hiring-tracker data as a result (private data access plus external communication).
Neither attacker needed to bypass a login or find a code exploit — both were simply the natural outcome of all three lethal-trifecta properties being present at once. This is also why the security community believes smarter system prompts or detection classifiers alone can't fully solve the problem, since the issue lies at the architectural level of which capabilities combine, not in any single instance of misjudgment.
What does the lethal trifecta mean for me, and how should I respond in practice?
If your organization is deploying or evaluating agents with data access, this framework turns a vague risk into something you can audit and sign off on item by item — list whether each agent satisfies all three properties on any single operational path; if the answer is yes to all three, that's a structurally vulnerable design needing priority attention. In October 2025, Meta's AI security team publicly published a practical method built on this framework, called the "Rule of Two": an agent, within a single session, may satisfy at most two of the three properties, ensuring that even if an attack instruction is successfully injected, the attack chain gets physically broken at some point.
This can be implemented through three concrete configurations: let the agent process untrusted content and communicate externally, but give it no access to private data at all; or let the agent access private data and process untrusted content, but require every outbound send to be confirmed by a human first; or let the agent access private data and communicate externally, but strictly limit it to fully trusted, controlled input sources. This bears directly on accountability too: a document stating clearly "we knew this agent had a lethal trifecta and accepted the risk because of mitigation X" represents an entirely different level of governance responsibility than deploying without ever assessing it at all.
In January 2026, security research team PromptArmor publicly disclosed two independent incidents within five days — IBM's coding agent Bob and Notion AI — both fitting the lethal trifecta pattern exactly. Meta's AI security team had already publicly published its "Rule of Two" defense methodology, built on this framework, in October 2025.
Strictly following the Rule of Two ensures the attack chain gets physically broken at some point, but sacrifices some user experience or functional flexibility — an agent that could originally both read an inbox and auto-reply might, to break down to two properties, need to switch to "draft first, send only after user confirmation," meaning the user has one more approval step. Ignoring the lethal trifecta entirely in pursuit of maximum autonomy and convenience directly inherits every risk this framework describes. There's no option that has it both ways — only a tradeoff made according to how much risk you can tolerate.