The OWASP Top 10 for LLM applications in plain language

The OWASP Top 10 for LLM applications is a list of the 10 most important security risks in software built on large language models. It is written for people who build and secure those applications, but it also works as a checklist when you buy an AI tool. This guide explains each entry in plain language, gives an everyday example, and suggests one question to ask a vendor or developer.

What the list is and who publishes it

The OWASP GenAI Security Project publishes the list. Its audience is the people who build and secure applications based on large language models (LLMs), the kind of model behind chatbots, writing assistants and document search tools.

The current version is the 2025 edition. Its full title is “2025 Top 10 Risk & Mitigations for LLMs and Gen AI Apps.” An earlier 2023-24 edition also exists, with a version dated April 11, 2024. Translations of the 2025 list are dated March 12, 2025 and July 22, 2025. If you see older material that uses different names or a different order, it is probably based on the earlier edition.

Each entry has an id such as LLM01:2025. The number gives the entry’s position in the list, and the year names the edition. For a short definition you can share with colleagues, see our glossary entry on the OWASP Top 10 for LLM applications.

Why it matters to a small organization

You may never train a model, but you probably connect one to something that matters: a shared inbox, a file drive, a donor database or a public website chat. Most of the risks on this list come from that connection, not from the model on its own.

The list gives you a common vocabulary for LLM security risks. When a vendor says their assistant is “secure,” you can ask which of the 10 entries they test for and what they do about each one. That conversation is far more useful than a general promise. If you want background before going further, our guide to LLM security basics covers the core ideas.

The 10 risks in the 2025 edition

Each entry below has three parts: what it means, an example of how it could show up in a small organization, and one question to ask.

LLM01:2025 Prompt Injection

What it means: someone writes text that makes the model follow their instructions instead of the ones it was given. The text can be typed straight into the chat, or hidden in a web page, email or document the model reads.

Example: an assistant that summarizes incoming email reads a message containing hidden text telling it to forward the last 10 messages to an outside address.

Ask: “What stops content the assistant reads from changing what it does?”

See our glossary entry on prompt injection and the longer guide on prompt injection for non-engineers.

LLM02:2025 Sensitive Information Disclosure

What it means: the application reveals personal data, confidential information or credentials that it should keep private.

Example: a staff chatbot connected to HR files answers a volunteer’s question with details from another person’s personnel record.

Ask: “Which data can the assistant reach, and how do you stop it from showing that data to the wrong person?”

More in our glossary entry on sensitive information disclosure.

LLM03:2025 Supply Chain

What it means: problems in the models, datasets, software libraries and plug-ins that the application is built from. A flaw in any of these parts becomes your flaw.

Example: a free plug-in added to a writing tool contains code that sends documents to an unknown server.

Ask: “Which outside models, libraries and plug-ins does this product depend on, and how do you check them?”

LLM04:2025 Data and Model Poisoning

What it means: someone tampers with the data used to train, fine-tune or feed the model, so it behaves the way the attacker wants.

Example: a search assistant built on a shared folder of policies gives wrong answers after someone quietly edits a few files in that folder.

Ask: “Who can change the data the model learns from or searches, and how would you notice a bad change?”

See our glossary entry on data poisoning.

LLM05:2025 Improper Output Handling

What it means: other systems use what the model produces without checking or cleaning it first. Anything an attacker slipped into the output can then travel onward into a web page, a database or a command.

Example: a website shows chatbot replies as raw web code, so a reply containing a malicious script runs in a visitor’s browser.

Ask: “What checks happen to the model’s output before another system uses it?”

Our glossary covers this under insecure output handling, an older name for the same idea.

LLM06:2025 Excessive Agency

What it means: the model can take more actions, with more permissions, than its job needs.

Example: an assistant meant to draft replies can also send email, delete files and change calendar entries, all under an administrator account.

Ask: “What can the assistant do on its own, and can we limit it to read-only access or require a person to approve actions?”

See our glossary entry on excessive agency.

LLM07:2025 System Prompt Leakage

What it means: the hidden instructions that set up the model’s behavior get exposed. This is a real problem when those instructions contain passwords, internal rules or other details that should stay private.

Example: a public chatbot’s setup text includes an internal discount code and an access key, and a visitor talks the bot into repeating it.

Ask: “Do the hidden instructions contain any secrets, and what happens if a user sees them?”

More on what a system prompt is in our glossary.

LLM08:2025 Vector and Embedding Weaknesses

What it means: flaws in how documents are stored and searched so the model can pull them into its answers. A common example is weak separation between different users’ data.

Example: two programs share one document search tool, and staff in one program get answers drawn from the other program’s confidential case notes.

Ask: “How do you keep each user’s or team’s documents separate in search?”

LLM09:2025 Misinformation

What it means: the model produces false or misleading content, and people act on it.

Example: a staff member sends a grant report with a legal requirement the model made up, and nobody checks it.

Ask: “How does the tool show where its answers come from, and what do you recommend for checking them?”

LLM10:2025 Unbounded Consumption

What it means: requests use up computing resources or money with no limit.

Example: a public chat widget gets flooded with long requests overnight, and the organization receives a much larger bill than usual.

Ask: “What limits exist on usage and spending, and who gets alerted when they are reached?”

How to use the list as a checklist

Treat the OWASP Top 10 for LLM applications as a checklist, both for tools you build and tools you buy.

1. List your AI tools. Write down every AI feature in use, including ones built into products you already pay for.
2. Note what each tool connects to. Email, files, databases, the public website and payment accounts all raise the stakes.
3. Go through the 10 entries for each tool. Mark each one as “applies,” “does not apply” or “unknown.” Unknowns become questions.
4. Send your questions to the vendor or developer. Ask which entries they test for and how. A clear, specific answer is a good sign. A vague one is worth noting.
5. Fix the easy items first. Reduce permissions, remove secrets from setup text, set spending limits and require a person to approve actions such as sending or deleting.
6. Repeat when something changes. A new connection, plug-in or data source is a good moment to go through the list again.

Where to focus first

If an assistant is connected to email, files or databases, give extra attention to three entries:

• Prompt Injection, because the assistant reads content that outsiders can write.
• Sensitive Information Disclosure, because it can reach private data.
• Excessive Agency, because it may be able to act, not only answer.

These three together cover the most common way things go wrong: an outsider’s text steers an assistant that has too much access into exposing data or taking an action.

What to watch for

A few patterns should make you slow down:

• A vendor that cannot say which of the 10 entries they have considered.
• An assistant that runs under an administrator or shared account.
• Passwords, keys or private rules placed in the setup instructions.
• Model output that goes straight into a website, spreadsheet formula or script without checks.
• No usage cap on a paid AI service that the public can reach.

None of these mean you must stop using a tool. They mean you should ask more questions and limit what the tool can reach until you get answers.

Frequently asked questions

Is the OWASP list a standard we have to comply with?

It is a list of risks and ways to reduce them, written for people who build and secure LLM applications. It is not a certification you pass or fail. Use it as a checklist, and if a contract or funder names it, follow what that document asks of you.

Which entries matter if we only use AI tools and do not build them?

Prompt Injection, Sensitive Information Disclosure and Excessive Agency matter most for assistants connected to your email, files or databases. Misinformation matters for anyone who relies on AI answers, and Unbounded Consumption matters if you pay by usage. The rest are mostly for your vendor to handle, but you can still ask about them.

How is it different from MITRE ATLAS?

They come from different publishers and are organized differently. The OWASP list groups risks into 10 categories aimed at people who build and secure LLM applications. Our glossary entry on MITRE ATLAS explains what that resource covers, so you can decide which one fits your task.

Where do prompt injection attacks come from in practice?

They can come from anyone who can type into the tool, or from any content the tool reads: emails, web pages, shared documents and uploaded files. Hidden text in a document is a common route because the person using the assistant never sees it. Our guide on prompt injection for non-engineers walks through examples.