The lethal trifecta: how AI agents leak data, and how to break it

01What is the lethal trifecta?

Simon Willison named it in June 2025. The three capabilities are access to your private data, exposure to untrusted content, and the ability to communicate externally in a way that could be used to steal that data. Any one is fine and most pairs are manageable. When an agent has all three, an attacker who can put text in front of it can ask it to read something private and send it somewhere.

The reason is the one behind every prompt injection: LLMs follow instructions in content. A model cannot reliably tell the instructions its user gave from instructions inside a web page, an email, an issue or a tool result it was asked to process. Willison's post lists many products that shipped this class of flaw, including Microsoft 365 Copilot, GitHub's official MCP server, GitLab Duo, ChatGPT, Google AI Studio, Slack and Amazon Q.

Coding agents fit the pattern by default. They read repositories, dependencies and web pages written by strangers; they run with the developer's files and credentials; and they can usually open network connections.

02How AI agents leak data: markdown images, links and tool calls

The way out does not have to look like a network call. In 2023 Johann Rehberger showed markdown image exfiltration against Bing Chat: an injected page told the model to output an image whose URL carried data from the conversation as a query parameter, and the browser fetched that URL to render the image, with no click needed. The fix he observed was a Content Security Policy that only allowed images from a few Bing domains.

EchoLeak, CVE-2025-32711, took the same idea to an enterprise assistant. NVD records it as AI command injection in Microsoft 365 Copilot that allows an unauthorized attacker to disclose information over a network, with a CVSS 3.1 score of 9.3 from Microsoft. The researchers' paper describes a single crafted email that needed no user interaction. The chain evaded Microsoft's prompt-injection classifier, slipped past link redaction with reference-style markdown, used images that are fetched automatically, and routed the request through a Microsoft Teams URL that the Content Security Policy allowed.

For agents with tools the channel is often more direct: an HTTP request, a curl in a shell, a DNS lookup, a comment posted to a public issue, or a pull request. Every one of them is a way out, so all of them belong to the third leg.

03Why filters and classifiers do not close the gap

Detection is worth having, but it is probabilistic. Willison's point is that a guardrail product claiming to catch 95 percent of attacks is a failing grade in security, because an attacker only needs the attempt that gets through and can keep trying. EchoLeak is a clean example: the chain included a bypass of the classifier that was there to stop it.

Meta reached a similar conclusion from the design side. Its Agents Rule of Two, published in October 2025, says that until injection can be reliably detected and refused, an agent should satisfy no more than two of three properties in a session: it can process untrustworthy inputs; it can access sensitive systems or private data; it can change state or communicate externally. If a task needs all three, the agent should not run it autonomously; a human should approve, for example. Meta's third property is wider than Willison's: it covers changing state, not only sending data out.

04How to break the trifecta at the network layer

Of the three legs, the way out is often the one you can remove without breaking the task. Agents need to read untrusted content to be useful, and they usually need some private data. Few need to reach arbitrary hosts. So close the network by default, allow the hosts the task needs by name, and enforce the rule outside the agent's environment, where code running inside cannot rewrite it.

An allow-list narrows the channel; it does not remove it. Data can still be sent in a request body to an allowed host, and broad entries are risky. Anthropic's Claude Code sandbox documentation warns that allowing a broad domain such as github.com can create paths for data exfiltration, and that a proxy deciding by hostname without inspecting TLS may be bypassed with domain fronting. DNS is a channel too, so the sandbox should not be free to query resolvers of its choosing.

Two more measures shrink what can leak. Keep credentials out of the agent's environment by adding them in an egress broker on the trusted side, so a hijacked agent cannot send the key itself, and record every request the broker makes. And where output is rendered, do not let the model's text fetch arbitrary images or links.

• Deny all egress by default; allow named hosts, not whole platforms.
• Enforce the rule on the host, outside the sandbox, including DNS.
• Keep API keys outside the sandbox and add them in a broker on the way out.
• Log every outbound request, allowed or refused.
• Do not auto-load images or links from model output in a rendering client.

05When an agent needs all three legs

Some tasks need private data, untrusted input and a way out at once: triaging a public issue against private code and posting a reply, for example. Then split the work so no single session holds all three, or put a person in the path. Run the reading step in a session with no network, pass a narrow result to a second session that can act, and require approval for the action itself.

Narrow each leg even when you cannot remove it. Let the agent's machine see one project folder, not the home directory. Give it a token scoped to one repository. Make outgoing actions that publish or send wait for a named approver. None of this needs the model to recognise an attack, which is the point.