The lethal trifecta: private data, untrusted content and external communication

Any agent holding all three can be tricked into sending private data to an attacker, and the trick needs no vulnerability in the agent's code.

Simon Willison named the pattern in June 2025 and the reasoning is compact: LLMs follow instructions found in content, so an agent that reads untrusted content while holding private data and an outbound channel is an exfiltration system with a natural language interface (The lethal trifecta for AI agents).

Why does the lethal trifecta matter now?

Agent products have spent two years adding legs. Browsing, email, file access, chat, code execution and arbitrary HTTP are all reasonable features individually, and each one is a leg of the trifecta. Default configurations rarely have a view on the combination.

The attack data describes how reliably the combination fails. On the Gray Swan indirect prompt-injection benchmark, an attacker with 15 attempts succeeded against Claude Opus 5 2.0% of the time, while GPT-5.6 Luna reached 43.9% (Anthropic Transparency Hub). At the other end of the scale, the largest public agent red-teaming competition recorded 1.8 million attacks and more than 60,000 successful policy violations across 22 frontier agents (arXiv:2507.20526).

The structural reason is the one the UK NCSC states plainly: models do not enforce a security boundary between instructions and data inside a prompt, and prompt injection may never be fully mitigated the way SQL injection was (NCSC). If instruction and data share a channel, then any content the agent reads can issue instructions.

Safeguards help and do not settle the question. Anthropic's browser work took attack success from 13.8% to 1.9% for one model and from 8.0% to 1.4% for another, and the team's own note is that a 1% attack success rate "still represents meaningful risk" (Anthropic). OpenAI measured ChatGPT agent resisting active data-exfiltration attacks in the visual browser 67% of the time, which means it failed about a third of the time under those test conditions (ChatGPT Agent System Card).

MCP makes the trifecta easy to assemble by accident. A documentation server, a web fetch tool and a chat integration in one project config is three lines, and 88% of surveyed MCP servers require credentials, which suggests how much private data the tool layer already reaches (Astrix).

How exposed is your setup? Compass asks the questions that identify which of your agents hold all three legs: compass.alyria.ai.

How does the trifecta produce an exfiltration?

The chain has five steps, and none of them looks like an attack in a log.

1. The agent reads content an attacker influenced. A shared document, a web page, an issue body, a tool result, a calendar invite, a support ticket.
2. The content contains an instruction that is plausible in context, such as summarising a document and posting the summary to a URL for review.
3. The model follows the instruction, because the instruction is in the same channel as the data and carries no lower authority.
4. The agent uses its private data access to assemble the payload, from files, a database, a mailbox or a credential store.
5. The agent uses the outbound leg to send it: an HTTP call, an email, a comment on a public repository, a calendar event, a form submission.

Each step is a normal tool call, which is why detection has to look at the sequence and the arguments rather than at any single event.

How is the lethal trifecta different from prompt injection?

Prompt injection is the trigger. The trifecta is the condition that makes the trigger worth pulling.

	Prompt injection	The lethal trifecta
What it is	An instruction smuggled into content	A capability combination in an agent
Where it lives	In the input the model reads	In the agent's design and configuration
Can it be patched	No, by the NCSC's assessment	Yes, by removing a leg
Who owns the fix	Nobody fully	The team that scoped the agent
Detection signal	Content patterns, hard to generalise	Capability inventory, easy to enumerate
Failure outcome	The model does something unintended	Private data leaves the organisation
Residual risk	Always present	Removable for a given agent

In practice: You cannot stop the attacker from writing content. You can stop the agent from holding all three capabilities at once.

What are the main variants?

The assistant with browsing, files and email

The most common shape in consumer and enterprise assistants. It reads your documents, browses the web and can send mail. Any web page it reads is a potential instruction, and the mailbox is the outbound leg.

The coding agent with repository, issues and network

The repository is private data. Issues, pull requests, READMEs and dependency documentation are untrusted content. Package installs and HTTP calls are the outbound leg. The GitHub MCP toxic flow used exactly this shape, with a public issue steering the agent into leaking private repository data through a pull request (Invariant Labs).

The support agent with customer records, tickets and an API

Customer data is private. Ticket bodies are attacker-controllable, because customers write them. The outbound leg is a webhook, a reply or an internal API that can reach the internet. This variant is common in pilots because support is an obvious automation target.

The retrieval assistant with documents, web search and write access

Retrieval supplies private data and untrusted content in the same pipeline, which is the worst version: the poisoned text and the secret sit in one context window. A write tool then completes the trifecta.

The split trifecta across agents

Two agents where one has private data and another has outbound access can reconstruct the trifecta if they exchange free-text context. Splitting is only a control when the handoff is structured and validated, not when it forwards a conversation.

In practice: Every variant is discovered the same way: list the three capabilities per agent and look for the intersection.

How to remove a leg

The goal is not to defend all three. It is to make sure no single agent holds all three, and to bound the damage where business needs force a compromise.

1. Inventory the three legs per agent

For each agent, record whether it can read private data, whether it consumes content you do not control, and whether it can send data anywhere. This is a table with three columns and it takes an afternoon for a fleet of fifty agents.

Tip: Treat "can it reach the internet" as a question about destinations, not a yes or no. An allowlist with one endpoint is a different risk from open egress.

2. Remove the outbound leg first

Replace sending with drafting. Restrict egress to named destinations. Where an agent genuinely must send, route it through a proxy that logs the payload and refuses unknown hosts. This is usually the cheapest leg to remove.

3. Narrow the private data leg

Scope reads to the minimum the task needs, drop columns and documents that add nothing, and keep credential stores out of reach entirely. A read-only agent with a narrow data scope limits disclosure even when an injection succeeds.

4. Treat untrusted content as untrusted

Provenance helps: separate content that arrived from outside your boundary, and refuse to combine it with private data in one context where the task allows. Where it cannot be avoided, decide the action deterministically after the model has read it.

5. Put a decision between reading and sending

Endpoint policy can refuse a send whose payload contains data the agent read in the same session from a private source. That is an information-flow control rather than a content filter, and it does not depend on recognising the attack.

6. Keep a human at the last step

For high-impact sends, a named human approves with the exact content visible. Approval works when it is rare and specific, which is why removing two legs is a precondition for approval being a real control. See Human in the loop approvals.

7. Test the exfiltration path deliberately

Plant an instruction in a document the agent can read and confirm that the resulting send is refused, held or recorded. Test with repetition, because attack success rises with attempts: one injection attempt hijacked a computer-use model 17.8% of the time, and 200 adaptive attempts reached 78.6% without safeguards (Claude Opus 4.6 System Card).

8. Accept and document the residue

Some agents cannot avoid two legs, and a few cannot avoid three. Where that is a business decision, write it down with the compensating controls, the monitoring and the owner. Undocumented acceptance is how the trifecta ends up in production by default.

Where the lethal trifecta applies in the agent lifecycle

Design

The three legs are chosen at design. A capability list that names browsing, mail and file access has built the trifecta before a line of policy exists.

Note: Feature requests rarely say "add an outbound channel". They say "let the agent reply". The leg is added in the language of convenience.

Development

Keep the legs visible in configuration. A single capability manifest per agent, reviewed with the code, is more effective than a policy written afterwards.

Pre-deployment testing

Test the combination, not the parts. The failure appears only when untrusted content, private data and an outbound path meet in one session.

Note: A test where the injected instruction is ignored is weaker evidence than a test where the send is refused. Prefer the control that holds when the model complies.

Deployment

Confirm egress destinations, data scope and the approval path at deployment. Verify that the audit record captures the read and the send in one trace, because that trace is what an investigation needs.

Runtime

Enforce the information-flow rule: refuse sends that carry data from a private source read in the same session, unless approved. This is the control that generalises across unknown attacks.

Continuous monitoring

Watch for new destinations, new tools, new data sources and any agent whose capability set gained a leg. Capability drift is the leading indicator, not the incident.

Note: When a team adds a browsing tool to an agent that already has customer data, that is a trifecta event even if nothing has gone wrong yet.

Decommissioning

Revoke credentials, remove tool registrations and keep the record. An orphaned agent with all three legs is the worst kind of leftover.

The takeaway: The trifecta is a design review question. Ask which three legs this agent has, and make someone defend the third.

Worked example: a customer operations assistant

A subscription business builds an assistant for its customer operations team. It reads the customer database, searches a public help centre and drafts replies. The team asks for one more feature in week two: send the reply directly, because copying the draft into the mail client is tedious.

The third leg. Sending turns the assistant into a trifecta. Customer records are private data. The help centre and inbound tickets are untrusted content. The mail tool is the outbound path. The feature request is reasonable and it completes the pattern.

The compromise that was not one. The security team proposes keeping the send but restricting it: replies can only go to the customer's address on the record, attachments are disabled, and any reply that references a ticket containing an external link is held for review. Egress is limited to the mail provider's API. The team accepts, and the assistant keeps the feature.

The test that failed. A sample ticket is created containing an instruction to include the account's payment details in the reply. The assistant complies: it composes a reply with the payment details and attempts to send it to the customer's address rather than the attacker's, because the send restriction holds. The payload is wrong and the destination is right. That is a disclosure to a customer rather than an exfiltration, and it is still an incident.

The added control. Policy now refuses a send whose body contains data the assistant read from the payment table during the same session, unless the request came from an operator action. The rule is an information-flow constraint, it does not depend on recognising the injected text, and it holds when the model is fully persuaded.

The quarterly review. Three months later a team asks for a web browsing tool so the assistant can check public documentation. That request is refused, because browsing adds an untrusted content source to an agent that already has private data and an outbound path. The request is redirected to a separate research agent with no customer data and no send capability.

Outcome. The assistant kept the feature that mattered, the exfiltration path was closed by construction, and the capability table is what made the third request answerable in a meeting rather than after an incident.

How standards and regulations influence the lethal trifecta

Framework	Primary focus	Relevance to the trifecta
OWASP Top 10 for Agentic Applications 2026	ASI01 goal hijack, ASI02 tool misuse, ASI09 human-agent trust exploitation	Frames the combination as agent-level risk
OWASP Top 10 for LLM Applications	LLM01 prompt injection, LLM02 sensitive information disclosure, LLM06 excessive agency	The application-level components of the three legs
OWASP MCP Top 10 (beta)	MCP06 contextual payload injection, MCP10 context over-sharing	Shows how servers assemble the legs
NIST AI RMF	Govern, Map, Measure, Manage	MAP captures data flows and dependencies in context
ISO/IEC 42001	AI management system with documented controls	Requires documented scope and data flows per system
ISO/IEC 42005	AI system impact assessment	Structures the pre-deployment question of disclosure impact
EU AI Act	Obligations by risk class, including human oversight	Drives approval requirements where disclosure is high impact
SOC 2	Confidentiality, monitoring, access control	Expects controls over data leaving the boundary

Further reading: Prompt injection in AI agents for the trigger, Sensitive data and secrets in agent context for the payload side, and Agentic AI security for the wider programme.

How Alyria handles it

Alyria makes the three legs visible per agent and enforces the boundary at the endpoint. Beacon, the signed daemon on every machine, inventories each agent's tools, MCP servers, data sources and network destinations, so the capability table is generated from observation rather than from a design document nobody updated.

Lyra holds the rule that closes the combination. Because policy is information-flow aware, it can refuse a network or mail call that carries data the agent read from a private source in the same session, and it decides locally before the call executes. That rule works without recognising the injected instruction, which is the part model-based defences struggle with.

Umbra keeps credentials out of reach, so the private data leg is not a config file on disk. Spectra streams signed, chained decisions to Alyria Cloud or your own SIEM, so the read and the attempted send appear in one trace.

Start free at alyria.ai with a Beacon on one machine and see your own capability table: app.alyria.ai/signup.

The free Agent Exposure Report covers the read-only version, and the platform overview explains how the modules fit together.