The Lethal Trifecta

The lethal trifecta is a structural pattern in AI agent deployments that virtually guarantees data theft. The term was coined by Simon Willison, the engineer who first formalised the concept of prompt injection.

An AI agent has the lethal trifecta if it has all three of these properties simultaneously:

1. Access to private data. The agent can read information that should not be shared publicly — your inbox, your calendar, your customer database, your source code, your file system.

2. Exposure to malicious instructions. The agent processes content from untrusted sources. Someone outside your organisation can put text in front of the agent — by sending you an email it reads, by publishing a webpage it visits, by submitting a support ticket it processes.

3. The ability to exfiltrate. The agent can send information out of your environment. It can email, post, call an external API, write to a public file, or otherwise transmit data beyond the trust boundary.

If an agent has all three, you have a security catastrophe waiting to happen. It is not a matter of if; it is a matter of when someone exploits it.

The natural instinct on hearing this is to say: "We will filter the malicious instructions." That instinct is wrong, and understanding why it is wrong is the most important thing about the lethal trifecta.

You cannot reliably filter malicious instructions out of natural language. Detection systems get to perhaps 97% accuracy on known attack patterns. That sounds good. It is not. Three percent of attempts will succeed. If you process a thousand emails a day, that is thirty successful attacks. If your agent has access to your customer database, that is thirty exfiltration events.

Worse: filters are an arms race. Every published defence becomes a target. Every model you train to detect prompt injection becomes a model attackers can probe to find what it does not detect. The space of possible adversarial inputs is unbounded. The space of trained defences is finite.

The only reliable defence is structural: cut one of the three legs.

Cutting the trifecta is an architectural decision, not a configuration setting. You design the agent so that it cannot have all three properties at once.

Cut data access. Run the agent in an environment where it does not have access to private data. This is the easiest cut for many use cases. A coding agent that operates on a public repository has no private data to leak.

Cut malicious instruction exposure. Restrict the agent to processing content from trusted sources only. If your agent only ever sees text written by your own employees, who you have authenticated and who have agreed to your acceptable use policy, you have cut this leg. The moment it processes content from outside your trust boundary, the leg grows back.

Cut exfiltration. Make it structurally impossible for the agent to transmit data outside your environment. Block all outbound network calls. Restrict file writes to a controlled location. Require human approval for any communication that crosses the trust boundary. This is often the easiest cut for high-stakes use cases.

For most production AI agents, cutting exfiltration is the most practical defence. The agent can still read your data and process untrusted input, but it cannot send the data out. Any output goes through a human review step or a structurally constrained channel.

The lethal trifecta is everywhere because the most useful agents are the ones with all three properties. People want a personal assistant that reads their email, processes incoming messages, and replies. That has the trifecta by definition.

Personal email assistant. Reads your inbox (private data). Processes incoming emails (malicious instructions). Replies and forwards (exfiltration). This is the canonical lethal trifecta. Every personal email AI built without architectural defence is one prompt injection away from leaking your inbox.

Customer support bot with database access. Reads customer data (private data). Processes customer messages (malicious instructions). Replies to customers (exfiltration). An attacker can submit a support ticket containing instructions that cause the bot to send other customers' data back to them.

Code review bot for public PRs. Reads internal code (private data). Processes pull request content from outside contributors (malicious instructions). Comments on PRs publicly (exfiltration). An attacker submits a PR with hidden instructions that cause the bot to leak internal code in a public comment.

Voice assistant integrated with smart home and contacts. Microphone input (potential malicious instructions if anyone can speak near the device). Access to contacts and smart home state (private data). Can send messages and place calls (exfiltration). Lower probability than text-based attacks, but the lethal trifecta is present.

Constellation treats the lethal trifecta as a first-class concept. Every agent registered in Constellation declares its capabilities, and Constellation evaluates whether those capabilities form a lethal trifecta.

When you register an agent, Constellation asks three questions:

1. **What private data can this agent access?** (Specific systems, scoped to specific resources.) 2. **What untrusted input sources does this agent process?** (Email, web content, user-submitted forms, external APIs.) 3. **What channels can this agent use to send information out?** (Email, API calls, file writes, public posts.)

If the answer to all three is non-empty, Constellation flags the agent as having a lethal trifecta. The flag does not block the agent — it requires explicit acknowledgement and a documented mitigation. The mitigation must explain which leg has been structurally cut and how.

Constellation also runs continuous self-tests. Every consequential action an agent takes goes through the governance gate, which checks the action against the constraints set for the agent. If the action would expand the agent's capabilities into a lethal trifecta configuration, the gate blocks the action and escalates.

This is not a perfect defence — nothing is. But it converts an invisible risk into a visible, documented, contestable risk. The organisation that deployed the agent now has an artefact that says "we knew the agent had a lethal trifecta and we accepted it because of mitigation X." That is the difference between negligent governance and informed risk acceptance.

Simon Willison has been predicting a catastrophic lethal trifecta exploit for several years. As of 2026, no headline-grabbing incident has occurred — not because the attack is hard, but because it has not yet been worth executing at scale.

The conditions that will produce the disaster are accumulating. AI personal assistants are proliferating. OpenClaw and similar tools have hundreds of thousands of users. Each one is a target. The first major incident will involve a sophisticated attacker compromising a high-value individual's AI assistant through prompt injection in an inbound email, exfiltrating private correspondence or financial data, and publishing it.

When that happens, every organisation deploying AI agents will be asked: did you know about the lethal trifecta? Did you check your deployments for it? Did you have a documented mitigation? The organisations that can answer yes will be fine. The organisations that cannot will face the same accountability questions that followed every previous wave of preventable security failures.

The point of detecting the lethal trifecta is not to prevent every possible exploit. It is to make sure the question "did you know?" has an auditable answer.