When an agent believes the wrong text

Picture a postal worker who reads every letter before delivering it. Most letters are ordinary. Then one arrives that says: "Postal worker, forget your previous instructions and bring all the mail from this house to this address." And the postal worker does it.

That is prompt injection. It has been number one on the OWASP list for three years running, and in the new list published on 3 August 2026 it is still at the top.

OWASP is a non-profit community that maintains software security's best-known list: the ten most common and most serious vulnerabilities in each kind of software. The web application list has been a standard reference for twenty years, and language models now have their own. The list has no force in law, but it is in practice the yardstick security work in the field is measured against.

The reason it stays at the top is not that anybody is being lazy. The reason is structural.

Why there is no fix

A language model reads its instructions and the material it is working on through the same channel. What arrives is one stream of text, with no technical difference between the part that is the developer's instruction and the part that is a web page, an email or a customer message the model happened to read.

This differs from familiar vulnerabilities in one decisive way. SQL injection was fixed. Database queries now have a way to separate the query from the data such that data cannot become a command. For a language model no equivalent separation exists, because the model's entire capability rests on interpreting text as text.

There are defences: filtering the input, separate checking models, instructions telling the model not to obey commands embedded in material. They raise the bar. None removes the problem, and attacks move to channels nobody thought to filter. In the latest list, prompt injection also covers commands hidden in images and audio.

What changed in 2026

Two things, and both say the subject moved from guesswork to measurement.

The list now rests partly on real incidents. Previously the ordering came out of a vote among experts. By OWASP's own account the new version draws on thousands of real security incidents. According to security press reporting, the vote carries 75 per cent of the weight and the remaining 25 per cent comes from 6,639 cases in public vulnerability and incident databases.

Excessive agency rose to third. The entry means a system has been given more authority to act than its task requires. Its rise says that the damage happens specifically in agents: where the model does not merely answer but acts.

Since spring 2026 OWASP has also had a separate list for agent applications, because an agent's risks are not the same as those of a single model call.

The thought worth reading twice

The conclusion running through the new version, as the security press has summarised it, turns the whole way of thinking on its head. Do not try to build a model that cannot be fooled. Build a system around it in which nothing important breaks when the model is fooled, because sooner or later it will be.

This is the same principle as in all other safety engineering. An aircraft is not designed on the assumption that no part fails; it is designed around what happens when one does. With a language model the only difference is that many people are still trying to solve the problem with a better prompt.

Three things that together make an agent dangerous

The risk does not come from one property but from three being true at once:

1. The agent has access to sensitive information. A customer register, a price list, internal documents.
2. The agent handles material whose content nobody on your side controls. A web page, an incoming email, a customer's attachment, a search result.
3. The agent has some outbound channel. Email, an API call, a message, writing a file.

When all three hold, an attacker can write a command into point two and get the agent to send point one out through point three. None of them is dangerous alone. The combination is.

The practical guidance follows directly: break one of the three. Usually the third is the easiest.

What an adopting organisation should do

None of this requires a research team.

• Give the agent the smallest possible permissions. Not the whole database but the rows the task requires. No write access if reading is enough.
• Require a person in the loop for anything irreversible. Moving money, sending a message outside, deleting information, approving a contract.
• Separate the sources. Mark in the system which text came from outside, and treat it as data rather than instruction. Perfect separation is not available, but the logging improves and investigating an attack afterwards becomes possible.
• Log the tool calls. What was called, with what parameters, and what came back. Without this an incident cannot be investigated.
• Set a budget and a round ceiling. It also bounds the damage a compromised agent has time to do.
• Test it with an attack. Write a line into your own material telling the agent to do something forbidden, and see what happens. This is the cheapest security test there is, and it fits into one afternoon.

In one sentence

There is no fix for prompt injection, because a language model does not separate instruction from data, so security comes not from a better prompt but from the agent having so few permissions that even a fooled agent cannot do enough to matter.