Blog

The Lethal Trifecta, Broken at the API Layer

·7 min read

Simon Willison’s lethal trifecta is the combination of private data, untrusted content and external communication that lets prompt injection steal data from an AI agent. Guardrail models catch many attacks and miss others. Deterministic controls on the private-data and outbound legs – scoped reads, response filtering, destination limits – change the outcome even when the injection succeeds.

Credit belongs with Willison. He named prompt injection years earlier, and on 16 June 2025 he named this particular three-part failure.

The summary that posted the inbox to a form

On 12 January 2026 Willison linked PromptArmor’s disclosure: Superhuman AI, asked to summarise recent mail, followed instructions hidden in an untrusted email and submitted content from dozens of other messages – including financial, legal and medical mail – to an attacker’s Google Form. The root cause PromptArmor and Willison described was a content-security policy that allowed Markdown images from docs.google.com, a host that will persist data sent in a GET. Superhuman treated it as a high-priority incident and issued a fix.

That is the trifecta in one product: the agent could read private mail, it consumed untrusted mail, and it could communicate out (here, by loading an image URL). The injection did not need to steal a password. It needed the three legs at once.

January 2026 was a cluster, not a one-off. Inbox and connector assistants were the obvious surface: private data already connected, untrusted content arriving every minute, and a convenient outbound channel in the same session.

What is the lethal trifecta?

Willison’s three capabilities, in his words’ shape if not a long quotation, are: access to private data; exposure to untrusted content; and the ability to communicate externally in a way that can steal that data.

He is careful about terms. Prompt injection is the mixing of trusted and untrusted content in one context, named by analogy with SQL injection. Jailbreaking – tricking a model into an embarrassing reply – is a different problem. Developers who conflate the two ignore the data-theft case.

The trifecta is sufficient for exfiltration. It is not a complete map of agent harm. Willison later noted that it does not cover every destructive tool action.

What is Meta’s Agents Rule of Two?

It is a session rule, published 31 October 2025 and credited by Willison on 2 November 2025, that an agent should have at most two of three properties until prompt injection can be reliably refused: [A] process untrustworthy inputs; [B] access sensitive systems or private data; [C] change state or communicate externally.

Meta wrote that the rule is inspired by Chromium’s Rule of Two and by Willison’s trifecta. The addition of “change state” pulls in writes, not only exfiltration. If a task needs all three properties in one session, the agent should not run autonomously: it needs human approval or another reliable check.

The Rule of Two is a design constraint. It is not a detector. Meta says it is not sufficient against other agent harms and not a finish line.

Which leg does each control break?

Guardrails try to notice the injection. API-layer controls remove a leg so a missed injection has less to steal or nowhere to send it.

ControlPrivate data (B)Untrusted content (A)External communication / state change ©
Prompt-injection detector / guardrail modelNoTries to catch A; misses remainNo
Scoped reads (only the objects and fields the task needs)Breaks or shrinks BNoNo
Response filtering at the proxyShrinks B: PII never enters contextCan strip injected strings in API bodiesNo
Destination limits (only approved hosts and paths)NoNoBreaks C for arbitrary exfil URLs
Deny writes and side-effect methodsNoNoBreaks state change
Human approval on the third propertyNoNoConverts C into a supervised step

The Superhuman case is a C failure (an allow-listed image host that accepted data) plus A and B in the same session. A destination list that excluded that form, or a session that could not both read the whole inbox and fetch arbitrary URLs, would have removed a leg. A filter that never loaded the rest of the inbox into the same context as the untrusted message would have shrunk B.

This is why MCP security that lives only inside the server is not enough, and why response-side redaction is a trifecta control, not a privacy nicety.

What still belongs to the model layer

Detection, session hygiene and user warnings.

A new session for the untrusted document is a Rule of Two move. Refusing to mix inbox-read and arbitrary-fetch tools in one context is another. Those are product decisions. They fail when a user confirms a prompt they did not read. The API layer is the backstop: the private data the model never received cannot be posted to the form.

Willison’s own caution stands. The trifecta is one class of attack. Writes, fraud and availability are other classes. Break the legs you can break without waiting for a perfect detector.

A design review that only asks “do we have a prompt-injection scanner” will pass the Superhuman-shaped case on paper and fail it in production. Add three questions that do not mention models:

  1. What private objects can this session read, field by field?
  2. What untrusted input can reach the same context as those objects?
  3. What destinations, methods and side effects can the session invoke without a human?

If the answers are “the vendor default,” “anything in the inbox or the ticket,” and “any host the tool library allows,” the trifecta is assembled. Shrink 1, split 2 into another session, or pin 3 to an allow-list. Meta’s Rule of Two is those three questions with a stop-rule: do not run all three unsupervised.

January 2026 will not be the last cluster. Inbox, CRM and MCP tools keep combining the same three properties because that combination is also the product demo. The API layer is how you ship the demo without shipping the form-post.

A practical split that keeps the demo useful: one session summarises an untrusted ticket or email and cannot read the rest of the inbox; a second, later session reads the named objects a human selected and cannot fetch arbitrary URLs. The model still works. The three properties no longer sit in one unsupervised context. That is Meta’s Rule of Two applied as two grants, not as a scanner.

The same split works on a CRM agent. Session one reads the ticket text. Session two is allowed GET on one contact and cannot POST to a webhook host the ticket named. You do not need to prove the injection failed. You need the form-post to be a deny row.

Where RequestRocket fits

RequestRocket sits on outbound calls to APIs you do not host. It can shrink B (scope and filter what the agent may read) and constrain C (only approved targets, methods and paths; no arbitrary host). It does not read the user’s inbox as a mail client and it does not detect injection with a model. Identity and the AI gateway remain the other layers. The complementary map is outbound API governance.

FAQ

Who coined the lethal trifecta?

Simon Willison, in a 16 June 2025 essay. He also coined “prompt injection.” Meta’s Agents Rule of Two (31 October 2025) cites both the trifecta and Chromium’s Rule of Two.

Do guardrail models make the trifecta obsolete?

No. They reduce how often A succeeds. They do not remove B or C. Design for the miss.

Is loading a Markdown image really external communication?

If the URL can carry data to an attacker – query strings, form endpoints, webhook hosts – yes. Superhuman’s January 2026 case used that channel.

Does the Rule of Two require us to drop useful agents?

It requires you not to give one unsupervised session all three properties. Split sessions, shrink data, or add a human on the third property.

How do destination limits work if the vendor is the only host?

The vendor is allowed. The Google Form is not. C is about unexpected outbound, not about calling the CRM you already approved.

Is this the same as a WAF?

A WAF protects inbound traffic to your edge. Exfiltration here leaves through the agent’s outbound tools. Different hop.

Book a walkthrough of RequestRocket

Sources

Enhance ISO 27001
Enhance SOC 2
Enhance GDPR
Enhance HIPAA

Add outbound API security
without changing code

Start on your own or talk to our team about improving the security of every API call you make.