The lethal trifecta: cut the leg that holds your secrets

Short answer: an AI agent is exposed to data theft when one session combines three things: access to your private data, exposure to content an attacker can write, and a way to send data out. Remove any one and the classic attack stops working. Use the checker to see which legs your setup has, then cut the one that is cheapest to remove. Often that is the first: the agent never needs to hold your secrets.

The name and the framing are Simon Willison’s. In June 2025 he described three capabilities that are dangerous together: access to your private data, exposure to untrusted content, and the ability to communicate externally in a way that could be used to steal your data. If an agent combines all three, he writes, “an attacker can easily trick it into accessing your private data and sending it to that attacker,” because LLMs follow instructions found in content. His conclusion for people mixing tools themselves: “The only way to stay safe there is to avoid that lethal trifecta combination entirely.”

The three legs in practice

Leg What it looks like in an agent session
Private data Reads your working directory, .env files, private repositories, a database, your email
Untrusted content Fetches web pages, reads public issues and pull requests, third-party READMEs, MCP tool output you have not reviewed
External communication Runs shell commands with network access, makes HTTP requests, sends messages, posts comments, pushes code, renders images or links from model output

A real example Willison linked: the GitHub MCP server could read private repositories and public issues, and a malicious public issue tricked an agent into leaking private repository contents (write-up). One server, all three legs.

Check your setup

The trifecta checker runs in your browser. Tick what your agent session can do and it shows which legs you have and gives ideas for removing one. We tested its logic (a shell alone supplies two legs, so adding “reads public issues” completes the trifecta; reading only web pages is one leg). The classification of tools into legs is our reading of Willison’s idea, not a standard: a shell is counted as both private-data access and external communication because it can read your files and use the network. Adjust the result to your actual configuration.

Which leg to cut

You rarely control the content (leg two) and you often need some way to communicate (leg three). The one most teams can shrink is the first:

  • Private data → give the agent names, not values. If the agent never holds your secrets, the worst thing a hijacked session can send out is not your credentials. That is the idea behind Dynv’s MCP server: variable names and masked values by default, writes limited to variables you list, previews with dry_run, and a read-only token kept in a file (setup). Be precise about what that covers: masking applies to what the MCP server returns. If the agent can also run cat .env or read the token file, the leg is back. That is why the secrets have to leave the working directory too (why).
  • External communication → sandbox the network. Restrict outbound connections to the hosts the task needs, disable rendering of images and links from model output, and require approval for sending messages and pushing code. The process firewall and a Landlock wrapper restrict direct connections by port, not by host, so they are friction rather than a host allowlist.
  • Untrusted content → separate sessions. Use one session to read untrusted pages and another, with no private data, to act. Review MCP servers (checklist).

What this model does not tell you

  • Two legs are not safe. An agent with private data and an outbound channel can still be hurt by any content you later add. Mixed tools change over time.
  • Guardrails that “catch 95% of attacks” are not a boundary. Willison is “deeply suspicious” of such products: “in web application security 95% is very much a failing grade.” We agree: prefer removing a leg to detecting attacks.
  • The checker is a thinking aid. It does not inspect your real configuration, and some tools fall between categories (a read-only database with customer data is private data even if it never touches a file).
  • A removed leg can come back when someone adds a tool. Re-run the check when you do.

For the broader threat model and a maturity scale, see AI agent secrets management.

Facts last verified . Spotted an error? Tell us.

New here? Start here for the guides in a sensible order.