Most agent security incidents are not exotic. They are the same three ingredients in one process:
- Access to private data. Your repository, your database, your credentials, your customers.
- Exposure to untrusted content. A web page, a retrieved document, a dependency's README, an issue comment. Anything an attacker can write.
- A way to communicate outward. An HTTP request, an email, a commit, a webhook. Anywhere data can go.
With all three, an attacker who can influence what the agent reads can, in principle, get it to send your private data somewhere. They do not need an exploit. They only need the agent to be helpful.
Why it is worth naming
The value of the name is that it turns "is this agent safe?" into three checkable questions. Safety stops being a vibe and becomes an audit you can actually perform on a tool configuration.
It also explains why patching the prompt does not help. The trifecta is a property of the agent's capabilities, not of its instructions. Adding "do not exfiltrate secrets" to the system prompt leaves all three legs standing.
Breaking a leg
Removing any one leg collapses the worst case, and the cheapest one to remove is usually the third:
- Cut egress. An agent that reads untrusted pages and holds secrets but cannot make arbitrary outbound requests can be misled into a bad answer, not into theft. See egress control.
- Cut private access. Scope credentials to the task. An agent summarising public documentation does not need production database access. See least privilege.
- Cut untrusted content. Hardest in practice, because retrieval and browsing are usually the point. Treat this as the leg you cannot rely on removing.
Where it hides
The trifecta is rarely configured deliberately. It accretes. A tool is added for one task and stays. An MCP server exposes more than the current job needs. A credential in the environment is inherited by every session. Audit the union of what an agent can reach, not each addition in isolation, because the third leg is usually the one nobody remembers adding.
Related terms
Sandbox
A sandbox is an isolated environment that limits what an agent can touch, such as the filesystem and network, so a mistake stays contained and cannot damage the real system.
Read definition →PatternProvenLeast privilege
Least privilege means giving an agent only the access the current task needs, and no more. It is the one defence that works without knowing how the attack arrives, because it shrinks what any attack can accomplish.
Read definition →PatternValidatedEgress control
Egress control restricts where an agent can send data, rather than what it can read. It is usually the cheapest leg of the lethal trifecta to remove, because most agent work needs very few outbound destinations.
Read definition →AntipatternProvenTool poisoning
Tool poisoning is a tool whose own description or schema instructs the model, rather than merely describing what the tool does. Tool definitions go into the context as trusted text, so whoever writes them is writing your prompt.
Read definition →ConceptBlast radius
Blast radius is how much damage an action can do if it turns out to be wrong. It is the measure that lets you scale review and permissions to consequence instead of treating every change the same.
Read definition →