The OWASP Top 10 for LLM Applications (and its agentic sibling)

Where ATLAS describes how an attacker moves, the OWASP Top 10 for Large Language Model Applications describes what is weak. It is maintained by the OWASP GenAI Security Project, and its current edition on the project site is the 2025 list. It is a ranked catalogue of vulnerability categories, which makes it the most practical checklist for anyone building or testing an application around an LLM. It is a list of categories, not a test method: each entry still has to be turned into concrete tests for your system.

The 2025 list

Prompt injection: the entry to know best

OWASP defines a prompt injection vulnerability as one where user prompts alter the model’s behaviour or output in unintended ways, even through inputs that are imperceptible to humans, as long as the model parses them. It distinguishes two forms. Direct injection comes from the user’s own input. Indirect injection arrives through external content such as websites or files that the model is asked to process. Jailbreaking is described as a form of prompt injection in which the input makes the model disregard its safety protocols entirely.

Two statements from OWASP shape how you test. First, retrieval-augmented generation and fine-tuning make outputs more relevant, but research shows they do not fully mitigate prompt injection. Second, because of how models work, “it is unclear if there are fool-proof methods of prevention”, so the aim is to limit impact. Its listed measures include:

• constrain model behaviour and validate expected output formats with deterministic code;
• apply input and output filtering;
• enforce least privilege, giving the application its own API tokens and handling those functions in code rather than handing them to the model;
• require human approval for high-risk actions;
• segregate and identify external content so untrusted material has less influence;
• run adversarial testing and attack simulations, treating the model as an untrusted user to test trust boundaries and access controls.

The last item is the bridge to red teaming. OWASP’s own example scenarios include a support chatbot told to ignore its guidelines and send emails, a summariser that follows hidden instructions on a web page and leaks the conversation through an image URL, and a modified document in a retrieval repository that changes the model’s output. Each is a ready-made test case.

Excessive agency: when the model can act

OWASP says Excessive Agency occurs when an LLM-based system performs damaging actions in response to unexpected, ambiguous or manipulated model output, once developers let it call functions or use extensions. It names three root causes: excessive functionality (tools that do more than the application needs), excessive permissions (broader access rights than necessary) and excessive autonomy (no verification or approval for high-impact actions). The mitigations follow the causes: minimise extensions and their functions, avoid open-ended tools such as shell execution, run actions in the user’s context with minimal privileges, require human approval for significant actions, and enforce authorisation in downstream systems instead of relying on the model’s judgement.

That last point is the most testable claim in the whole list. A tester can ask, for every tool the model can call: if the model were fully controlled by an attacker, what is the worst thing this tool could do, and would any system outside the model stop it?

The agentic sibling

OWASP has also published a separate OWASP Top 10 for Agentic Applications for 2026, dated 9 December 2025. The project describes it as a globally peer-reviewed framework identifying the most critical security risks facing autonomous and agentic AI systems, developed with over 100 industry experts. If your system plans multi-step tasks, calls tools or coordinates with other agents, read that document alongside the LLM list. This lesson does not reproduce its ten entries, so read the official document directly before you rely on it.