The OWASP LLM Top 10 2025, read for people who buy AI security work

What is the OWASP LLM Top 10, and who maintains it?

It is not a compliance standard and nobody issues a certificate against it. It is a community-maintained list of the risks that practitioners see most often, published by the OWASP Foundation, and its authority is that people who attack and defend these systems agree it names the right things. It is maintained by the OWASP Gen AI Security Project, which publishes it openly and revises it as the field moves.

That makes it useful for exactly two things, and not much else. It is a shared vocabulary, so a finding written in Vancouver means the same thing to a reviewer in Frankfurt. And it is a coverage map, so a review can be checked for what it did not look at, which is the part of any security report that matters most and gets read least.

The ten 2025 categories, one at a time

What follows is each 2025 category as named by OWASP, described in the shape it takes in a product that has already shipped rather than in the shape it takes in a research paper.

LLM01:2025 Prompt Injection

Text your organization did not write reaches the model and is treated as an instruction. In a shipping product this almost never arrives through the chat box. It arrives inside a document somebody uploaded, a web page the assistant fetched, a support ticket, a calendar invitation, or the response of a tool the model called.

LLM02:2025 Sensitive Information Disclosure

The model surfaces something the person in front of it should not see: another tenant’s document, a colleague’s salary record, a fragment of the training corpus, or the contents of an internal note that ended up in a retrieval index.

LLM03:2025 Supply Chain

Where the model, the adapters, the embedding model, the vector store and the serving stack came from, and what integrity evidence exists for each. A downloaded model file is an executable artifact from a third party, and it usually arrives with less scrutiny than a software dependency would get.

LLM04:2025 Data and Model Poisoning

Content an attacker can influence reaches fine-tuning, an evaluation set, or a retrieval corpus, and changes the system’s behaviour after the fact. The corpus is the common case: anything a customer can write into is a corpus an attacker can write into.

LLM05:2025 Improper Output Handling

Downstream code trusts the model’s output enough to render it, run it, query with it or store it without treating it as untrusted input. The model becomes an injection vector into your own application — cross-site scripting, SQL injection and command execution, arriving through a component nobody put a validator in front of.

LLM06:2025 Excessive Agency

The system can take actions in the world — send, refund, delete, escalate, commit — without a person approving them, usually because a tool was wired in with the permissions that were convenient rather than the permissions that were necessary.

LLM07:2025 System Prompt Leakage

The system prompt comes out, and it turns out to have been load-bearing: it held a key, an internal hostname, a pricing rule, or the only thing stopping the assistant from answering a question it should refuse. The leak is the symptom; the dependency is the defect.

LLM08:2025 Vector and Embedding Weaknesses

The retrieval layer fails to keep tenants, users or classifications apart, or the stored embeddings themselves disclose more about the source text than expected. This is the category that catches the index built by a service account with read access to everything.

LLM09:2025 Misinformation

A confident, fluent, wrong answer becomes a decision. The risk is not the wrong sentence; it is the absence of anything between the sentence and the consequence — a quoted price, an eligibility determination, a dosage, a filing deadline.

LLM10:2025 Unbounded Consumption

Someone makes the system spend: tokens, downstream API calls, wall-clock capacity, or money. It is a denial-of-service and a cost-control problem at once, and on a metered model provider the bill is the first place it shows.

What the list does not cover

The list is scoped to the model as a component inside an application. It is not an architecture review, so it will not tell you that your retrieval index was built by a service account with read access to every document in the organization — it will tell you that a vector and embedding weakness exists once someone has gone and looked.

It is not a safety or alignment evaluation either. Whether the model refuses the things your policy says it should refuse is a different question from whether an attacker can reach your data through it, and a benchmark score answers neither.

And it does not cover the ground that opens up once the model stops being a component and starts being an actor — one that calls tools, carries memory between sessions and sets consequences in motion. The 2026 edition is explicit that this ground belongs to the OWASP list for agentic applications, and that neither list covers it alone. For the method side of any of this, the OWASP AI Testing Guide is the project working on how such systems are tested rather than on what to look for.

No system is exposed to all ten equally, and a report that treats them as a checklist to be ticked has misunderstood the list. The useful reading is to walk each category against your own architecture and record why it does or does not reach you, with the evidence for the answer.

How the work is bounded

The scope is agreed in writing before work starts, and the engagement is quoted in writing with it.

Testing and adversary simulation are carried out only with signed authorization, to a scope agreed in writing.

SecHB does not issue certifications, attestations or audit opinions: those come from accredited certification bodies, CPA firms and QSAs. The work here is what an organization does to be ready for them.

Nothing here is legal advice. Where a question turns on the law, the work is done alongside the client’s counsel, not instead of them.