The instruction is only half of the attack

Prompt injection in AI agents: tools, data and the lethal trifecta

A chat assistant that follows an injected instruction gives you a bad answer. An agent that follows one sends the email, opens the page, runs the command or edits the file. This guide explains why agents are exposed by design, walks through two documented failures, and sets out which of the published defences change the shape of the problem and which only narrow it.

Published 5 September 2026
By the Prompt Injection Scanner editorial team (Mothership Engineering)
Every claim traces to the primary references listed at the foot of the page

What makes an agent different from a chat

An agent is a language model wired to tools: a mailbox, a browser, a file system, a code repository, a payments API. It reads content, decides what to do, calls a tool, reads the result and continues, often for dozens of steps without a person watching each one. Everything the model reads along the way, including the results the tools return, is text, and the model has no reliable way to tell an instruction it was given from an instruction it merely encountered. The UK National Cyber Security Centre put it bluntly in December 2025: inside a language model there is no separation between instructions and data, only the next token.

That is tolerable in a chat, where the worst outcome of a misread instruction is an answer you can ignore. It is not tolerable in an agent, where a misread instruction is an action taken with your credentials. The question to ask of any agent is not whether it might read hostile text, because if it reads the web or your inbox it certainly will, but what it can do once it has.

The lethal trifecta

Simon Willison’s June 2025 description of the “lethal trifecta” gives the question a usable shape. An agent becomes a data-theft risk when it combines three capabilities: access to private data, which is the reason most tools exist; exposure to untrusted content, meaning any way for text an attacker controls to reach the model; and the ability to communicate externally, whether by sending a message, making a web request or rendering a link. With all three present, an injected instruction can read the data and carry it out. Remove any one and the attack loses its exit.

Willison’s list of systems that have fallen to exactly this combination runs from ChatGPT and Google Bard in 2023 through Amazon Q and Slack AI in 2024 to GitHub’s MCP server and Microsoft 365 Copilot in 2025. His conclusion is uncomfortable for anyone hoping for a filter: guardrails that catch most attacks are not a security boundary, vendors cannot protect the tool combinations that users assemble themselves, and the only reliable protection for someone mixing tools is to avoid assembling the trifecta at all.

Two documented failures

On 26 May 2025 Invariant Labs described an attack on agents using GitHub’s official MCP server. An attacker files an issue in a public repository containing instructions. A developer later asks their agent to look through the repository’s open issues. The agent reads the malicious issue, follows it, pulls data from the developer’s private repositories into the conversation and publishes it. Invariant called the pattern a “toxic agent flow” and was careful about where the fault lay: not in the MCP server’s code, but in an architecture that lets one tool’s untrusted output drive another tool’s privileged action. Their recommended mitigations were granular, least-privilege permissions on what the agent can reach and continuous monitoring of the tool calls it makes.

On 20 August 2025 Brave published its analysis of the Comet AI browser. Hidden text in a web page, white on white or inside a collapsed comment, was read by the browser’s agent as part of a summarisation request. Following it, the agent opened the user’s account page to find their email address, navigated to a look-alike domain, triggered a one-time login code, read that code out of the user’s Gmail and posted both to a public forum. Brave’s four recommendations map directly onto the trifecta: treat page content as untrusted, check the model’s proposed actions against what the user actually asked, require explicit confirmation for security-sensitive tasks, and make agentic browsing a mode the user cannot enter by accident.

Defences that change the shape of the problem

The most durable defences do not try to detect hostile text; they change what the system can do while reading it. The NCSC’s formulation is the simplest: when a model processes content from a party, its privileges should drop to those of that party, so an agent reading email from strangers should hold no privileged tools while it does so. Willison’s 2023 Dual LLM pattern is a way to build that: a privileged model with tool access never sees untrusted text, a quarantined model reads it and can do nothing else, and ordinary software passes opaque tokens between them. Google DeepMind’s CaMeL, published in March 2025, goes further, extracting the control and data flow of a task from the user’s trusted request and attaching capabilities to data so that a tool call which would move private data to an untrusted destination is refused by policy. On the AgentDojo benchmark it completed 77 per cent of tasks with provable security against 84 per cent for an undefended agent.

Vendors have shipped layered versions of the same ideas. Google’s June 2025 account of Gemini’s defences lists content classifiers, “security thought reinforcement” that reminds the model of its actual task, markdown sanitisation and redaction of suspicious URLs, a user-confirmation framework for consequential actions and notifications when a defence fires. OpenAI’s December 2025 note on the Atlas browser describes an automated attacker trained by reinforcement learning to find long, multi-step injections, and gives users advice that echoes the trifecta: require confirmation before sending messages or making payments, and do not give an agent broad access to an inbox without a specific reason.

What to do if you run an agent

For each set of tools an agent can use, write down which of the three legs it holds. If it holds all three, remove one: scope its credentials so it cannot reach data the task does not need, cut its ability to browse or read untrusted sources during that task, or take away its outbound channels and route anything it wants to send through a person. Put a confirmation step in front of every external action and every write, and log tool calls so that when something goes wrong you can see what the agent read and what it did next.

A scanner such as the one on this site belongs at the input, as a review aid for a person deciding whether a document, page or ticket should be handed to an agent at all. It reads the text the way a model would, reports instruction-shaped passages and hidden channels with their locations, and stops there. It cannot know what your agent can reach, and a clean result does not license you to assemble the trifecta. The controls above are the boundary; detection is what helps you keep hostile content on the right side of it.

Primary references

These sources describe the external risks or standards discussed above. The property’s detector claims remain limited to its versioned policy and recorded evidence.

Browse every guide

Result boundary: Findings are indicators for review. Detection cannot certify a source, and a no-indicator result does not replace downstream isolation, validation, least privilege or approval.