The Lethal Trifecta

In June 2025, Simon Willison published a short piece naming the condition under which an AI agent becomes dangerous. He called it the lethal trifecta, and it is the most useful three-part idea in this field.

An agent is exposed when all three of these are true at once:

1. Access to private data. Which is usually the entire reason the agent exists.
2. Exposure to untrusted content. Any mechanism by which text or images controlled by an attacker can reach the model.
3. The ability to communicate externally, in a way that could carry data out.

Any two of the three is survivable. All three is an exploit that someone has not written yet.

Why two is survivable

The arithmetic is worth doing slowly, because it is what makes the framing an engineering tool rather than a slogan.

Private data plus untrusted content, no outbound channel. An attacker can make the model read a poisoned document and conclude something wrong. They cannot find out what it concluded. The attack lands in a room with no door.

Private data plus an outbound channel, no untrusted content. The agent can send things, and it has things worth sending, but nobody can tell it to. Everything it processes comes from inside your boundary.

Untrusted content plus an outbound channel, no private data. An attacker fully controls the agent. It has nothing worth stealing. They have compromised a machine that knows nothing.

Now add the third leg to any of these and the picture changes completely. The attacker instructs, the agent reads, the data leaves.

This is why the trifecta is more useful than a risk score. It does not ask you to estimate probability or impact. It asks three yes-or-no questions about your architecture, and the answers are facts rather than opinions.

The third leg is wider than you think

Most teams audit the first two legs correctly and get the third badly wrong, because they picture exfiltration as an HTTP POST to an attacker's server.

Willison's own formulation is broader, and worth quoting as the standard: if a tool can make an HTTP request, to an API, or to load an image, or even by providing a link for a user to click, that tool can carry stolen information back to an attacker.

Sit with the last clause. A link the user clicks is an outbound channel. Your agent does not need network access at all. It needs only to render something a human will interact with, and humans click links in output they asked for.

The list of things that supply leg three, in systems whose owners believe they have no outbound channel:

• Rendering markdown that contains images, which fetch on display
• Any citation or source link in generated output
• A tool that fetches a URL to summarise it
• Error messages that echo arguments into an external logging service
• Writing to any store a third party can read
• DNS resolution, which is enough to carry a few dozen bytes at a time

An agent that "just answers questions" and renders its answers as markdown has leg three. This surprises people, and it is the most common finding when the audit below is run for the first time.

All three legs, in a real system

The clearest published demonstration is EchoLeak, tracked as CVE-2025-32711, against Microsoft 365 Copilot.

The three legs line up exactly. Copilot has access to the user's mail and documents, which is leg one and the entire product. It reads incoming email, which is leg two, and an attacker can put an email in front of it without any cooperation from the victim. Copilot's output renders markdown, and markdown images are fetched when displayed, which is leg three.

The attack needs no click. An email arrives carrying instructions. Copilot processes it as part of ordinary work, follows the instructions, retrieves something sensitive from the user's own data, and encodes it into the URL of an image it renders in its reply. Displaying that reply fetches the image. The fetch carries the data to a server the attacker controls.

The victim did nothing but open their assistant. There was no attachment to avoid, no link to resist, no warning sign to miss, and no moment at which a cautious user could have behaved differently.

Notice which leg was the cheap one. Copilot could not stop reading mail, and could not stop having access to the user's documents, because those are the product. What it could have done is refuse to render an image whose URL was assembled from content it had just read. That is a rendering decision, not an AI problem, and it is the kind of fix chapter 10 is made of.

Grading the legs

The binary table is where to start, but a leg is rarely fully open or fully shut, and the grading is where the second pass earns its time.

Leg three in particular sits on a scale. An agent that can POST anywhere on the internet is wide open. One that can send mail only to addresses inside your own tenant is much narrower, though not closed, since an insider or a compromised internal mailbox still receives it. One that can only write to an append-only internal log is narrower still.

The same applies to leg one. An agent with a connection string to the whole database has a wider first leg than one holding a scoped token for a single customer's records, which is what chapter 8 is about.

Mark the binary answer first, because that is the screening question. Then write a second column with the width, because that is what tells you where the next hour of work belongs.