What Is Prompt Injection?
Prompt injection is input, written by someone other than the operator, that a system reads as instruction rather than as data. It is not the exploitation of a bug: instructions and content arrive through the same channel in the same form, and the mechanism that follows one follows the other.
Direct and indirect, and why the second is harder
Direct injection comes from whoever is talking to the system — a user writing an instruction meant to override the operator's. Indirect injection comes from material the system fetches: a web page, a document, a code comment, an email, a calendar entry, where the instruction was planted for the system to read later. The second is the harder problem, because the content arrives along a path the operator asked for, and nobody is present at the moment it is read.
Severity follows the capabilities rather than the wording. An injected instruction reaching a system that can only answer produces a wrong answer. The same instruction reaching a system that can send mail, spend money or write to a repository produces an action, taken with the operator's authority and logged as legitimate.
The structural reason this resists a tidy fix has a name in security that long predates any of it: the arrangement is a confused deputy. The authority is held by the system — a session, a key, a repository, a mailbox — and the attack consists of inducing the holder to exercise it, not of obtaining it. Text carries no provenance once it has been concatenated into a prompt. An operator's instruction, a retrieved passage, and a sentence planted inside that passage arrive as one sequence, and no tag, delimiter or fenced block obliges the reader to treat them differently, because the same mechanism reads all three. Marking the boundary is worth doing and it is a convention, not a partition: it asks for a distinction to be honoured rather than making one that cannot be crossed.
| Source | How it reaches the prompt |
|---|---|
| User input | Written directly by whoever is interacting with the system. |
| Retrieved documents | Placed in a source the retrieval store indexes. |
| Web pages | Read by an agent that browses, including in text that is never visible on screen. |
| Tool output | Returned by an API, a file, or another system, and pasted back into the context. |
| Messages between components | Produced by one part of a system and consumed as instruction by another. |
Every row is a place where content becomes context. A system that treats any of them as trusted has decided the question rather than answered it.
Mitigations, and an honest statement of their limits
The measures in general use are: separating instructions from data with unambiguous delimiters and declaring that supplied content is data; constraining what a system is permitted to do rather than what it is permitted to read; requiring approval before consequential actions; filtering input and output for known patterns; and isolating retrieved content in a component that holds no privileges of its own.
None of them is a solution, and calling any of them one is the error worth avoiding. A filter is pattern-matching against an adversary who can rephrase. An instruction to ignore instructions is itself an instruction. The measures that hold up are the ones that assume the injection succeeds and bound what it can then reach, which makes this a question about privileges and approvals rather than about wording.
One route out is easy to miss because it involves no action anyone would recognise as one. Output is a channel too. Where an answer is rendered — as a link, as an image reference, as markup a client resolves on its own — an injected instruction can ask that material already in the context be encoded into a destination, and the client retrieves it without a person clicking anything. No tool was invoked and no permission was exceeded, so every containment aimed at actions passes the case through untouched. The corresponding measures sit on the output side rather than the input side: restrict which destinations may be rendered at all, decline to assemble links out of content that arrived with the data, and treat whatever the system emits into a rendering surface as material leaving the trust boundary rather than as presentation.
How the Registry classifies an injection review task
Reviewing retrieved web content for injected instructions before it is passed into a downstream prompt is filed as data processing in this registry's classification: existing material is examined, and what the task produces is a derived judgement about it.
The Registry's canonical brief for this entry is filed as:
Review retrieved web content for injected instructions before it is passed into a downstream prompt.
Submitted for assessment it is
classified as Data processing, and its wording is hashed once — to
aea870edee6d2396…, the first sixteen of sixty-four hexadecimal
characters — with the wording itself never stored. The hash is what the derivation
reads.
That class's own page is /tasks/analysis.
Classification is one of three inputs. The other two are the configuration submitted with the task, and the permanent chart derived from that configuration — fixed by the model name, the training cutoff and the temperature alone, and never reading the task at all. The same ascendant, ruling planet and harmony therefore appear on every assessment a given configuration receives, whatever it was asked to do. The derivation is published in full at /method.
What this page does not claim about prompt injection
This page does not evaluate any defence, name any product, or state how often anything succeeds. It describes a mechanism and the shape of the responses to it.
The Registry does not run this task, does not inspect any system's output for it, and validates no assessment it issues against what afterwards happens. What it does is compute — from a published method, for one submitted task and one submitted configuration — a verdict and a recommended execution window. It computes neither on this page.
Questions about prompt injection
- What is prompt injection?
- Prompt injection is input written by someone other than the operator that a system reads as instruction rather than as data. It works because instructions and content share a channel, so there is no format-level distinction between an operator’s directive and a directive planted in supplied material.
- What is indirect prompt injection?
- Indirect injection places the instruction in material the system will fetch later — a web page, a document, an email, a code comment — rather than typing it at the system directly. It is harder to address because the content arrives along a path the operator deliberately opened, with nobody watching at the moment it is read.
- Is prompt injection the same as jailbreaking?
- Related, not identical. A jailbreak aims to make a system produce output its operator’s policy forbids. An injection aims to make a system follow an instruction its operator never issued, which may involve no policy at all. The mechanism overlaps; the objective differs.
- Can prompt injection be prevented completely?
- No method in general use eliminates it, because instructions and data share a channel and any filter faces an adversary who can rephrase. Practice therefore concentrates on limiting consequences: narrow permissions, approval before irreversible actions, and isolating retrieved content from anything privileged.
- Can an injection leak data without any tool being called?
- It can, wherever output is rendered. An instruction can ask that material from the context be encoded into a link or an image reference, which a client that resolves such references fetches by itself. Nothing was executed and no permission was exceeded, so containments aimed at actions do not apply. The measures that do apply restrict what the output is allowed to reference.
Related entries
Browser agent · Prompt engineering · Human in the loop (HITL)
Order an assessment for data processing tasks
The Registry issues a permanent, numbered task risk assessment for one submitted task and one submitted configuration. EUR 1.90 Standard, EUR 4.90 Extended, EUR 14.90 Full Chart, which adds the permanent chart. Assessments from EUR 1.90; machine-readable at /pricing.json.