The Lethal Trifecta: Why Your Most Useful Agents Are Your Most Exploitable

Picture the most useful agent your team shipped this quarter. It reads customer tickets, checks the account database, and posts status updates to a webhook. Each capability is why you built it. Together, they form a complete exfiltration path an attacker can trigger with a single document.

Where the term comes from

Security researcher Simon Willison, who coined the term "prompt injection," named this pattern the "lethal trifecta" in June 2025. His definition is simple. An agent becomes exploitable when three capabilities meet in one workflow:

• It reads all types of content.  An email, a web page, a support ticket, an uploaded PDF. Anything that originated outside your org.
• It can reach sensitive data. A customer database, a knowledge base, a code repository, a finance folder.
• It can send data out. A webhook, an outbound email, an API call, even a URL it is allowed to fetch.

All three-in-one agents mean an attacker does not need to breach your network. They just need to get one document to your agent.

How the attack runs

An attacker can embed instructions in content your agent is designed to process. This could be white text in a PDF, a comment in a shared document, or a line in a web page. Language models often cannot distinguish between content and instructions, so the agent may treat hidden text as a command. For example, it might receive an instruction to query the customer table and send the results to a specific URL. If the agent has both database and webhook tools, it will execute the task. There is no malware and no stolen credentials, so nothing in your endpoint stack catches it.

Real deployments have already been hit this exact way. In September 2025 a researcher hid white-text instructions in a PDF, uploaded it to Notion's AI agent, and watched the agent pull a client list and push it out through its own web search tool. The user never clicked anything. Earlier that year, Microsoft patched CVE-2025-32711, a zero-click injection flaw in Microsoft 365 Copilot that could leak internal data. If this happens inside products built by world-class security teams, it can happen in the agent your sales ops team wired up last month.

The audit you can run today

You do not need to buy anything to check for this. Open a spreadsheet. For every agent in your environment, list every tool it can call. Next to each tool, mark which leg it touches: reads untrusted content, reaches sensitive data, or sends data out. Any agent with marks in all three columns is currently carrying the trifecta.

Then break one leg. Remove the tool the agent needs least, pin its outbound channel to fixed internal destinations, or cut its data access down to what the workflow actually requires. The attack needs all three legs. Breaking any one of them collapses the path.

Tool names lie, so judge the behavior

The hard part of that audit is knowing what a tool really does. A connector called search_docs might read the open web. A helper called notify might post to any URL on the internet. Before you trust a tool's name, ask five questions about its behavior:

1. What is the most dangerous thing it can do? A routine data read, or credential access and code execution?
2. Does it read, write, or execute on systems beyond the agent?
3. How far can its outbound actions reach? One fixed system, or any address on the internet?
4. Where does its inbound content come from? Trusted internal records, or the open web?
5. Are its effects reversible? A read is harmless. A deletion is not.

Score each tool this way and you get the name of the specific tool that turns an ordinary agent into an exfiltration bridge. That is a thing you can fix.

Two legs are already a problem

A quieter version of this risk needs no attacker at all. An agent that combines sensitive data access with an outbound channel can leak data on its own, simply by trying too hard to satisfy a prompt. Ask an over-permissioned agent to share the numbers with the team and it may post real customer records to an external destination because nothing stopped it. We call this two-leg state the Lethal Bifecta. It is the precursor worth catching before a new connector adds the third leg.

What we automated

The spreadsheet audit works. It also goes stale as soon as someone adds a new MCP server or data source. That gap is what the Lethal Trifecta policy in Cyera Agent Guardian closes.

Agent Guardian discovers the agents, tools, and non-human identities operating across your workspace, classifies the sensitivity of every data source each agent can access, and scores every tool across the behavior dimensions above. The model was built by classifying thousands of tools from live agent deployments, and when a tool's definition is too thin to judge, it says so rather than guessing. The policy flags full trifecta states, catches Bifecta precursors, and re-audits automatically whenever an agent gains a new tool, MCP connection, or data source. The output is specific: this agent, this tool, this data, together forming this path.

Data sensitivity decides which findings deserve your time. An agent wired to public documentation with all three legs is a low-grade finding. The same three legs wired to financial records are the first thing you fix on Monday.

Three questions before your next review

For every agent you run, ask: what does it read that a stranger could have written, what sensitive data can it touch, and where can it send what it finds? If one agent has an answer to all three, you have work to do this week, with or without our product.

Agents are only getting more capable, and every new tool connection redraws this map. The teams that stay safe will be the ones who treat agent permissions as an attack surface and audit them as often as they change.

See if your environment is at risk of the Lethal Trifecta