Prompt Injection: OWASP Says There May Be No Fool-Proof Fix. Here Is What Actually Helps

Most vendor writing on prompt injection ends with a product. The OWASP page on it ends with an admission, and the admission is the most useful sentence published on the subject: given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection. That is the security community's own top-ten entry for language models saying, in its own words, that this may not be solvable. Everything practical follows from taking it seriously.

What it is, and why the name understates it

Prompt injection is LLM01 in the OWASP Top 10 for LLM Applications — the first entry, ahead of data leakage and supply chain issues. OWASP separates two forms. Direct prompt injection is when "a user's prompt input directly alters the behavior of the model in unintended or unexpected ways". Indirect prompt injection is when "an LLM accepts input from external sources, such as websites or files", and that external content changes its behaviour. In both cases OWASP notes the manipulation may be deliberate or entirely accidental.

The word "injection" invites a comparison with SQL injection, and the comparison is where teams go wrong. SQL injection has a fix: separate the query from the data with parameterised statements, and the class of bug disappears. There is no equivalent separation here. Your system prompt and an attacker's paragraph arrive at the model as the same kind of thing — text — and nothing in the format marks one as authoritative. That is not an implementation gap waiting for a patch; it is a property of how the models work.

The indirect case is the one that surprises people

Direct injection is visible. Someone types into your chat box, you see the traffic, you can rate-limit it and log it. Indirect injection is quieter: your agent fetches a web page, reads a PDF a customer uploaded, or summarises a support ticket — and instructions sitting in that content get read as though you had written them. The attacker never touches your interface, and nothing in your logs looks like an attack.

This matters because it follows automatically from the architecture, not from a mistake. Any agent that browses the web, opens files, or ingests third-party data has this exposure by construction. It is also why Cloudflare named isolation against prompt injection as a design goal when it built a browser specifically for agents rather than for people: the moment an agent reads the open web, the open web is an input channel.

A black and white striped barrier tape reading DANGER, stretched across a dark scene — Barrier tape reading DANGER. It marks a boundary without physically enforcing one - which is exactly what "segregate and identify external content" does for an agent: labelling untrusted input helps, but the label is not a wall.

The seven mitigations OWASP names

OWASP lists seven strategies, and it is worth noticing that not one of them is a product you can buy:

Constrain model behavior through system prompts
Define and validate expected output formats
Implement input and output filtering
Enforce privilege control and least privilege access
Require human approval for high-risk actions
Segregate and identify external content
Conduct adversarial testing and attack simulations

Read as a list, they look like seven boxes to tick. Read as a set, they describe something more specific: an architecture built on the assumption that the model will occasionally be talked into something, and that the job is to make sure whatever it is talked into is cheap to undo.

Two of the seven hold even when the attack works

The first three items — system prompts, output formats, input and output filtering — all raise the cost of an attack. They are worth doing, and they all fail eventually, because they operate on the same channel the attacker is using.

Privilege control and least privilege access, and human approval for high-risk actions, are different in kind. They do not try to stop the model being persuaded. They limit what a persuaded model can do. If your agent has read-only credentials, a successful injection reads something it should not — bad, bounded, recoverable. If it holds a payments token, the same successful injection is a different conversation entirely.

This is why the useful question before deploying an agent is not "how good is our prompt". It is: what is the worst thing this agent can do without a human in the loop, and are we willing to have that happen by accident? An agent that drafts a reply for someone to send is a genuinely different risk proposition from one that issues refunds unattended — and the difference has nothing to do with the model.

Testing means trying to break your own agent

The seventh item, adversarial testing and attack simulations, is the one most often skipped because it has no obvious finish line. A workable version is narrower than it sounds: for every source your agent consumes — web pages, uploaded documents, tickets, emails — feed it content containing instructions, and check what the agent did, not what it said.

That distinction is the whole test. A model that politely refuses and then calls the tool anyway has failed. A model that produces an alarming-sounding reply while touching nothing has not. Logging tool calls, not just completions, is what makes the difference visible — and it is the cheapest instrumentation you can add before an agent goes anywhere near production.

What to take from the OWASP admission

If prompt injection had a clean fix, the sensible plan would be to apply the fix and move on. It does not, so the sensible plan is different: assume occasional success, design so that success is boring, and instrument so you can tell. That is a less satisfying answer than a filter, and it is the one the evidence supports.

It also happens to be good engineering regardless. Least privilege, validated output formats, human review on irreversible actions and adversarial testing were sound practice before language models existed. The novelty is not the controls. It is that a system which reads text can now be argued with — and that the argument arrives through the same door as the data.

Frequently asked questions

What is prompt injection, in one sentence?

It is when text that reaches a language model changes its behaviour in ways you did not intend. OWASP classifies it as LLM01 in its Top 10 for LLM Applications, and splits it in two: direct prompt injection, where a user's prompt input directly alters the behavior of the model in unintended or unexpected ways, and indirect prompt injection, where an LLM accepts input from external sources, such as websites or files, and that content changes its behaviour. Both can be deliberate or accidental.

Why can't you just tell the model to ignore malicious instructions?

Because the instruction you write and the instruction an attacker writes arrive as the same kind of thing: text. There is no channel that carries authority. Constraining behaviour through system prompts is a real mitigation and OWASP lists it first, but it raises the cost of an attack rather than closing the door. OWASP is explicit on the limit: given the stochastic influence at the heart of the way models work, it is unclear if there are fool-proof methods of prevention for prompt injection.

What is the difference between direct and indirect injection in practice?

Direct injection is someone typing into your chat box. You can see that traffic and you can rate-limit it. Indirect injection is the one that surprises teams: your agent fetches a web page, reads a PDF a customer uploaded, or summarises a support ticket, and instructions hidden in that content are read as if they came from you. The attacker never touches your interface. Any agent that browses, reads files or ingests third-party data has this exposure by construction.

What does OWASP actually recommend?

Seven strategies, and none of them is a product you buy. Constrain model behavior through system prompts. Define and validate expected output formats. Implement input and output filtering. Enforce privilege control and least privilege access. Require human approval for high-risk actions. Segregate and identify external content. Conduct adversarial testing and attack simulations. Read as a set, they describe an architecture, not a filter: assume the model can be talked into something, and make sure the thing it can be talked into is not expensive.

Does this mean we should not deploy AI agents?

No, and treating it that way misreads the risk. It means the blast radius matters more than the prompt. An agent that drafts a reply for a human to send is a different proposition from one that issues refunds unattended. The two OWASP items that change the most are privilege control and human approval for high-risk actions, because they hold even when the injection succeeds. Deploy the agent; decide first what it is allowed to do alone.

How would we test for it?

OWASP names adversarial testing and attack simulations as one of the seven strategies, which is a polite way of saying that you have to try to break your own agent before someone else does. In practice that means feeding it content that contains instructions, from every source it consumes, and checking not whether it refuses but whether anything irreversible happened. A test that only checks the model's reply misses the point: what matters is what the agent did.

The LLM01:2025 designation, the definitions of direct and indirect prompt injection, the seven mitigation strategies and the statement that it is unclear whether fool-proof prevention exists are all taken from the OWASP Gen AI Security Project's page on prompt injection, checked at the time of writing. We have not conducted our own adversarial testing programme and make no claim to measurements of our own here.

ZAX Support for AI Agents

We build AI agents for businesses, which means we spend most of the design time on exactly this question: what the agent is allowed to do alone, and what needs a person. Privilege scoping, tool-call logging and human-approval gates are part of the build, not an afterthought.

Audit and scoping. A free 30-minute AI audit looks at what your agent can currently reach, and what would happen if it were talked into using it.