AI Prompt Injection Attacks: Direct, Indirect and What Actually Reduces the Damage

A support agent is asked to summarise a customer thread. Buried in an earlier message is a line addressed to the agent, not to any human, telling it to forward the account notes elsewhere. Nobody typed that line into the agent's chat window, yet the agent may treat it as an order. That gap between who typed and who is obeyed is the whole subject of AI prompt injection attacks.

This article separates the two kinds, shows where each enters an agent, and sets out what reduces the damage and what only appears to. It relies on OWASP definitions, public research and the UK NCSC's guidance. No attack strings appear, and none are needed to plan a defence.

Two entrances to the same flaw

OWASP's LLM01 entry frames the weakness as model behaviour or output being altered in ways nobody intended, and says the indirect variety arises when a model takes in material from outside sources, websites and files among them (OWASP LLM01:2025). A jailbreak is a different animal, since it aims at the model's own safety training; this definitions article keeps the three terms apart.

Direct

The hostile text comes from the person using the application, through the prompt box or the API. The person who typed it can see it. The party usually harmed is the operator, because a policy gets bypassed, and the goal is typically output the product should not produce. Policy, rate limits and output checks are the main defences.

Indirect

The text comes from an outsider who controls something the agent reads: a page, a message, a file, a ticket, a tool result or another agent. The user may never see it. The victim is more often the user or the user's data, and the goal is an action or a transfer of data. The best defence is limiting what a hijacked agent can reach.

For agents the second kind dominates, since they ingest much more than people type. Public write-ups show how it plays out: ForcedLeak and EchoLeak both begin with content the agent was built to read. Both come from vendor or researcher reports, and each article says so.

Why it resists a fix

The NCSC explains the root: current language models do not enforce a security boundary between instructions and data inside a prompt, because underneath there is only the next token. That is why it argues prompt injection should not be treated like SQL injection, where parameterised queries remove the problem at its source, and why it says the risk can only be reduced and managed (NCSC blog). Every defence below should be read in that light.

What lowers the odds

Tagging data so a model can tell it from instructions is a genuine technique. In a paper on spotlighting, Microsoft researchers report that transforming untrusted input to signal where it came from reduced attack success from above 50 percent to under 2 percent in tests on GPT-family models, with little cost to task quality (arXiv:2403.14720). Those numbers come from one lab's own attack set.

Evaluation method is the counterweight. A 2025 paper named "The Attacker Moves Second" found that adaptive attacks defeated twelve published defences, mostly at rates over 90 percent, even though several had claimed close to zero (arXiv:2510.09023). Put the two side by side and the lesson is plain: probability-lowering measures help, and none deserves to be the only barrier. Filters and detectors catch careless attacks. Training makes models more resistant, yet the NCSC notes such work still overlays a distinction the technology does not make (NCSC blog).

What limits the damage

Architecture carries the strongest evidence. Two rules of thumb size an agent's power. Simon Willison's lethal trifecta says that combining private data, untrusted content and an outbound channel enables data theft. Meta's Agents Rule of Two caps a session at two of three properties: untrustworthy inputs, access to sensitive systems or private data, and the power to change state or communicate externally (Meta, Agents Rule of Two). Willison's commentary on the two papers records an objection, namely that untrusted input combined with state change can still hurt without any private data (Willison's write-up).

A person approving actions adds a further layer, though only when the reviewer sees what will really happen and not a description written by the agent.

Six steps against indirect injection

1. Inventory every source the agent reads, noting who may write into it.
2. Take away one side of the trifecta wherever you can, agent by agent.
3. Hand out credentials sized to the task and short-lived.
4. Insist on approval for sends, writes, payments and deployments while untrusted content sits in context.
5. Control destinations: allow named hosts only and block data hidden in URLs where possible.
6. Maintain a suite of harmless canary injections, described in prompt injection testing in CI.

Testing safely with a canary

No real attack content is needed to test your own agents. Pick a benign action that is easy to observe and that the agent has no reason to take, for instance stamping a particular test label on a ticket. Hide an instruction to do so in material the agent legitimately reads, then ask it to do its normal job. A label in the tool log shows the agent obeyed text it should have treated as data. Rerun after any change to prompts, tools or models, note the date and version, and stay inside systems and data that you own.

Sort by who writes, not by channel

The direct and indirect labels describe the channel. For defence, a more useful sorting question is: who can write to anything this agent reads, and how much do we trust them? A page from the public web, a message from a customer, a file from a partner and a note from a colleague are four different writers with four different trust levels, yet all four are usually called indirect.

The NCSC points to a rule that follows from this view: when a model processes information from a party, its privileges drop to that party's level, so an assistant processing mail from strangers should hold no privileged tools (NCSC blog). A writer map makes that rule checkable. List each input, the writer class, and the tools the agent may use while that input is in context.

This preference for writer classes over the direct and indirect pair has a limit. For a chat product with no tools and no stored data, the user is the only writer, and the direct label is enough. Once the agent reads anything a third party can influence, the writer map earns its keep. Rank which agents to fix first by two questions: how much untrusted content does each read, and what can each do afterwards?

Open points

• No control offers a guarantee, and adaptive results suggest filters should not be expected to.
• Evidence for architectural rules is mostly argument rather than measurement.
• Rates of real-world attacks are poorly measured, and reliable public figures are scarce.

The wider control set is in the runtime security guide. This page is no substitute for a review by qualified security engineers.

Prompt injection questions