What is prompt injection?

Prompt injection is when text a language model reads changes what it does, against the intent of the people who built it or use it. It works because a model receives its instructions and its data as one stream of text, and cannot reliably tell them apart.

Simon Willison coined the term and named it after SQL injection, which has the same root: trusted and untrusted input mixed in one channel. It is often confused with jailbreaking, where a user talks a model into saying something its maker does not want. OWASP treats jailbreaking as one form of prompt injection. Willison keeps the two apart: a jailbreak tricks a model into something embarrassing, while prompt injection is about trusted and untrusted content mixed in one context.

OWASP’s LLM01:2025 separates two kinds. In a direct injection, the person typing the prompt is the attacker. An example is a user who tells a support chat to ignore its previous instructions. In an indirect injection, the instruction arrives inside content the model reads from somewhere else, such as a website or a file.

Indirect injection is the one that matters for an enterprise assistant. The attacker never talks to it. They write a supplier notice, an email, a ticket comment or a wiki page the assistant will later search or summarize. Greshake and colleagues, who described the attack in a 2023 paper, put the cause in one line: applications built on language models “blur the line between data and instructions.”

The instruction does not have to be visible. OWASP notes that it only has to be parsed by the model, and gives instructions hidden in an image as one example.

A model sees one sequence of tokens. Telling it to ignore instructions found in documents is itself an instruction, and the model follows it most of the time, not every time. An attacker can phrase the same request in any number of ways and try until one works.

Detection helps less than it seems. OWASP’s guidance says “it is unclear if there are fool-proof methods of prevention for prompt injection.” Willison points out that a filter which catches 95% of attacks is a failing grade in application security. An attacker can keep trying until one gets through.

A documented case shows how the pieces chain. EchoLeak, tracked as CVE-2025-32711, let one crafted email make Microsoft 365 Copilot send data out with no click from the user. The case study describes how it evaded Microsoft’s classifier for injection attempts, got around link redaction and used images the client fetched on its own.

In June 2025 Willison named the combination that turns an injection into a data leak. An assistant is at risk when it has all three: “Access to your private data”, “Exposure to untrusted content” and “The ability to externally communicate”. With all three, a hidden instruction can tell it to read your data and send it out.

The way out is wider than it looks. A request to an API is one. So is an image whose address carries data in its query string, or a link the user is invited to click. Willison notes that most vendor fixes for these leaks closed the way out. The other two legs are usually why the assistant exists.

An assistant that can change things carries a fourth risk. A steered model with write access can do harm without sending anything anywhere: delete a record, change a setting, add an endpoint. So the question is what a steered assistant can reach, read and change, not only what it can send.

Since the model cannot be trusted to refuse, the design has to limit what it can do once it is steered. The design patterns paper from researchers at IBM, Google, Microsoft, ETH Zurich and others puts the principle this way: once an agent has read untrusted input, that input must not be able to trigger consequential actions. For an enterprise assistant, the principle comes down to three limits.

• Scope what it can reach. It reads as the person asking, under their permissions, not as a service account that sees everything. See What is permission-aware retrieval?
• Give data no way out. No network by default, no requests to addresses the model chose, and no images or links rendered from its output without a check.
• Make changes wait for a person. OWASP lists human approval for high risk actions among its mitigations. The approval should bind to the exact change shown, not to a summary of it.

None of these prevents injection. A steered model can still write a wrong summary or a bad draft. What they limit is how far the damage travels.

Assume the prompt is steered, then ask what the assistant can reach. Five questions cover most of it:

• What untrusted content can reach it: email, web pages, uploaded files, tickets, tool results?
• What private data can it read, and as whom?
• What ways out does it have: network requests, rendered images and links, email, tools that write elsewhere?
• What can it change, and who approves the change before it applies?
• Is the approval bound to the exact change, and can an applied change be traced and reversed?

An answer that relies on the model noticing the attack is no answer. An answer that names what is absent is a good one.

Sudo, the admin assistant in Curiosity Studio, reads untrusted input as part of his job: a ticket, a field report, a file an admin attaches. So he is built for the day his prompt is steered.

He works in a sandbox whose filesystem is the workspace configuration. Every command is managed code inside the server, with no fork and no exec, and curl, wget, ssh and git are absent rather than refused. The sandbox has no network. The one exception is a headless browser, off until an administrator turns it on and limited to the hosts they allow.

He reads the graph as the administrator in the chat, and he writes none of your data. His edits stay in his own copy. A commit stages them and stops, and an administrator reads the diff and applies it. The approval is bound to the commit that was shown, so a newer one cannot slip through.

What this does not do: it does not detect an injection. A steered prompt can still change what Sudo drafts, so the reviewer has to read the diff. Every applied commit is recorded, attributed to the admin who approved it, and can be reversed. The Inside Sudo paper has the details.