The OWASP Top 10 for Large Language Model Applications is the widely used reference list of the most critical security risks in software built on large language models. It is published and maintained by the Open Worldwide Application Security Project, the same volunteer organization behind the long-standing OWASP Top 10 for web applications.1 The list gives developers, security teams, and auditors a shared vocabulary for the ways AI applications fail. If you build, buy, or assess systems that use an LLM, it is the single most useful starting point for understanding what can go wrong and where to look first.
The list exists because LLM applications break in ways traditional application security checklists never anticipated. A model that follows instructions hidden in untrusted data, that can be talked past its own guardrails, or that can take real actions through connected tools introduces failure modes with no clean equivalent in a conventional web app. For a regulated company in finance, healthcare, or critical infrastructure, those failures are not abstract. They translate into data leakage, fraudulent transactions, and regulatory exposure under the GDPR, the EU AI Act, and DORA. The Top 10 is how you start to reason about that risk in a structured way.
What the OWASP LLM Top 10 is, and why it exists
The list is a curated set of the ten most critical security risks specific to applications built on large language models, compiled by a global group of security practitioners and updated as the technology and the attacks against it evolve.1 It is not a standard you certify against, the way you certify against ISO/IEC 27001. It is a reference that informs how AI applications should be designed, built, and tested. Security teams use it to scope work, developers use it to avoid common mistakes, and assessors use it as a baseline for what an AI application should defend against.
It exists because the classic OWASP Top 10 for web applications, while still relevant to the surrounding system, does not describe the new attack surface a model introduces. Risks like prompt injection and excessive agency simply have no row in the old list. The LLM Top 10 fills that gap without throwing away decades of application security knowledge. The smartest way to read it is as an extension of classic app security, not a replacement for it.
The ten risks, with defenses
The table below walks the full list. The names and groupings follow the current OWASP edition, which consolidated some earlier 2023 categories. Where a 2023 risk such as model denial of service, insecure plugin design, overreliance, or model theft no longer appears under its old name, the underlying concern still lives inside one of the current entries, noted in the description.
| Risk | What it means | How you defend against it |
|---|---|---|
| Prompt injection | User or external input manipulates the model into ignoring its instructions. Indirect injection hides the payload in a document, web page, or email the model later reads. | Treat all input as untrusted, separate trusted instructions from untrusted content, and enforce limits in code outside the model. |
| Sensitive information disclosure | The model reveals secrets, training data, system prompts, or one user's data to another. | Minimize what the model can access, filter inputs and outputs, and never place secrets where the model can reach them. |
| Supply chain | Compromised models, datasets, plugins, or dependencies introduce risk before the app even runs. This is the home for model theft and tampered third-party components. | Vet model and dataset provenance, pin and verify dependencies, and govern third-party AI as you would any external code. |
| Data and model poisoning | Training, fine-tuning, or retrieved data is corrupted to change behavior or plant a backdoor. | Control data sources, validate and version datasets, and test the model for poisoned or backdoored behavior. |
| Improper output handling | Downstream systems trust model output blindly. This is the modern form of insecure plugin design, where unchecked output drives code, SQL, or shell commands. | Validate and encode model output before any system or browser acts on it, exactly as you would user input. |
| Excessive agency | The model can take actions, call tools, or access systems beyond what is safe, so manipulation causes disproportionate harm. | Grant least privilege to tools and connectors, require human approval for high-impact actions, and scope every integration tightly. |
| System prompt leakage | The model's hidden instructions are extracted, often as the first step toward a larger attack. | Assume the system prompt will leak, keep no secrets or access decisions inside it, and enforce authorization in code. |
| Vector and embedding weaknesses | The retrieval layer of a RAG system is attacked through poisoned documents or cross-tenant embedding access. | Isolate tenants in the vector store, control what enters the index, and treat retrieved content as untrusted input. |
| Misinformation | The model produces confident but false output that users act on. This absorbs the earlier overreliance category. | Ground answers in verified sources, surface uncertainty, and keep humans in the loop for consequential decisions. |
| Unbounded consumption | Uncontrolled use drives runaway cost or denial of service. This covers the earlier model denial of service, sometimes called denial of wallet. | Rate-limit, cap token spend, monitor usage, and alert on anomalous consumption patterns. |
The OWASP LLM Top 10 is not a checklist to tick once. It is a map of where AI applications break, and most of those failures have no equivalent in traditional app security.
Which risks are most dangerous in practice
On paper all ten matter. In real engagements, a few cause most of the serious damage. Prompt injection is first for a reason. It is the defining LLM risk, and there is no complete fix, only mitigation, because the model cannot reliably tell trusted instructions apart from untrusted content in the same context window. We treat it as a permanent design constraint, not a bug to patch, a point we develop in prompt injection is not a prompt problem.
Excessive agency is the second risk that turns a nuisance into an incident. A model that can only generate text is limited in the harm it can do. A model wired to send email, move money, query a production database, or call internal APIs is not. The more autonomy and tool access you give an agent, the more an injection or a hallucination can hurt you. This is why agent design is a security decision, covered in securing AI agents.
Improper output handling rounds out the dangerous three. It is the bridge between the model's world and your classic attack surface. If your application takes model output and feeds it into a SQL query, a shell command, or a web page without validation, you have recreated injection and cross-site scripting through a new door. The vulnerability is old. The entry point is new.
How LLM applications are tested
Testing against the Top 10 is not a scan you run once. The most damaging attacks chain several risks together, so testing has to pursue realistic attack paths rather than check each item in isolation. A typical chain looks like this: an indirect prompt injection hidden in a poisoned document, retrieved through a weak embedding layer, that steers an over-permissioned agent, whose output is then trusted downstream. Treating the list as ten separate boxes misses how attackers actually operate.
- 01Scope the application, not just the modelMap every input the model reads, every tool it can call, every system that trusts its output, and the data it can reach. The attack surface is the whole application, not the prompt.
- 02Map the engagement to the Top 10Use the list to make sure no major risk class is skipped, from prompt injection through unbounded consumption, while keeping the focus on the risks that matter for this specific app.
- 03Pursue realistic attack chainsCombine injection, retrieval, agency, and output handling into the multi-step attacks an adversary would actually run. This is the difference between a checklist scan and genuine AI red teaming.
- 04Test the controls, not just the modelVerify that limits live in code outside the model, that tools enforce least privilege, and that output is validated before any system acts on it.
- 05Produce evidence and retestDocument findings, attack paths, and fixes in a form you can use for governance and audit, then retest after remediation.
How LLM applications are defended
Most of the list resolves to a small number of durable principles, applied across the whole application rather than the model alone. None of them is exotic. They are the same defense-in-depth ideas that have always worked in application security, adapted to a component that processes untrusted natural language and can act on it.
- Treat everything the model processes, including retrieved documents and tool output, as untrusted input.
- Put security controls outside the model, in code the attacker cannot reach, never in the prompt.
- Constrain the model's capability and access so that manipulation cannot cause disproportionate harm.
- Validate model output before any downstream system, browser, or user acts on it.
- Govern the supply chain of models, datasets, and dependencies as you would any third-party code.
- Log and monitor usage so abuse can be detected, rate-limited, and investigated.
- Test against realistic attack chains, mapping to the Top 10 but pursuing the paths attackers actually use.
These principles connect AI security directly back to classic application security, and we cover the broader picture in securing LLM applications.
The link to classic application security
The most useful way to read the LLM Top 10 is alongside the original OWASP Top 10 for web applications, not instead of it. An LLM application is still a web application. It has authentication, session management, access control, dependencies, and infrastructure, all of which can fail in the classic ways. The model adds a new and dangerous layer on top. If you secure only the model and forget the surrounding app, or secure the app and ignore the model, you have a gap an attacker will find.
This is why a serious assessment covers both lists. Improper output handling is just injection wearing a new hat. Excessive agency is broken access control reframed for tools. Supply chain risk is the same dependency problem the web Top 10 has flagged for years. The vocabulary is new because the entry points are new, but the underlying engineering discipline is continuous with everything good application security teams already know.
OWASP, regulation, and governance
The OWASP LLM Top 10 is a technical reference, and it dovetails with governance and regulation. The EU AI Act's robustness and cybersecurity requirements and the NIST AI Risk Management Framework both expect AI systems to be tested against realistic threats.2 The Top 10 is a practical basis for that testing. Mapping your testing to the list produces evidence you can use in AI governance and toward EU AI Act obligations, and it complements management-system work under ISO 42001.
How Raptoric helps
We test AI applications against the full OWASP LLM Top 10 and the realistic attack chains it describes, as an independent firm with no model or platform to sell you. That means scoping the whole application, mapping coverage to the list, and pursuing the multi-step attacks that cause real incidents, then handing you findings and evidence you can use for remediation and audit. To have your LLM applications assessed properly, see our AI security service and book a scoping call.