What is the OWASP LLM Top 10?
By Identra · Updated
The OWASP LLM Top 10 is an awareness guide to security risks in applications built with large language models. It helps security teams examine how an application's instructions, data access, tools and outputs could cause harm and decide where controls belong.
What is the OWASP LLM Top 10 used for?
An LLM app is more than the model. It's the retrieval layer, the connected accounts, the plugins and whatever downstream code acts on the output. A model that refuses a bad request tells you little about the rest.
The list gives security and app teams shared words for those parts. Use it to structure threat models, vendor questionnaires and test plans. The order is OWASP's. Your own ranking should come from what data and actions your deployment exposes.
What are the OWASP LLM Top 10 categories?
These are from the OWASP 2025 edition. Names and numbers can shift between editions, so write the edition into every assessment.
LLM01: Prompt Injection
- What goes wrong
- Untrusted text redirects what the app does.
LLM02: Sensitive Information Disclosure
- What goes wrong
- Responses expose confidential or restricted data.
LLM03: Supply Chain
- What goes wrong
- A model, dataset or package brings in a compromise.
LLM04: Data and Model Poisoning
- What goes wrong
- Tampered data or models change intended behavior.
LLM05: Improper Output Handling
- What goes wrong
- Downstream code trusts generated output without validating it.
LLM06: Excessive Agency
- What goes wrong
- Too many functions, permissions or autonomy enable damage.
LLM07: System Prompt Leakage
- What goes wrong
- Exposed instructions reveal secrets or security assumptions.
LLM08: Vector and Embedding Weaknesses
- What goes wrong
- Retrieval flaws leak data or feed manipulated context.
LLM09: Misinformation
- What goes wrong
- Wrong output misleads people or business processes.
LLM10: Unbounded Consumption
- What goes wrong
- Runaway usage drives up cost or knocks over availability.
How do the categories show up in a real incident?
Usually several at once. Say a support assistant reads tickets and can send email. An attacker files a ticket telling it to find another customer's contract and mail it to an outside address. That's indirect prompt injection.
It only works if retrieval ignores which customer is asking and the email tool will send anywhere. So the same event is prompt injection, sensitive information disclosure and excessive agency. File it under one and you'll fix one.
The fix lives in two places. Check the user's access before documents are retrieved. Check again before anything goes out, with external sends tied to an approval that shows the real recipient. Test it with synthetic contracts and a mailbox you control.
Does the list apply to AI tools you buy?
Yes. The vendor writes the code. You still pick the users, the connected data, the permissions and the allowed uses. Turning on Microsoft 365 Copilot over a SharePoint tenant with loose sharing is an application security decision, even if nobody wrote a line of code. So is a business team building an agent in Copilot Studio with write access to a CRM.
Ask vendors about your configuration specifically. How does retrieval enforce permissions? What can each connector touch? Can you investigate what the assistant did?
Employee behavior sits next to all this. Someone pasting a contract into a personal chatbot is an AI data leakage problem. It isn't an app vulnerability.
Which controls map to the biggest risks?
Pick one workflow and list its users, sources, dependencies, identities, actions and output destinations. Put each control where it can actually enforce something. A system prompt shouldn't be the only thing guarding confidential data or privileged actions.
- Retrieval: enforce document permissions before content enters the context, and test tenant separation and access revocation.
- Agency: least privilege for connected identities, separate read from write, restrict destinations, approve consequential actions.
- Output: treat it as untrusted input. Validate tool arguments, encode for the destination and never pipe generated commands straight to a shell.
- Supply chain: check where models, datasets and packages come from, and pin reviewed versions.
- Consumption: set request, concurrency and spend limits, with a way to kill runaway jobs.
How do you prove the controls work?
A checklist shows you looked. It doesn't show anything holds. For each material risk, write the test, the expected result, the owner and what actually happened.
For RAG security, try to pull another team's restricted document, then revoke someone's access and see if retrieval notices. For insecure AI output handling, check whether generated HTML or shell commands reach an execution context unvalidated.
AI red teaming finds the combinations a checklist misses. Keep the good cases as repeatable tests and rerun them when models, sources, tools or permissions change.
How Identra thinks about it
Identra addresses parts of this list where enterprise AI is used rather than built. Prompts and uploads are checked on the device before they are sent, which helps limit sensitive information disclosure to AI apps. AI agent tool calls on endpoints are checked against policy, and destructive shell commands can be denied, which helps contain excessive agency. An inventory of MCP servers, skills, plugins and browser extensions supports supply chain review.
Go deeper: AI security, built on identity
Frequently asked questions
Is the OWASP LLM Top 10 a certification?
No. It's an awareness resource. Mapping controls to it doesn't certify an app or prove regulatory compliance.
Which edition should an assessment use?
Name the edition and stick to its category names. When you update an old assessment, recheck the mappings. Identifiers can mean different things across editions.
Can a prompt filter address every category?
No. A filter can't verify dependencies, enforce document permissions or authorize downstream actions. Those controls belong in the systems that own them.
Is system prompt leakage always a data breach?
No. It depends on what the prompt contains and whether the app relies on keeping it secret.
Can the list replace ordinary application security testing?
No. LLM apps still need authentication, authorization, secure config and normal appsec testing. The list adds AI-specific cases on top.