Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

What Is the Lethal Trifecta for AI Agents?

It is the combination of three capabilities in one agent, access to private data, exposure to untrusted content and the ability to communicate externally, which together let a planted instruction become a data theft. Check which of the three each agent holds, and remove the one whose absence costs the task least, which is usually the private data.

Private files, outside content, and stored data converge at one agent node connected to a globe.

It is the combination of three capabilities in one agent, access to private data, exposure to untrusted content and the ability to communicate externally, which together let a planted instruction become a data theft. Check which of the three each agent holds, and remove the one whose absence costs the task least, which is usually the private data. The term was coined in June 2025 to name a pattern security researchers had been describing for two years: an agent that reads content an attacker can influence, holds data the attacker wants, and can send messages or make requests outward, is an exfiltration path waiting for the right paragraph of text. Each leg is ordinary: agents read web pages and emails, work in systems full of customer data, and send messages and submit forms. The danger is the conjunction. This page defines the three legs and explains why the combination is lethal, shows how indirect prompt injection supplies the untrusted-content leg, weighs which leg to remove and what each removal costs, works through a single support ticket record, sets out how to measure whether the trifecta is present in a deployment, and lists the claims a buyer should refuse. Its argument, consistent with the earlier treatment of how to secure AI agents, is that the private data leg is the one whose removal leaves the agent most useful.

Key findings

  • The lethal trifecta, as its originator defined it, is access to your private data, exposure to untrusted content, and the ability to externally communicate; an agent with all three can be made to steal the data by content it reads (Simon Willison, 2025).
  • Meta's security guidance converts the diagnosis into a rule: until prompt injection is reliably stopped, agents must satisfy no more than two of three properties within a session, processing untrusted input, accessing sensitive systems or data, and changing state or communicating externally (Meta AI, 2025).
  • Indirect prompt injection, in which instructions arrive inside content the model retrieves, was demonstrated against real applications in 2023 and has since been observed in the wild on pages agents browse (Greshake et al., 2023; Palo Alto Networks Unit 42, 2026).
  • Prompt injection holds the first position in the security community's top ten risks for language model applications, and the entry treats it as a problem to be contained by design rather than solved by detection (OWASP, 2025).
  • Research on detection-based defenses asks whether firewalls are enough or stronger benchmarks are needed, a framing that signals filtering is not yet a reliable way to remove the untrusted-content leg (Bhagwatkar et al., 2026).
  • Removing the private data leg by substituting tokens for real values before the model reads a screen leaves the agent able to browse and act, which the other two removals do not (What Is Sensitive Data Masking for AI Agents?).

What are the three legs, and why is the combination lethal?

The originator's definition has three parts: access to your private data, exposure to untrusted content, and the ability to externally communicate (Simon Willison, 2025). Private data is anything the organization would not want sent to a stranger: customer records, credentials, internal documents. Untrusted content is anything an attacker could have written or edited: a web page, an inbound email, a document from outside, a free-text field a customer filled in. External communication is any channel out: sending an email, making a web request, posting to a chat, submitting a form to a third-party site.

The combination is lethal because language models do not reliably distinguish instructions from data. A model reading a web page that says, in effect, take the account numbers you have seen and include them in a request to this address, may do so. If the model has seen account numbers, the first leg is present. If it read the page, the second is. If it can make the request, the third is. The attacker needed only to place the paragraph where the agent would read it.

Each leg alone is harmless. An agent with private data and untrusted content but no outbound channel can be confused but cannot leak. An agent with untrusted content and an outbound channel but no private data can be made to send things, but has nothing worth sending. An agent with private data and an outbound channel but no untrusted content follows only its principal's instructions. Meta's guidance states the operating rule that follows, no more than two of the three within a session until prompt injection is reliably stopped (Meta AI, 2025). The practical question for any deployment is which of the three to remove, and the analysis of AI agent data security frames the data leg as the one an organization controls most directly.

How does indirect prompt injection supply the untrusted-content leg?

Direct prompt injection is a user typing an instruction the system should refuse. Indirect prompt injection is more dangerous for agents: the instruction arrives inside content the model retrieves in the course of its work, and the user never sees it. The 2023 research that named the problem demonstrated it against real language-model-integrated applications (Greshake et al., 2023). The security community's top ten lists prompt injection first and treats containment by design, limiting what the model can do after reading untrusted content, as the response (OWASP, 2025).

What was a demonstration is now an observation. Unit 42 has reported web-based indirect prompt injection against agents in the wild, with instructions embedded in pages browsing agents visit (Palo Alto Networks Unit 42, 2026). The untrusted-content leg is no longer hypothetical for any agent that browses or reads inbound messages, and most useful agents do one or the other.

The defensive research is candid about detection. A 2026 study asks whether firewalls, filters placed in front of the model to catch injected instructions, are all that is needed, or whether the benchmarks used to evaluate them are too weak to tell (Bhagwatkar et al., 2026). A control whose evaluation is in question is not a control to rely on for removing a leg. Design-level work takes the other path: CaMeL's goal is that untrusted data retrieved by the model can never impact program flow (Debenedetti et al., 2025), and a family of design patterns aims at provable resistance by constraining what the agent can do after exposure (Beurer-Kellner et al., 2025). Both treat the untrusted-content leg as permanent and work around it, the posture this page adopts.

Which leg should be removed, and what does each removal cost?

Leg removed How What the agent loses What a buyer should verify
Untrusted content The agent reads only trusted internal sources Research, triage, intake, anything involving outsiders That the restriction is enforced by reach, not instruction
External communication The agent cannot send, post, request or submit Completing tasks; each action becomes a handoff That no allowed destination doubles as an outbound channel
Private data Identifiers and regulated values become tokens before the model reads the screen Little, for tasks that compare, route, draft or summarize That tokens are consistent and resolve only at approved destinations

Removing untrusted content is the cleanest in theory and the most expensive in practice. An agent that cannot read a web page, an inbound email or a customer's own words cannot do most of the work agents are deployed for, and the restriction must be enforced by reach, since untrusted content can counter an instruction to ignore it.

Removing external communication is safe and slow. An agent that can only read and propose is harmless to data, and every outbound step is a handoff. For consequential actions that is the right design; applied to every action, it turns the agent into a drafting tool. An allowed destination can also be an outbound channel if the attacker controls a field in it, so the removal is rarely complete.

Removing private data costs the least. If identifiers and regulated values become consistent tokens before the model reads the screen, the model can still read the page and the message, compare records and propose actions; it holds nothing worth stealing. The planted paragraph that says to send the account numbers finds ACCT_001 and ACCT_002, which resolve only at an approved destination during an approved action. The analysis of agent data exposure treats this removal as a measurement problem; here it is the strategic choice.

What does a single support ticket record show?

Take one record type, an inbound support ticket in a service desk, and one task: an agent reads new tickets, looks up the customer's account to check entitlement, drafts a reply and routes the ticket to the right queue. The ticket body is written by the customer, or by anyone who can send an email to the support address. The account page renders the customer's name, account number, contact details, plan, payment method on file and recent invoices. The reply goes out by email.

Count the legs. Untrusted content: the ticket body, which anyone could have written. Private data: the entire account page. External communication: the reply email and the routing action. All three are present; this ordinary workflow is a textbook instance of the trifecta. A ticket whose body contains an instruction to include the account's payment details in the reply and copy an outside address has every leg it needs, and the model that reads it has been shown, by the organization, exactly the data the instruction asks for.

Remove the private data leg. Before the model reads the account page, the name, account number, contact details and payment method are replaced with consistent tokens; the plan and the invoice status, which the entitlement check needs, remain readable. The model reads the ticket, confirms that CUST_001 is on a plan that includes the requested support, drafts a reply addressed to the contact token and proposes a queue. If the ticket body carried the planted instruction, the model has no payment details to include and no real address to copy. The reply is confirmed by the support lead before it sends, and at that moment the contact token resolves to the customer's real email at the mail system. The agent read untrusted content and communicated externally, two legs, and the session was never lethal. The broader program for securing agents in an enterprise applies this pattern workflow by workflow.

How should an organization measure whether the trifecta is present?

For each agent and task, write down the three legs and mark each present or absent, with evidence. Untrusted content is present if the agent reads anything a person outside the trusted team could have written, including fields inside internal systems that customers, vendors or applicants populate. Private data is present if any value the organization would be obliged to report as breached reaches the model in the clear. External communication is present if the agent can send, post, request or submit without a person confirming, and also if any allowed destination has a field an outsider can read.

Then verify each claimed absence by test, not by design review. For a claimed absence of untrusted content, try to get content from outside into the agent's reading path. For a claimed absence of external communication, look for any allowed destination that leaks outward. For a claimed absence of private data, sample the screens as the model saw them and confirm that identifiers and regulated values appear as tokens, consistently across the run, and that no token resolved anywhere but an approved destination during an approved action.

Finally, test with planted content. Place a benign instruction in a ticket, a web page or a document the agent will read and observe what the agent does. Meta's rule gives the pass condition: a session holding two legs should show no path from the planted text to harm (Meta AI, 2025). A session that fails the test holds a leg the inventory missed. The originator's framing is useful here too: the trifecta is a property of the agent's capabilities, not of the attacker's skill, so the test is of the deployment and not of the model (Simon Willison, 2025).

What does a governed environment change?

A governed environment removes the private data leg from the model's view while leaving the agent able to browse and act, which is the one removal that costs the task least. The trifecta, as defined, is access to private data, exposure to untrusted content and the ability to communicate externally (Simon Willison, 2025). An agent running directly in the application or the user's browser holds all three the moment it opens a record. In the environment, the first is absent from context, so a planted instruction that lands has nothing real to send.

This class of control works at the rendered screen. Sensitive values on the page are replaced with consistent tokens before any model reads them, and the task runs on tokens. Real values resolve only at an approved destination at the moment of an approved action. A named person confirms what is tokenized and approves consequential actions such as payments, submissions and record changes. Every screen as tokens, every action and every approval is recorded and exported to the organization's own logging.

Set this against the two claims the previous section said to refuse. Instruction filters have an unmeasured miss rate, and whether firewalls are enough remains an open research question (Bhagwatkar et al., 2026), so they do not remove the untrusted-content leg. Model resistance training does not remove any leg. The environment's export supplies the evidence the inventory asked for: the screen as the model saw it, with tokens where the identifiers were, and the record of where each token resolved.

The control does not alter the application, the user's permissions or the model, and it does not lower the rate at which injections arrive; it changes what they find in context.

Where does RedactSure sit?

The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company. Its design removes the private data leg, the removal this page identifies as the one that leaves the agent useful. The agent works in a governed environment in the customer's cloud. Substitution happens at the render layer before any model reads the screen, so identifiers and regulated values reach the model as consistent tokens, such as ACCT_001 or PATIENT_001, for the whole run; the model can read untrusted content and take actions without holding anything a planted instruction could exfiltrate. Real values resolve only at approved destinations at the moment of an approved action. A named person confirms the tokenization policy and approves every payment, submission and record change, which RedactSure calls Supervised Delegation, so the external communication leg is gated for consequential actions as well. Every screen as tokens, every action and every approval lands in the AI Control Record and exports to the customer's SIEM. The design is model agnostic, requires no per-application integration, and leaves user permissions unchanged.

Deployments are in pilot. A pilot on the reader's own workflow would show, for each session, which legs the agent held, the screens as the model saw them, and the result of a planted-content test, which is the measurement this page describes. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on an expert blog that originated the term, vendor research, preprint research, an industry standard and industry threat analysis. The originating source is Simon Willison's June 2025 post defining the lethal trifecta. Vendor research is Meta AI's Agents Rule of Two post (October 2025). Preprints are Greshake and colleagues on indirect prompt injection (2023), the CaMeL paper from Google, Google DeepMind and ETH Zurich (June 2025), the design patterns paper by Beurer-Kellner and colleagues (June 2025), and Bhagwatkar and colleagues on firewalls and benchmarks for indirect prompt injection (v2, March 2026). The standard is the OWASP Top 10 for LLM Applications entry on prompt injection (2025). Threat analysis is Palo Alto Networks Unit 42's report on web-based indirect prompt injection observed in the wild (March 2026). All sources were read as of October 16, 2026.

No hands-on testing of any product, agent or research prototype was performed for this page. The research patterns and defensive studies are described as their authors describe them and have not been evaluated here. Where a source does not describe a capability, that capability is described as not described in the pages reviewed, not as absent. Vendor features change, and the page carries its date. Statements about RedactSure describe its current design, with deployments in pilot. The support ticket example describes a record type, not any organization; no customer or prospect is described.

Whether a given agent deployment's design adequately addresses prompt injection and data exfiltration risk under the obligations that apply to an organization is a determination for its counsel, its assessors and its own security and compliance officers, not for a research page.

What the record shows

The lethal trifecta names a conjunction, not a vulnerability: an agent that holds private data, reads untrusted content and can communicate outward is an exfiltration path, and the paragraph of text that triggers it has now been observed in the wild. The research community's response has been to accept that untrusted content cannot be reliably filtered and to design around it, and the operating rule that follows is no more than two legs per session. Of the three removals, removing untrusted content disables most useful work, removing external communication turns the agent into a drafting tool, and removing private data, by substituting tokens before the model reads the screen, leaves the agent able to read and act while holding nothing worth stealing. The test is to name one agent and one task, mark the three legs, place a benign instruction where the agent will read it, and see whether anything reaches the outside.

Frequently asked questions

Who coined the term lethal trifecta?

Simon Willison, in a June 2025 post that named the three capabilities, access to private data, exposure to untrusted content and the ability to externally communicate, and explained why an agent holding all three can be made to leak data by content it reads. The pattern itself had been described in the indirect prompt injection research since 2023; the post gave it a name that practitioners and vendors have since adopted, and Meta's Rule of Two built on it directly.

Is the lethal trifecta the same as the Rule of Two?

They are two statements of one idea. The trifecta is the diagnosis: three capabilities whose conjunction is dangerous. Meta's Rule of Two is the prescription: no more than two of three properties in a session until prompt injection is reliably stopped. Meta's three properties map closely onto Willison's three legs, with state change grouped alongside external communication. This page uses the trifecta to name the legs and the rule to decide what to remove.

Can a good system prompt break the trifecta?

No. A system prompt is an instruction, and the trifecta is dangerous precisely because instructions arriving in untrusted content compete with it. A model told to ignore instructions in web pages is still reading web pages that tell it otherwise, and the security guidance treats this as a design problem rather than a prompting problem. Breaking the trifecta means removing a capability by construction, not asking the model to decline to use one it still holds.

Why is private data the leg to remove?

Because its removal costs the task least. An agent that cannot read untrusted content cannot do research, triage or intake. An agent that cannot communicate cannot finish anything. An agent whose view of records has identifiers replaced with consistent tokens can still read, compare, draft and act, and the real values are used only at approved destinations during approved actions. The agent keeps the two legs that make it useful and loses only what an attacker would want.

Do injection filters count as removing the untrusted-content leg?

Not reliably. Filters placed in front of the model catch some injected instructions and miss others, and current research questions whether the benchmarks used to evaluate them are strong enough to say how many. A filter is a useful additional layer, and it is not a removal, because the content it misses still reaches the model with its full capabilities intact. A leg counts as removed only when the capability is absent by construction.

Does the trifecta apply to agents that only work inside internal systems?

Usually yes, because internal systems contain fields outsiders write. A support ticket, a job application, a vendor invoice, a customer note and an inbound email are all untrusted content sitting inside trusted applications. An agent that reads them has the second leg even if it never opens a browser. The inventory should treat any field an outsider can populate as untrusted, wherever the field lives.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.