prompt injection

No. 096 · v2026-08FR: injection de prompt

Prompt injection means slipping into a text the system reads an instruction that takes precedence over the designer’s own, because the model receives both as a single stretch of text and cannot tell which one carries authority. Like an unsigned note slipped into a file handed to an employee: they read it along with the rest, and nothing on the paper says it did not come from management.

What it is not

Prompt injection is not a fault that a guardrail comes along and fixes, and that is the confusion which costs the most. A guardrail lowers how often cases occur and bounds the damage, it does not make the system impervious: adding an instruction forbidding the model to obey instructions found in documents amounts to setting text against text, in the same place, with no guaranteed hierarchy. Nor is it a manufacturing defect that a patch will close, the way a software vulnerability is closed: it is the direct consequence of what makes a language model valuable in the first place, namely that it follows instructions written in natural language. As long as instruction and data arrive in the same form, the risk shrinks, it does not disappear.

In depth

The root cause

The root cause is not an oversight in implementation, it is a property of the arrangement: the context is a single stretch of text, and within it the model has no structural means of separating an instruction from a piece of data. The system prompt, the history of the exchange, an extract of a document retrieved by RAG, a tool result and your own request all reach the model through the same channel, in the same form. The roles that label them are markers inside the text, whose authority comes from training and not from transport: they make an instruction more likely to be followed, they do not make it binding. An imperative sentence placed inside reported content therefore competes directly with the designer’s instructions, and the model arbitrates according to what seems most plausible at that point in the text. That is why the flaw cannot be fixed where it is observed: it is bound to the very ability to follow instructions in natural language, which is what a language model was chosen for.

Two forms

Two forms are distinguished, and they do not call for the same defences. Direct injection is the work of the user themselves, who seeks to get around the product’s permanent instruction: to make it say what that instruction forbids, to obtain its substance, to step outside the intended scope. The damage stays bounded, because whoever makes the attempt is also on the receiving end of it, and because the exposure is limited to what their account could already reach. Indirect injection is far more serious: the instruction is deposited in a page, a document, a ticket or an email that the system will read for a quite different reason, and it runs to the benefit of its author, against the legitimate user. The victim is no longer the person who wrote, and they have no way of seeing what happened, since the reported content is never shown to them as the model read it. Every uncontrolled source that enters the context therefore becomes an attack surface, and taking an inventory of those sources is the first job to do.

What makes it serious

The severity is read not in the injected text but in what the system can do once it has been persuaded. On an assistant that merely answers, a successful injection produces a false or improper answer, which is a content incident. On a system equipped with tools, it triggers an action: reading a file nobody asked for, writing, sending, paying. Outbound network access on its own is then enough to carry out whatever the context held. The risk therefore rises with autonomy, because an agent chains its steps without coming back to you, and because the contaminated result of one turn becomes the input of the next. Three design errors recur: treating a tool result as trustworthy data when it is an uncontrolled input, granting one and the same system the right to read public sources and the right to act on sensitive resources, and relying on the system prompt to hold what only an execution-time control can hold. What genuinely protects is placed outside the text: least privilege in a sandbox, separation between what reads and what acts, human validation on anything irreversible, and logging that at least makes it possible to establish afterwards what happened.

Under the hood2 steps · the real shape of the objects

Layer 2 states that the separation does not exist. The reason is visible in the object itself: a message carries who spoke and what was said, and nothing at all that says where the text came from.

01
Two messages nothing separates
On one side what you wrote, on the other what a fetched page contains. Both objects have the same shape, the same fields, the same place in the list. No field says that the second one comes from a source nobody controls.
json
```
{
  "role": "user",
  "content": "Summarise this page and tell me whether it is reliable."
}

{
  "role": "user",
  "content": "[fetched page] … whatever the page contains …"
}
```
role
It says who spoke, never how much authority to grant. There is no value that would mean “untrusted content”.
content
A string, and nothing else. The bracketed “[fetched page]” is a convention the harness writes into the text itself: it is content, not a guarantee, and fetched text can imitate it.
the missing field
There is no “provenance” and no “trust”. That absence, and only that, is what makes injection possible: the model cannot decide on information it is never given.
The trapThis is why an instruction of the kind “do not obey instructions found in documents” cannot be enforced by the format. It asks the model to sort by an origin the object does not carry.
02
When the fetched text comes back from a tool
The serious case is not the one where you paste the page yourself, it is the one where the system goes and gets it alone. The tool result then enters the same list, in the same shape, and the loop reads it the way it reads everything else.
json
```
{
  "role": "tool_result",
  "tool_call_id": "c_31",
  "content": "… whatever the resource returned, word for word …"
}
```
tool_call_id
It ties this result to the request that produced it. It attests to the sequence, never to the content: knowing which tool spoke says nothing about what it was made to say.
content
Returned as is, because that is the whole point of a tool. A service, a page, a mailbox, a repository: the material is written by somebody other than you.
The trapThe victim is no longer the author of the attempt, and sees nothing: this block is never shown to them. That is the difference between direct injection, bounded by what its author could already reach, and indirect injection, which runs for the benefit of a third party.

Shown elsewhere

contextthe whole list, and how it is flattened into a single string before the model
tool callingthe full circuit by which an uncontrolled result comes back into the loop

What variesField and role names vary from one provider to the next, and some expose a distinct role for tool results where others file them among ordinary messages. What does not vary: no common format carries the provenance of a piece of content, roles remain markers inside the text rather than separate channels, and the only boundary that holds is set at execution, on what the system is allowed to do.

Dated examples

2026-08

The class of attack is acknowledged as unresolved by the main providers: their documentation treats it as a risk to be contained by architecture, never as a defect closed off by a model version. Public work on application security places it at the head of the risks specific to applications built on language models, and attention has shifted from the direct form to the indirect one as agents have gained access to the web, to mailboxes and to code repositories. The measures that count are architectural: marking reported content as untrusted, separating reading tools strictly from acting tools, requiring human confirmation on anything irreversible. The European AI regulation does not use the word, but its robustness and human oversight obligations for high-risk uses address it in practice.

Relations where the neighbours live

Runs inside: harness
Requires: system prompt context
Often confused with: guardrails

Check 3 questions · click your answer

Level 1 · Recognise

An assistant summarises a web page, and its answer plainly follows an instruction you never wrote. What has happened?

Level 2 · Distinguish

To prevent injections, an instruction is added to the system prompt forbidding the model to obey instructions found in documents. What does that achieve?

Level 2 · Distinguish

Why is indirect injection judged more serious than direct injection?

Who works with this 1 role

The roles for which this term is part of the ordinary work.

AI red teamerThe one who derails the system before anyone else does

No. 096 · v2026-08 · first written in August 2026 · editorial responsibility Anthony Capirchio

Cite this entry

Lexigraph, "Prompt injection", v2026-08, https://www.lexigraph.org/en/prompt-injection/, CC BY 4.0.