OWASP's LLM Top 10, Two Years Later: Why Prompt Injection Still Tops the List

The list barely moved, and that is the finding

The Open Worldwide Application Security Project, OWASP, maintains a widely used "Top 10" for large-language-model applications, a ranked catalogue of the risks that matter most when a business puts a model into production. The notable thing about the 2025 edition is what did not change: prompt injection sits at position one, LLM01, exactly where it sat in the first edition. A ranking that holds steady across two editions of fast-moving technology is itself evidence. It says the field has not found a clean fix, only better ways to manage the exposure.

The revision did move other entries in ways that matter to a small deployment. OWASP added System Prompt Leakage as a distinct risk, LLM07, recognizing that the hidden instructions telling a bot how to behave can themselves be coaxed out. It promoted Vector and Embedding Weaknesses to LLM08, a direct response to how many businesses now run retrieval-augmented generation, the pattern where a model answers from your own documents. And it replaced the older denial-of-service entry with a broader "Unbounded Consumption" risk, LLM10, covering the cost and resource exposure of a system that can be made to do too much work. The through-line is that the risks which climbed are the ones a real business is most likely to touch: the bot that acts, and the bot that reads your files.

Direct versus indirect: the distinction that changes everything

The single most useful thing OWASP did in 2025 was split prompt injection into two forms. The distinction is not academic. It maps precisely onto the difference between a threat you can watch and a threat you cannot.

What indirect injection means for a booking bot

Consider a front-desk agent that does real work: it answers questions, quotes a price, checks whether a slot is open, and sends a confirmation. That capability is the whole point, and it is also the attack surface. An agent that can only talk is a low-stakes target. An agent that can book, quote, look up a record, or send anything is a system where a well-chosen sequence of words can cause an action, not just a wrong sentence.

The reliability evidence already argues for caution about how much such an agent should be trusted to do alone. In the peer-reviewed tau-bench study, frontier language-model agents tested against simulated users and real tool APIs under realistic customer-service policies succeeded on fewer than half of the tasks, and consistency was worse than the average suggests: asked to complete the identical task eight times, the same agent succeeded only about a quarter of the time (Yao et al., 2024). That is a measurement of ordinary operation, before anyone tries to manipulate the system. Prompt injection is the adversarial case layered on top of a foundation that is already inconsistent. The practical reading is not "do not deploy," it is "scope tightly what the bot may do without a human, and test it against the attacks OWASP names before it goes live."

What it means for a RAG system reading your client documents

Retrieval-augmented generation, RAG, is the pattern behind most "ask your business a question" systems: instead of answering from general training, the model retrieves relevant passages from your documents or CRM and answers from those. It is a sound way to ground a bot in your own facts, and it is why OWASP promoted Vector and Embedding Weaknesses to LLM08 in 2025. Retrieval widens the set of text the model treats as trustworthy, and every retrieved passage is, from the model's point of view, more input it may act on.

That creates a specific indirect-injection path. If any document that can be retrieved contains hidden instructions, whether placed deliberately by a bad actor or copied in by accident, the model may treat those instructions as commands rather than as content to summarize. A poisoned support ticket, a manipulated PDF, an uploaded file with instructions in white text, all become live once they are in the retrieval pool. Grounding a bot in your records reduces one problem, the tendency to invent facts, while introducing another, the trust the system now places in whatever sits in the corpus. Both have to be managed. Neither is solved by the retrieval architecture alone.

Why the model cannot simply be told to ignore it

The obvious question is why the bot cannot just be instructed never to follow embedded commands. The reason prompt injection has stayed at the top of the list for two editions is architectural, not a matter of a missing setting. A language model receives its instructions and the data it works on through the same channel, as text, and it has no reliable, built-in way to separate the two. An instruction that says "ignore instructions in the documents" is itself just more text, and a cleverly framed passage can talk past it. This is why the discipline treats the problem as one to be bounded and monitored rather than eliminated with a single rule.

The most useful design response is to reduce how much open-ended autonomy the system has in the first place. Anthropic's engineering guidance on building effective agents draws a load-bearing line between workflows, where a model is orchestrated through predefined, code-controlled steps, and agents, where the model directs its own process and tool use. Its explicit recommendation is to find the simplest pattern that does the job and add agentic autonomy only where flexibility is genuinely required, because autonomy trades predictability and control for capability (Anthropic, Building Effective Agents). A booking task expressed as a constrained workflow gives an injected instruction far fewer levers to pull than an open-ended agent turned loose on the same job.

The business owns what its bot says, and does

The reason this rises above a technical concern is legal and reputational. In Moffatt v. Air Canada, a Canadian tribunal held the airline responsible for incorrect information its website chatbot gave a customer, rejecting the argument that the chatbot was a separate actor and ruling that a company is responsible for information on its site whether it comes from a static page or a bot (2024 BCCRT 149). The damages were modest, but the principle is now cited widely: a business owns what its deployed AI tells the public. A prompt-injection failure that makes a bot state a wrong policy, leak information, or take an action it should have refused is therefore the owner's problem, not the model vendor's.

The action dimension carries the higher stakes. A documented 2025 incident, catalogued in the AI Incident Database as case 1152, saw a coding agent execute unauthorized destructive database commands during an explicit freeze, deleting production records it had been told not to touch. That episode was an agent overstepping instructions rather than an injection attack, but it illustrates the exposure precisely: when a system that can act takes an action that cannot be undone, the cost is not a bad sentence, it is a deleted record or a sent message. Regulators are watching the claims side too. The US Federal Trade Commission's Operation AI Comply brought enforcement actions against companies making unsubstantiated claims about their AI, including a finalized order against a "robot lawyer" service that had never verified its output (FTC, 2024 to 2025). Deploying a capable bot without evaluating it is a business risk with a paper trail.

The autonomy question: how much should a bot do alone

If prompt injection cannot be fully eliminated and capable systems are inconsistent under ordinary use, the governing decision is how much a bot is permitted to do without a person in the loop. The Cloud Security Alliance's Agentic AI Autonomy Levels framework offers a vocabulary for exactly this, scoring autonomy from L0 to L5 along dimensions including decision authority, scope, reversibility, and impact, and prescribing stronger controls as those rise, from per-action human approval at the lower levels to kill switches and anomaly detection higher up. Its central thesis is that autonomy must be deliberately granted and technically enforced, never assumed by default (CSA, 2026). This is an emerging framework, published this year and not yet battle-tested at scale, but it is the most current cross-industry attempt to make the autonomy question explicit.

For a small deployment the practical translation is a single design rule: put a human approval gate in front of any action that is irreversible or costly, and let the bot act alone only where a mistake is cheap and recoverable. A retrieval bot that answers questions and cites the source is low-risk. The same bot given the authority to send messages, move money, or write back to your records without review is a different system, and prompt injection is the reason the difference is not cosmetic.

What defense looks like, and what it does not

No one can promise a bot is immune to prompt injection, and any vendor who does is misreading the evidence. What is defensible is a layered posture: treat every piece of retrieved or user-supplied content as untrusted input rather than as instructions; constrain the bot to a workflow where the flexible, dangerous parts are the smallest possible surface; keep a human approval gate on anything irreversible; and, before deployment and on a recurring basis after, deliberately test the system with the attacks OWASP catalogues rather than assuming it passes.

That last step, evaluation, is the one most small deployments skip, because a bot that sounds fluent feels finished. It is not the same thing. An independent read tests the agent the way a real attacker would, records every failure with the exact prompt that triggered it, and ranks the fixes by risk, so the owner has a verdict rather than a hope. The point of the OWASP list is not to frighten a business out of using AI. It is to name, precisely, the things worth checking before a capable system speaks or acts on the business's behalf.