What is prompt injection?

Prompt injection, defined

Prompt injection is an attack on an application built on a large language model (LLM): text the model processes changes what the model does, against the intent of the people who built the application. The text can come from the person in the chat, or from anything the model is given to read.

The name dates from September 2022, when Simon Willison proposed it and drew the obvious parallel with SQL injection: in both cases, data that was meant to be read ends up being obeyed.1 The parallel is useful for the first five minutes and misleading after that, for reasons this piece comes back to.

OWASP defines a prompt injection vulnerability as one where prompts alter the model’s behaviour or output in unintended ways, and places it first in its Top 10 for LLM Applications.2 It held that position in the 2025 edition and keeps it, as LLM01:2026, in the edition published on 3 August 2026.3

MITRE ATLAS catalogues the same attack as technique AML.T0051, LLM Prompt Injection, and describes it as a possible initial access vector: a foothold from which an attacker carries out the next steps of an operation.4

What is the difference between direct and indirect prompt injection?

In a direct injection the attacker is the user. They type into the chat box and try to talk the application out of its instructions. In an indirect injection the attacker never talks to the system at all: they place text where the system will read it later, in a web page, a shared document, an email, a support ticket or the output of a tool.5

The indirect form was set out in 2023 by Greshake and colleagues, who showed it against real LLM-integrated applications and argued that such applications blur the line between data and instructions.6 ATLAS has since added a third sub-technique, Triggered, for injections set off by a user action or an event in the victim’s own environment.7

That last row is the reason indirect injection matters most for agents. A direct attacker can only abuse their own session. An indirect attacker borrows someone else’s: the agent reads the planted text while working for a legitimate user, and acts with that user’s access. Fig. 1 follows one such line through a fictional insurer’s support agent, from its knowledge base into the stack beneath it.

Why does prompt injection work at all?

A model receives one stream of tokens. The developer’s instructions, the user’s message, a retrieved document and a tool result all arrive in that same stream, and nothing in it marks which parts are commands and which are material to work on (Fig. 2). Models are trained to give the developer’s instructions more weight, but that is a tendency learned from examples, not a rule the system enforces.

The UK National Cyber Security Centre made the point bluntly in December 2025: current LLMs do not enforce a security boundary between instructions and data, prompt injection may never be totally mitigated, and the realistic aim is to reduce the likelihood and the impact of attacks.8 Its author calls the model an inherently confusable deputy. That is where the SQL comparison breaks: SQL injection has a structural fix, the parameterised query, which keeps data out of the command channel. Language models have no equivalent channel to keep it out of.

OWASP draws the same conclusion from another angle: retrieval-augmented generation and fine-tuning make outputs more relevant, but they do not fully mitigate prompt injection.9 So the useful question is not how to make the model unpersuadable. It is what a persuaded model is able to do.

What can an attacker do with prompt injection?

The impact of a prompt injection is the reach of the system it lands in. The model’s words are rarely the damage; what the application does with them is. The consequences fall into four groups.

• Disclosure. The model reveals what it was given but should not pass on: hidden instructions, configuration, another user’s data, documents from the wrong tenant. OWASP is explicit that a system prompt should not be treated as a secret or used as a security control.10
• Actions. An agent calls the tools it holds on the attacker’s behalf: it sends the email, files the refund, updates the record. ATLAS describes how tool invocation can give an attacker the privileges of the integrated service, and how a tool that writes can carry data out inside a legitimate-looking action.11
• Output. The model’s answer is rendered or executed downstream without being treated as untrusted input, so the injection becomes a classic web or code execution flaw. OWASP files this under LLM10:2026, Improper Output Handling.3
• Persistence. The instruction is written into memory or a shared store, and keeps steering the system long after the original content is gone.

The OWASP Top 10 for Agentic Applications names the agent-level version of this risk as ASI01, Agent Goal Hijack: the attacker does not need the model to say anything wrong, only to pursue a different goal with the tools it already has.12

How do we test for prompt injection?

Testing for prompt injection is not a matter of trying a list of famous prompts. Those lists measure whether a filter has seen them before. We test the structure instead, in a scoped environment and under written rules of engagement.

1. Map the channels. Every place text enters the context: user turns, uploads, retrieval sources, web access, email, tickets, tool results and memory, with who can write to each.
2. Map the capabilities. Every tool, token, scope and renderer the model can reach, and whose permissions each one carries.
3. Pair them. For each channel and capability, we try to make content from that channel steer that capability, with probes written in our own lab for this system.
4. Repeat. Model output varies between runs, so each successful attempt is replayed and reported with its reproduction rate, model, version and settings.
5. Follow it into the stack. When the model is steered, we follow the request it makes: does the token behind it reach objects, records or tenants it should not?

The report names the control that would have stopped each finding, maps it to LLM01:2026 and the ATLAS technique, and gives a severity that reflects the reach, not the cleverness of the wording.

How do you defend against prompt injection?

Assume the model can be talked into anything it is able to do, and make sure that what it is able to do is safe. The defences that hold sit outside the model, where behaviour is deterministic. The NCSC recommends exactly that emphasis, plus enough logging of inputs, outputs and tool calls to see abuse when it happens.13

Most of these appear in OWASP’s own list of mitigations for LLM01, from constraining model behaviour to requiring human approval and running adversarial tests.14 The order above is ours: the first three cap the damage, the rest lower the odds.

The takeaway fits in one line: a prompt is not a vault, and a model is not a permission system. Put the rules that matter where text cannot argue with them.