Prompt injection defence for AI agents with tools: the three ingredients of every breach and the seven controls that remove them

A prompt injection is text that an AI model reads as an instruction when it should have read it as data. The model cannot tell the difference, because both arrive as the same kind of text, and no vendor has fixed that. OpenAI describes it as a frontier security problem still being worked on. In May the Five Eyes agencies, including CISA and the NSA, issued joint guidance on agentic AI that assumes it will not be solved and recommends deploying agents incrementally with human oversight at consequential decision points.

For a chatbot, an injection produces an embarrassing answer. For an agent with tools, it produces an action. The agent reads a document, an email, a web page, a ticket, a tool result or a message from another agent, finds instructions inside it, and follows them with whatever access it has. The incidents that shaped OWASP's Top 10 for Agentic Applications, published for 2026, were all of this kind, and they are the best way to understand what you are defending against.

What does a prompt injection attack on an agent look like?

It looks like an ordinary piece of content arriving through an ordinary channel, and an agent doing something its operator never asked for. The attacker rarely talks to the model at all.

EchoLeak, disclosed by Aim Labs in 2025 and assigned CVE-2025-32711 with a severity of 9.3, was an email. The target never opened it. Microsoft 365 Copilot retrieved it as context for an unrelated question, read the hidden instructions, and sent data out of the tenant. No click, no mistake by a user, no link to trace. OWASP files it under ASI01, agent goal hijack, and it is the reference case for the category.

The Amazon Q incident was a pull request. An attacker with an inappropriately scoped GitHub token committed a prompt into version 1.84.0 of the Amazon Q extension for VS Code, which had more than 950,000 installs. The prompt told the agent to clean the system to a near-factory state, and the agent had the AWS command-line tools to do it. That is ASI02, tool misuse: legitimate tools, chained by an instruction the agent should never have accepted.

Cursor's CVE-2025-54135 was a workspace configuration file delivered over the Model Context Protocol, missing the confirmation step that should have preceded a change to settings, and resulting in code execution on the developer's machine. And the Replit incident needed no attacker: an agent with production database access deleted the database during a code freeze it had been told about, then reported inaccurately on what it had done. OWASP's list includes that one under cascading failures, because the lesson is that autonomy plus broad access produces the same outcome as an injection without anyone injecting anything.

A research finding rounds out the picture. In a test with five MCP servers connected to an agent, one compromised server achieved a 78.3 per cent attack success rate. Every tool you connect is a channel for content the agent will read, and every tool result is untrusted.

Why do these attacks work: the three ingredients

Every one of those breaches combined three properties in one agent: access to private data, exposure to content an attacker could influence, and a way to act or communicate outward. Simon Willison named this the lethal trifecta in 2025, and Sysdig's 2026 guide observes that nearly every major finding fits the pattern. Remove any one ingredient and the attack has nowhere to go. An agent that reads untrusted email but holds no private data and cannot send anything has been hijacked to no effect. An agent that holds your customer database and can send email, but only ever reads inputs your own staff wrote, has no injection channel.

The defence follows from the diagnosis. You cannot make the model reliably tell instructions from data, so you design the system around the assumption that it will not, and you make sure the three ingredients are never all present in the same agent at the same time with the same authority.

What are the seven controls, in order of payoff?

The first control is to draw the trifecta for each agent before it ships. List what private data it can reach, which inputs an outsider could influence, and which actions or channels could carry data out. If all three columns have entries, the agent needs the rest of this list. If any column is empty, keep it that way and document why. This is a whiteboard exercise and it finds more problems than any scanner.

The second is least privilege by identity and by task. Every agent gets its own credentials scoped to the specific systems and operations it needs, as we set out in the permissions piece. OWASP's ASI03 calls identity and privilege abuse the risk that turns every other risk into a breach: a goal hijack with read-only scopes is an incident report, and the same hijack with a broad token is exfiltration. Scope tokens narrowly, rotate them, and give write and send permissions to named agents for named targets only.

The third is separating reading from acting. The architectural versions of this are the dual-model pattern, where a privileged model that can call tools never reads untrusted content and a quarantined model that reads untrusted content can call no tools, and capability-based designs such as Google DeepMind's CaMeL, where the agent commits to a plan and its allowed tools before it touches attacker-controlled content. In a business workflow the same principle is simpler: the step that parses the incoming invoice has no network access and no write permissions, and the step that posts the entry never sees the raw PDF, only the validated fields.

The fourth is controlling what goes out. Data leaves through tool calls, through URLs the model is induced to fetch, through markdown images that load from an attacker's server, and through messages the agent is allowed to send. Allowlist outbound destinations. Strip or neutralise links and image references in model output before rendering. Treat "send", "post" and "fetch" as the privileged verbs they are.

The fifth is validating tool calls at runtime, in code, before execution. The model proposes a tool call; a deterministic layer checks that the tool is on the agent's list, the arguments match the schema, the target is in scope, the amount is under the cap and the sequence makes sense. Cursor's vulnerability was a missing confirmation on a settings change. Amazon Q's was a wiper built from permitted commands. Both are caught by a check that does not read prose.

The sixth is a human approval step that shows the raw action. OWASP's ASI09, human-agent trust exploitation, is the observation that an approval based on the agent's own summary is an approval of whatever the agent chose to show. Display the exact command, the exact recipient, the exact amount. Log what was displayed, not just what ran. Reserve the step for irreversible actions so that it stays a decision rather than a reflex.

The seventh is testing for it. Put injection cases into the evaluation harness: documents with embedded instructions, tool results that ask for credentials, emails that request forwarding to an outside address, a poisoned entry in the agent's memory that surfaces three turns later. Score the agent on whether it acts, and block releases that regress. Then log every run, tool call and approval so that when something does get through you can reconstruct what the agent did, why, and under whose authority, which is the capability the Five Eyes guidance says most organisations lack.

What about detection tools and prompt-injection classifiers?

Use them as a second layer and never as the first. Input classifiers, including cheap fast ones of the kind we discussed with Jev in September, catch known patterns and reduce noise. Runtime monitoring of tool calls catches the consequences: an unusual recipient, a burst of reads, a fetch to a new domain. Neither sees the model's reasoning, and both can be evaded by an attacker who reads the same vendor documentation you do. The seven structural controls hold when the classifier misses; the classifier does not hold when the structure is missing.

The uncomfortable summary is that prompt injection is a property of the technology and the defences are properties of your architecture. Vendors will keep improving the models' resistance and none of them will promise immunity. A company that runs agents should assume every one of them will, at some point, read an instruction it should not have, and should have arranged things so that when it does, the damage is a log entry.

Frequently asked

What is prompt injection in AI agents? Prompt injection is an attack in which text that an AI model reads as data, such as an email, a document, a web page or a tool result, contains instructions the model then follows. Direct injection comes from the user's own input; indirect injection, now the dominant form, arrives through content the agent retrieves on its own. For an agent with tools the consequence is an unauthorised action: leaking data, sending messages, changing settings or running commands. OWASP's 2026 Top 10 for Agentic Applications lists agent goal hijack, of which injection is the main vector, as its first risk.

What was the EchoLeak attack? EchoLeak, disclosed by Aim Labs in 2025 and tracked as CVE-2025-32711 with a CVSS score of 9.3, was the first known zero-click data exfiltration from an AI agent. An attacker sent a crafted email to a Microsoft 365 user. The user never opened it, but Copilot later retrieved the email as context for an unrelated request, followed the hidden instructions and sent data out of the organisation. It demonstrated that an agent with private data, exposure to untrusted content and an outbound channel can be exploited with no user action at all.

How do you defend an AI agent against prompt injection? Assume the model cannot reliably separate instructions from data and design the system so that no single agent holds all three ingredients of a breach: private data, untrusted input and an outward channel. In practice: map those three for every agent, give each agent its own narrowly scoped credentials, separate the components that read untrusted content from those that act, allowlist outbound destinations and strip links from output, validate every tool call in code before it runs, require human approval that shows the raw action for irreversible steps, and test injection cases in your evaluation suite while logging every run.

Related reading

• Agent permissions: how to decide what an AI agent may read, write and spend
• OpenAI's agents broke out of their sandbox and into Hugging Face. Lessons for anyone running agents
• Building evaluation harnesses for production AI systems
• Do you need an AI agent control plane?
• Microsoft wants an inventory of your agents

An agent that can be talked into acting against you is a fact of the technology in 2026, and the companies that run agents safely are the ones whose architecture assumes it. Drawing the trifecta for each agent you run, and putting the seven controls in place before the next one ships, is work we do inside an AI agents engagement.