What Is Prompt Injection, Really? Why the Textbook Answer Cannot Tell You If You Have an Incident

Prompt injection is three things happening at once.

The definition written in 2022 described a model that followed an instruction hidden in the text it was asked to translate. The definition needed in 2026 describes an agent that read a support ticket and then queried a customer table it had never touched, using a service account nobody had revoked. Those are the same attack. The difference is that in 2022 the third part of the definition was switched off, because the model could only produce text, and in 2026 it is switched on, because the model can act.

Most definitions still describe the 2022 version. This one names all three parts, tests them against six cases, and ends with a sentence you can paste into an incident ticket.

Prompt Injection Takes an Untrusted Source, an Undivided Context, and Borrowed Authority

The first part is a source. Prompt injection begins when text enters the model’s context from somewhere the application trusts for content and does not trust for commands: a web page, a retrieved document, a ticket, an email, a tool result, another agent’s output. The researchers who first demonstrated injection through retrieved content called the attacker’s position “remote”: no access to the model’s interface, only to something the model would later read. The path the text takes decides who can attack you, and the direct and indirect labels describe that path. They stop describing anything once the text is inside.

The second part is the context. A language model receives the developer’s instructions, the user’s request and the retrieved content as one sequence of tokens, with nothing in the sequence that marks which tokens carry authority. Simon Willison’s original definition is a definition of this part: the attack works by concatenating untrusted input with a trusted prompt, and the model has no reliable way to tell where one ends and the other begins. Every technique for making the model prefer the developer’s text over the page’s text is a preference, trained in, and how that preference is built and why it holds at a rate is a separate question. For the definition, one sentence is enough: the model cannot structurally distinguish an instruction from data, so an instruction placed in data is a candidate instruction.

The third part is authority. The model’s output has to drive something. In a chatbot the output is displayed, and the harm is whatever the reader makes of the words. In an application the output is parsed into a tool call, a query, a message, a file write, a navigation, and executed with the credentials the application holds. The UK’s NCSC describes the resulting condition as a confused deputy: a component holding authority that exercises it on behalf of whoever wrote the text in front of it. Without this part, an injected instruction produces a strange paragraph. With it, the paragraph produces a database read.

Remove any part and the name stops applying. A user typing an override into their own chat window has no untrusted source; that is the user’s request, and if it defeats a refusal it is a jailbreak. A SQL string built from user input has an undivided context only until it reaches a parser with parameter boundaries, and that is classic injection, with a fix that has existed for twenty years. A model that reads a hostile page and answers with a limerick has met the first two parts and none of the third, and nothing happened.

Three parts, each necessary, together sufficient. That is the definition.

Standard Definitions Count Two of the Three

The published definitions name the source and the context, and stop.

Wikipedia’s entry describes inputs designed to cause unintended behavior by exploiting the model’s inability to distinguish developer prompts from user input, and adds indirect injection as a variant for models that browse. OWASP’s LLM01 entry defines the risk as user prompts altering the model’s behavior or output in unintended ways, then lists impacts that include unauthorized actions. The CWE entry describes a product that builds prompts from externally provided data such that the model fails to distinguish user input from developer directives. All three are accurate. All three describe the attack ending at the model’s output, and treat what happens next as impact rather than as part of the weakness.

There was a good reason to define it that way. In 2022 and 2023 the model’s output was the product. A chatbot that leaked its system prompt or insulted a customer had done the worst thing it could do, and a definition that stopped at the model captured the whole event. The entries’ own demonstrative examples show the era: a bot asked to write a haiku, a bot tricked into revealing a token. Reading the CWE entry for what its mitigation table therefore prescribes is its own exercise. For the definition, the point is narrower: two parts described the problem completely until the model could act.

OpenAI’s public account of the problem reaches for the third part without naming it, calling prompt injection a type of social engineering attack against conversational AI. Social engineering is the right frame precisely because the victim holds authority the attacker borrows. A model with nothing to do cannot be socially engineered into anything that matters.

Here is the useful consequence of the dropped part. The first two belong to the model vendor and the content’s author. The third belongs to you. What the application lets the model’s output do, with which credentials, against which destinations, is a decision your team made and can remake. The part the standard definitions leave out is the part you control.

Six Cases Decide What Counts

Apply the three parts and ambiguous events sort themselves.

Two rows deserve a second look. The jailbreak row fails on parts 1 and 3, which is why the operational split between injection and jailbreak comes down to who owns the fix: a model property belongs to the vendor, and an application property belongs to you. The SQL row fails on part 2, because a parser restores the boundary a language model lacks. That row is the whole reason the twenty-year-old fix does not transfer.

The verdict column changes what the ticket does next. Rows with three parts go to the team that owns the agent’s permissions, and they start a scope review. Rows with two go somewhere else: to the vendor, to the content team, to the database team. Getting the row right is the first thing a definition is for.

The Third Part Sets the Severity

Authority is the product of three quantities: the tools the agent can call, the credentials it holds, and the destinations its network reaches.

That product is the agent’s reach, and it is what the third part of the definition measures. Put one plainly worded sentence asking for a customer lookup in front of two agents. The first has read-only retrieval and a service account scoped to a wiki; it can return text about the request and nothing else. The second has a CRM tool, an account that reads customer records, and an egress policy that allows an external webhook. Same sentence, same model, same text-plane evidence, which is none. The first event is a curiosity. The second is tool misuse with a valid identity attached, and the technique that produced it needs no evasion at all, because nothing in the sentence is unsafe on its own.

The model-side definition is accurate about the mechanism, and it is the definition most people learned first because the mechanism is the surprising part. It stops one step early. Severity is a permissions variable, and permissions are set outside the model, which is also why every prevention claim reduces to a reachability claim about the third part rather than a filtering claim about the first two.

So when someone asks how bad prompt injection is, the definition supplies the answer: exactly as bad as what the application lets the model’s output do.

The Third Part Is Also Where the Evidence Is

When the injected text is a grammatical request for an authorized action, the first two parts leave no record worth having.

The source looks like every other page the agent reads. The context contains a sentence that a classifier scores as ordinary operational text, because it is ordinary operational text. What remains is the third part: a tool call with arguments, a credential exercised against a table, a connection opened to a destination, an identity presented to an API. The production chain for a prompt injection against an agent runs through eight stages, and the text is present at one of them. The other seven are actions.

An action is only evidence relative to a subject. A database read is routine for a reporting agent and unprecedented for a ticket summariser, and a fleet-wide rule cannot express the difference. ARMO records what each workload does in execution with a kernel-level sensor and builds a per-agent behavioral profile, Application Profile DNA (APD™), then evaluates each new action against that agent’s own history. The case the profile exists for is coercion: a trusted prompt redirecting authorized capability without breaking a single control, where every step is permitted and the sequence is the attack. That is the third part of the definition, observed from below.

Turning that observation into a bound follows the Audit and Enforce sequence. The sensor records first, the team reviews what a policy would have blocked against real traffic, and the policy arms per agent once the record shows the boundary is right. Credential isolation adds an outcome on top: when the agent holds placeholder credentials and the real ones are substituted outside its reach, an instruction that needs the key completes with a key that opens nothing, which narrows what borrowed authority can carry. The coercion still happens. The reach it borrows is smaller.

ARMO’s runtime security for AI workloads covers the third part of the definition: what the agent did, measured against what it does. Bring one production agent and its tool registry to a working session and the three parts get filled in against its actual runtime record.

A Definition That Fits in an Incident Ticket

Prompt injection is an instruction from an untrusted source, followed by a model that cannot tell instructions from data, acted on by an application with its own authority.

Write that sentence at the top of the ticket, then three lines under it. Source: where the text came from and who can write there. Model: what the model did with it. Application: what the application then did, with which credential, against which destination. If the third line is empty, the ticket is a content-policy issue or a vendor report. If the third line has anything in it, you have prompt injection, and the third line is the incident.

FAQ

Is prompt injection the same as jailbreaking? No. A jailbreak has no untrusted source, since the user is the attacker, and no borrowed authority, since the harm is the text the model produces; the target is the model’s safety training and the fix belongs to the model vendor. Prompt injection has all three parts, and its fix belongs to whoever runs the application. The two separate cleanly by owner even when one payload carries both.

Is prompt injection a vulnerability in the model or the application? The condition is the model’s: it cannot structurally separate instructions from data, and no vendor has shipped a model that can. The vulnerability is the application’s: it decided what the model’s output is allowed to do and with which credentials. That split is why the same model is safe inside a read-only chatbot and dangerous inside an agent holding a service account.

Can prompt injection happen without an attacker typing anything? Yes, and that is the form that reaches production. Indirect prompt injection places the instruction in content the application will retrieve later, such as a web page, a document, an email, a ticket or a tool result. The attacker never touches the model’s interface and may never learn which user triggered the retrieval. Delivery path is the only difference, and it decides who is able to attack you.

What is the difference between direct and indirect prompt injection? Direct injection arrives through the application’s input field, from the user. Indirect injection arrives through content the application reads on the user’s behalf. Both meet the definition once the text is in context and the application can act on the output; the label describes the source, which is the first of the three parts, and it tells you which pipeline to inspect.

Is prompt injection a security incident? When the third part is present, yes. If the application did something with its own authority because of an injected instruction, a record was read, a message sent, a connection opened or a file written, and that is an incident with a scope review and possibly obligations that depend on the data. If the model only produced text, it is a content or vendor issue. The line is the third part.