The Lethal Trifecta in AI Agents: How Private Data Gets Exposed—and How to Break the Chain

AI agents become useful when they can do more than generate text. They can search internal documents, read email, query databases, browse websites, call APIs and send messages. But combining these capabilities can create a security problem that is easy to miss in a tool-by-tool review.

Security researcher Simon Willison calls this combination the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. Each capability can be legitimate on its own. When all three exist in one agent workflow, however, attacker-controlled content may manipulate the agent into retrieving sensitive information and sending it somewhere it should not go. Willison introduced the framing in June 2025.

What are the three parts of the lethal trifecta?

1. Access to private data

The agent can read information that should not be disclosed to an arbitrary outside party. This may include customer records, internal documents, private source code, email threads, support tickets, financial records or confidential business plans. Access can come from a search index, an API, a connected account, a database tool or information already placed in the model’s context.

The key question is not simply whether the agent can see sensitive data. It is whether that access is limited to the specific user, task and moment that require it. Broad service credentials and unrestricted search tools can turn one manipulated request into a much larger exposure.

2. Exposure to untrusted content

An agent often needs to process content it does not control: a webpage, an incoming email, a PDF, a repository issue, a calendar invitation or a document supplied by a customer. That content may contain instructions aimed at the model, such as a request to ignore earlier directions, search for confidential records and include them in a response.

This is a form of indirect prompt injection. The malicious instruction arrives inside content the agent was asked to read, rather than as a direct instruction from its user. The content may look like ordinary prose, hidden webpage text, a document comment or a message embedded in a tool result.

Prompt injection is difficult because language models are designed to interpret language and follow instructions, while attacker-controlled text can be mixed into the same context as legitimate task information. Telling a model to “ignore malicious instructions” can help, but it is not a reliable security boundary by itself.

3. A way to communicate externally

The agent can send information out through email, a messaging tool, an HTTP request, a webhook, a file upload, a public issue or pull request, or another connected service. External communication does not have to look like a conventional email. Even a tool that fetches a URL or publishes generated content may provide an outward channel, depending on how it is implemented.

If an agent can retrieve secrets and then place them in an outbound message or request, an attacker may be able to use that channel to exfiltrate data. The exact risk depends on the tools, permissions, data boundaries and approval steps in the system.

How the attack chain can work

Consider an AI assistant that summarizes incoming support emails. It can read internal customer records and send replies. A malicious sender includes instructions in an email telling the assistant to find a different customer’s account details and include them in a reply to an attacker-controlled address.

1. Entry: the assistant reads an email containing attacker-controlled instructions.
2. Manipulation: the model treats some of that text as a task instruction instead of merely untrusted content.
3. Access: the agent uses its connected tools to retrieve information it is technically permitted to read.
4. Exit: a send-message or network tool provides a route to transmit the information outside the intended boundary.

This is an illustrative scenario, not a claim that every agent will follow injected instructions. The important point is architectural: if the model makes a bad decision, the surrounding system should still prevent unauthorized data access or disclosure.

Why ordinary prompt guardrails are not enough

Prompt instructions, content classifiers and model-level safeguards can reduce risk, but they should not be the only controls standing between an attacker and private data. Injection attempts can be phrased in many ways, and the agent may encounter instructions in sources developers did not anticipate. A system that relies on the model to recognize every malicious instruction is asking the same component being manipulated to enforce the security boundary.

OWASP’s guidance on excessive agency highlights the danger of giving AI systems too much functionality, permission or autonomy. The lesson is to constrain what the agent can do independently, not merely to ask it to behave responsibly.

Break the trifecta with architecture

The most direct design strategy is to ensure that a single agent context does not simultaneously have all three capabilities. In practice, that means choosing which capability to remove or tightly isolate for each workflow.

Option A: Reduce access to private data

• Use per-user authorization and enforce access checks in the tool or data service, not just in the prompt.
• Retrieve only the records needed for the current task; avoid loading broad collections of confidential data into context.
• Use short-lived credentials and narrow scopes. Prefer read-only access when the task only requires reading.
• Redact secrets and sensitive fields before data reaches the model when those fields are unnecessary.

Option B: Isolate untrusted content

• Treat webpages, emails, documents, repository comments and tool results as data, never as authoritative instructions.
• Separate trusted task instructions from retrieved content in the orchestration design, while recognizing that formatting alone is not a hard security boundary.
• For high-risk tasks, use a constrained processing stage to summarize or extract facts from untrusted content, then pass only the minimum validated result to an agent with privileges.
• Test with indirect prompt-injection cases in text, HTML, images and documents relevant to the actual workflow.

Option C: Restrict external communication

• Use destination allowlists and egress controls for network-enabled agents.
• Separate drafting from sending. Require human approval before sensitive messages, uploads, public posts or high-impact actions.
• Validate outbound payloads against data-loss prevention rules and block secrets or unauthorized records from leaving the system.
• Use narrowly scoped tools: an agent that drafts replies may not need a tool that can send them directly.

No single measure is sufficient for every workflow. A robust design combines least privilege, tool-level authorization, constrained network access, explicit approval for sensitive actions, and logs that allow investigators to reconstruct what happened.

A practical review checklist for agent builders

For every agent and tool integration, ask:

1. What sensitive data can this agent access, directly or through other tools?
2. Which inputs can be influenced by outsiders, including emails, webpages, documents and tool outputs?
3. What channels can send data outside the trust boundary?
4. Can authorization be enforced outside the model, at the point of data access and action?
5. Which actions require explicit human approval?
6. Are outbound destinations, payloads, tool calls and access decisions logged and monitored?
7. Have we tested realistic prompt-injection scenarios and verified that controls block the resulting action?

If the first three answers are all “yes,” the system deserves a focused threat-model review. It does not automatically mean a breach is inevitable, but it identifies a combination where one model error or successful injection may have an unusually large impact.

How this connects to agent identity and incident response

The lethal trifecta is a useful complement to identity and incident-response design. Every agent should have a distinct identity, limited permissions and an auditable set of actions. If an agent behaves unexpectedly, teams should be able to revoke its credentials, disable specific tools, stop outbound traffic and investigate the relevant logs. Our guides on AI agent identity and permissions and AI agent incident response cover these related controls.

The takeaway: do not make the model your last line of defense

The lethal trifecta is powerful because it turns a vague AI safety concern into a concrete architecture question. What private data can the agent reach? What untrusted content can influence it? How can it communicate outward?

AI agents need tools to be useful, but they do not need unrestricted access to every tool at once. Remove unnecessary capabilities, enforce permissions outside the model, constrain outbound channels and require approval for sensitive actions. The goal is not to eliminate every prompt injection attempt. It is to design the system so that an attempted manipulation cannot become a data breach.

Sources and further reading

• Simon Willison: The lethal trifecta for AI agents.
• OWASP GenAI Security Project: Excessive Agency.
• OWASP AI Security and Privacy Guide: AI security overview.