Prompt Injection

Why does prompt injection happen at all?

Because a language model receives instructions and data through the same channel, as text, and has no structural way to tell them apart. A system prompt, a user’s question, a retrieved document and a tool’s response all arrive as tokens in a context window. The model infers which of them carries authority from how they read, not from where they came from.

That is a property of the architecture rather than a defect in any particular implementation. There is no flag that marks a passage as untrusted, and no equivalent of the separation that makes parameterized queries work in databases. This is why the problem has proved durable: every mitigation so far operates by making the model better at inferring which instructions to privilege, which is a different and weaker guarantee than making the distinction structural.

Worth saying early, because it shapes how much weight to put on everything that follows: prompt injection attracts more attention than any other topic in agent security, and it is not the largest category of agent risk. An agent can cause serious problems with no adversary present at all. Geordie’s argument for why the attention is disproportionate is in Prompt Injection Isn’t the Main Problem in AI Agent Security.

What are the types of prompt injection?

Three forms account for most of what organizations encounter, and they differ in where the attacker needs access rather than in what the model does wrong.

Type	Where the instruction enters	What it looks like in practice	Why it’s hard to catch
Direct	The attacker types into the agent themselves	A user of a shared or public-facing agent attempts to override its instructions or extract its system prompt	Comparatively tractable, because the input arrives at a known entry point that can be screened
Indirect	Content the agent retrieves on its own	Instructions hidden in a web page, email, PDF, repository file, calendar invite or tool response	The attacker never touches the agent. They only need to place content somewhere it will later read
Stored	The agent’s own memory or knowledge base	Adversarial text written into long-term memory or an indexed corpus, activating on a later session	It persists after the attacker has gone, and the agent carries it forward as its own context

Indirect injection is the form that matters most for enterprise agents, because it requires no access to the organization at all. An attacker who can get text into something an agent reads has a delivery mechanism. Stored injection is the more unsettling variant: research from Palo Alto’s Unit 42 demonstrated indirect injection manipulating session summarization so that adversarial instructions were written into long-term memory, persisting across sessions with no continued attacker access.

Why can’t it be patched like SQL injection?

The comparison to SQL injection is the one most people reach for, and the difference is instructive. SQL injection was solved structurally, by separating the query from its parameters so that user input could never be parsed as code. The fix works because SQL has a grammar, and data can be placed outside it.

Natural language has no such boundary. The instruction and the data are the same kind of thing, expressed in the same medium, and the model’s usefulness depends on its willingness to act on text it reads. A model that refused to follow any instruction found in retrieved content would also be unable to summarize a document that says “list the action items below.”

OpenAI has stated this plainly in its own published research, describing prompt injection against browser and computer-use agents as a problem unlikely to ever be fully solved, and comparing it to social engineering: reducible, not eliminable. Taking that at face value is the right starting position. It redirects the question from how to prevent injection toward how to limit what a successful injection can accomplish.

What does a successful injection actually do?

Nothing the agent could not already do. That is the key to reasoning about severity.

An injection does not create new capability. It redirects existing capability, which means the blast radius is defined entirely by what the agent is permitted to reach and what actions it can take without further checks. The same injection against a read-only research agent and against an agent holding production database credentials produces a nuisance in one case and an incident in the other.

Published cases make the range concrete. OpenAI’s own red-teaming produced a case where a malicious email containing hidden instructions caused an agent asked to draft an out-of-office reply to instead send a resignation letter to the user’s CEO. EchoLeak, tracked as CVE-2025-32711 at CVSS 9.3, was a zero-click injection in Microsoft 365 Copilot that exfiltrated sensitive context with no user interaction at all, by exploiting how markdown links were rendered. Microsoft patched it before disclosure and reported no confirmed customer compromise.

The practical implication is that prompt injection is best treated as an agent capability and permissions question rather than purely a content-filtering one. What the agent can reach determines what the attack is worth.

Do detection and filtering work?

Partially, and the limits are well documented enough to plan around rather than hope past.

Content classifiers and prompt shields catch a meaningful share of attacks, particularly those using recognizable injection vocabulary. Unit 42 found that enabling the prompt-attack guardrail stopped the multi-agent attack chain it had demonstrated against a Bedrock supervisor architecture, which is a genuine result and an argument for turning these controls on.

The difficulty is that detection degrades sharply against attacks that work through context rather than through phrasing. Recent academic work has found injection classifiers performing at close to chance when attacks manipulated the agent’s context instead of using injection-style commands, and separately found that safety training aimed at the problem could reduce an agent’s usefulness without reliably improving its security.

Two further findings are worth holding alongside that. EchoLeak was specifically phrased to evade cross-prompt-injection classifiers. And Zenity Labs has described techniques aimed directly at circumventing human approval checkpoints, which means the fallback of asking a person is itself a target rather than a backstop.

What actually reduces the risk?

Layered, and oriented toward containment rather than prevention:

• Scope what the agent can reach. An injection inherits the agent’s permissions, so least privilege does more to limit damage here than any filter.
• Enforce before execution, not after. A control that evaluates an action before it runs can stop it; a log tells you it happened. This is the distinction covered in agent lifecycle hooks.
• Keep enforcement independent of the model’s reasoning. A control the model can be talked out of triggering offers a weaker guarantee than one applied from outside its reasoning – which is the practical case for deterministic rather than probabilistic enforcement.
• Enable the platform’s own prompt-attack filters. They are not sufficient and they are not nothing, and the Unit 42 result shows they stop real attacks.
• Treat memory as a write target. Apply the same scrutiny to what gets summarized into long-term memory as to what gets executed, since stored injection persists after the attacker leaves.
• Instrument behavior, not just inputs. A successful injection shows up as the agent doing something inconsistent with its purpose, which is a behavioral signal rather than a content one.
• Keep an immutable record. Establishing what a compromised agent actually did requires an audit trail the agent cannot edit.