What Is Prompt Injection? OWASP's LLM01 Explained

What is prompt injection

OWASP's definition is short: a Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways.

It sits at LLM01, the first entry in OWASP's Top 10 for LLM applications, which is a ranking of risk in systems built on language models.

The reason it ranks first is not that it is exotic. It is that the thing being exploited is the thing that makes the system work. A language model takes text and acts on it. Instructions and data arrive through the same channel, as text, and the model has no reliable way to tell one from the other.

Direct and indirect, and why the second is worse

OWASP splits it in two.

Direct prompt injection is when a user's own prompt input directly alters the model's behaviour. OWASP notes this can be deliberate or accidental, which is worth sitting with: someone can trip this without trying.

Indirect prompt injection is when the model accepts input from external sources such as websites or files, and content hidden in that material changes what the model does. The person running the model never typed the instruction. They asked it to read a page, and the page contained the attack.

Indirect is the harder problem because the attack surface is everything your system reads. A model that browses, opens documents, reads email or calls tools is consuming text written by people who are not your users.

“A Prompt Injection Vulnerability occurs when user prompts alter the LLM's behavior or output in unintended ways.”

OWASP, LLM01 Prompt Injection

OWASP adds a detail that closes off the obvious defence: these inputs can affect the model even when they are imperceptible to humans. Injected text does not have to be visible. White text on a white background, content in metadata, or phrasing that reads as innocuous to a person can still be parsed by the model.

A vibrant workspace showing computer monitors with code, keyboard, and tech accessories — Indirect injection means the attack can arrive in anything the system reads, not only in what the user types. Photo: Jakub Zerdzicki / Pexels

Why this is not a bug you can patch

A conventional injection flaw, say SQL injection, has a clean fix: separate the code path from the data path so user input can never be executed as a command. Parameterised queries solve it structurally.

Language models have no equivalent separation. The prompt, the retrieved document, the tool output and the system instructions all arrive as text in the same window, and the model's job is to be responsive to text. You can tell it which parts to trust. You cannot make it unable to read the rest.

This is why OWASP's own wording is as careful as it is. It says it is unclear if there are fool-proof methods of prevention for prompt injection, and describes its listed measures as limiting impact rather than removing the flaw.

That is an unusual thing for a security standard to say about its own number one risk, and it should shape how systems get built.

What OWASP actually recommends

Seven measures, and the ordering is informative:

1. Constrain model behavior. Set clear role and limit instructions in the system prompt. 2. Define and validate expected output formats. Require specific formats and check them with deterministic code. 3. Implement input and output filtering. Apply semantic filters and string checks. 4. Enforce privilege control and least privilege access. Give the application its own API tokens and handle functions in code rather than through the model. 5. Require human approval for high-risk actions. Human-in-the-loop for privileged operations. 6. Segregate and identify external content. Mark untrusted material clearly so it carries less influence. 7. Conduct adversarial testing and attack simulations. Test trust boundaries regularly, treating the model as an untrusted user.

“it is unclear if there are fool-proof methods of prevention for prompt injection”

OWASP, in its own guidance on the risk it ranks first

Notice what most of these have in common. Only the first two are about the prompt. The rest are about building the system so that a successful injection still cannot do much: limited privileges, deterministic checks on the way out, a human in front of anything consequential.

That last framing, treat the model as an untrusted user, is the most portable idea on the list. It converts an unsolved problem in model behaviour into a familiar problem in access control, which is a field that does have fool-proof methods.

What this means if you are shipping something

The practical question is not whether your prompt can be broken. Assume it can.

The question is what an attacker gets when it is. If the answer is a rude reply, you have a reputational issue. If the answer is a database write, an outbound email, a payment or a file read, the injection is not the vulnerability. The privilege you handed the model is.

Frequently asked questions

What is prompt injection?

OWASP defines it as a vulnerability that occurs when user prompts alter the LLM's behavior or output in unintended ways. It is ranked LLM01, the first entry in OWASP's Top 10 for LLM applications. The underlying problem is that instructions and data reach a language model through the same channel, as text, and the model has no reliable way to tell which is which.

What is the difference between direct and indirect prompt injection?

Direct prompt injection is when a user's own prompt input directly alters the model's behaviour, which OWASP notes can be deliberate or accidental. Indirect prompt injection is when the model accepts input from external sources such as websites or files, and hidden content there changes its behaviour. Indirect is generally the harder problem, because the attack surface becomes everything your system is allowed to read rather than only what your users type.

Can prompt injection be completely prevented?

OWASP's own guidance says it is unclear if there are fool-proof methods of prevention for prompt injection, and describes its seven listed measures as limiting the impact rather than eliminating the flaw. That is an unusually candid statement for a security standard to make about its top-ranked risk, and it is the single most important fact to carry into a design review. Build on the assumption that injection will sometimes succeed.

Why can't you just fix it the way SQL injection was fixed?

SQL injection has a structural fix: parameterised queries keep user input off the code path entirely, so input can never be executed as a command. Language models have no equivalent separation. The system prompt, the user's message, retrieved documents and tool output all arrive as text in the same context, and the model's purpose is to be responsive to text. You can label which parts to trust. You cannot make the model unable to read the rest.

Does injected text have to be visible to work?

No, and this is one of the more counter-intuitive points in OWASP's entry. It states that these inputs can affect the model even when they are imperceptible to humans. Text hidden in page markup, content that reads as innocuous to a person, or instructions placed where a human reader would not look can still be parsed by the model. Visual review of a page is therefore not a defence.

What are OWASP's recommended mitigations?

Seven: constrain model behaviour through clear role and limit instructions; define and validate expected output formats and check them with deterministic code; implement input and output filtering; enforce privilege control and least privilege access, giving the application its own API tokens and handling functions in code rather than through the model; require human approval for high-risk actions; segregate and clearly identify external content; and conduct adversarial testing and attack simulations against trust boundaries.

Why do most of the mitigations have nothing to do with the prompt?

Because the prompt is the part you cannot fully secure. Only the first two of OWASP's seven measures concern the prompt itself. The remaining five are about system design: least privilege, deterministic output checks, human approval for consequential actions, clear separation of untrusted content, and adversarial testing. The strategy is to make a successful injection cheap rather than to make injection impossible.

What does treat the model as an untrusted user mean in practice?

It means giving the model the access a stranger would get, and no more. If the model can trigger an action, assume an attacker can trigger that action through the model. That reframing matters because access control is a mature field with reliable techniques, whereas controlling model behaviour through instructions is not. It converts an unsolved problem into a solved one by moving where the control sits.

Are AI agents more exposed to this than chatbots?

Generally yes, for two compounding reasons. An agent reads more external material, which widens the indirect injection surface, and it can take actions, which raises the value of a successful attack. A chatbot that gets injected says something wrong. An agent that gets injected may send, write, buy or delete. OWASP's emphasis on privilege control and human approval for high-risk actions is aimed squarely at that difference.

How do you test for prompt injection?

OWASP recommends adversarial testing and attack simulations conducted regularly, treating the model as an untrusted user and probing trust boundaries. In practice that means attempting injection through every channel the system reads from, not only the chat box: documents, retrieved pages, tool responses and any other external input. Because new phrasings keep working where old ones stop, this is a recurring exercise rather than a one-off sign-off.

What is prompt injection, and why does OWASP say there may be no fool-proof fix?