The OWASP Top 10 for LLM Applications is a community-maintained list of the most critical security risks in software that uses large language models. The 2025 edition covers prompt injection, sensitive information disclosure, supply chain, data and model poisoning, improper output handling, excessive agency, system prompt leakage, vector and embedding weaknesses, misinformation and unbounded consumption.
- It is a separate list from the classic OWASP Top 10 for web applications. An LLM feature needs both.
- Prompt injection can't be fully prevented by prompt wording. Limit what a manipulated model is able to do.
- Treat model output as untrusted input to every system it touches.
- Excessive agency is the agent-era risk: narrow tools, least privilege and human approval for side effects.
- Retrieval needs access control at query time, or an assistant becomes a way around your permissions.
What is the OWASP Top 10 for LLM applications?
It is a project of the OWASP Gen AI Security Project, first published in 2023 and updated for 2025 in November 2024. It names the risks most likely to hurt applications built on LLMs: chatbots, retrieval systems, copilots and agents. Two entries are new in 2025, system prompt leakage and vector and embedding weaknesses, reflecting how many teams now build retrieval augmented generation (RAG) and agentic systems.
It complements, rather than replaces, broader frameworks such as the NIST AI Risk Management Framework, which covers governance and organisational risk. The OWASP list is the developer's checklist.
The 10 risks at a glance
| ID | Risk | In one line | First control to add |
|---|---|---|---|
| LLM01 | Prompt Injection | Input changes the model's behaviour against your intent, directly or via content it reads | Least-privilege tools and approval for side effects |
| LLM02 | Sensitive Information Disclosure | The model reveals personal, confidential or proprietary data | Keep secrets out of prompts; filter retrieval by user permissions |
| LLM03 | Supply Chain | Compromised or unvetted models, datasets, plugins or libraries | Pin and verify model and package sources |
| LLM04 | Data and Model Poisoning | Tampered training, fine-tuning or embedding data changes behaviour | Control and review data that feeds training and indexes |
| LLM05 | Improper Output Handling | Model output passed to other systems without validation | Validate and encode output like any untrusted input |
| LLM06 | Excessive Agency | An LLM is given more tools, permissions or autonomy than it needs | Narrow tools, scoped credentials, human checkpoints |
| LLM07 | System Prompt Leakage | Instructions or secrets in the system prompt are exposed | Never store secrets or access rules in prompts |
| LLM08 | Vector and Embedding Weaknesses | Weak access control or poisoning in RAG stores | Permission-aware retrieval; separate indexes per tenant |
| LLM09 | Misinformation | Confident but false output that people act on | Grounding, citations, evals and human review where it matters |
| LLM10 | Unbounded Consumption | Uncontrolled usage drives cost, outages or model extraction | Rate limits, quotas, token caps and spend alerts |
LLM01: Prompt injection
Direct prompt injection is a user typing instructions that override yours. Indirect injection is worse: instructions hidden in a web page, email, document or tool result that the model reads while doing its job. Because models process instructions and data in the same channel, no prompt phrasing reliably stops it.
- Design as if injection will sometimes succeed, and limit the blast radius: what can the model do if it obeys an attacker?
- Give tools the user's permissions, never a shared admin token.
- Require human confirmation for payments, deletions, outbound messages and other irreversible actions.
- Mark retrieved and tool content as data, and log every tool call for audit.
LLM02: Sensitive information disclosure
Models can repeat what is in their context: other customers' records pulled in by retrieval, secrets pasted into prompts, or personal data from training or fine-tuning sets. Filter what reaches the model by who is asking, minimise personal data in prompts and logs, and use zero-retention or private deployments when your data requires it.
LLM03 and LLM04: Supply chain, data and model poisoning
Open-weight models, adapters, datasets and LLM libraries are dependencies like any other, and can be tampered with. Download models from verified sources, pin versions, review licences, and scan the code and packages around the model as you would any service. For fine-tuning and RAG indexes, control who can add data and review what goes in: a few poisoned documents in a knowledge base can steer answers.
LLM05: Improper output handling
This is where LLM risk meets classic web security. If model output is rendered as HTML, run as SQL, passed to a shell or used to build a URL, an attacker who influences the output gets cross-site scripting, injection or server-side request forgery. Validate output against a schema, encode it for its destination, and never execute it directly. Static analysis of the surrounding code, the kind Caudilysis and other SAST tools do, helps catch the unsafe sinks; it does not test how the model itself behaves. See SAST vs DAST for where each kind of testing fits.
LLM06: Excessive agency
Agents call tools. The risk grows with each tool, permission and step of autonomy you grant. A support agent that only needs to read orders should not have a tool that can update any field on any record.
- Narrow tools: "refund this order up to the original amount", not "update order".
- Scoped credentials per user and per task, with short lifetimes.
- Budgets and stop conditions on steps, time and spend.
- Human-in-the-loop for high-impact actions, with the full context shown to the approver.
Our guide to MCP server development covers the same controls for tools exposed through the Model Context Protocol.
LLM07: System prompt leakage
Assume users can extract your system prompt. The risk is not the prompt text itself but what teams put in it: API keys, internal URLs, or rules like "only show admins the salary field" that should be enforced in code. Keep secrets in a secrets manager and access rules in your application.
LLM08: Vector and embedding weaknesses
RAG systems store chunks of your documents as embeddings. If retrieval ignores who is asking, any user can surface any document. In multi-tenant products, one tenant's data can leak into another's answers. Store access labels with every chunk and filter at query time, separate tenants' indexes where you can, and control who can write to the index.
LLM09: Misinformation
Models produce fluent, confident text whether or not it is true. The harm comes when people or systems act on it. Ground answers in retrieved sources, show citations, allow "I don't know", measure faithfulness with an evaluation set, and keep a person in the loop for legal, medical, financial or safety decisions. We cover evaluation in AI features that survive production.
LLM10: Unbounded consumption
Every request costs money and capacity. Without limits, a single user, a loop in an agent or a deliberate attack can run up a large bill or degrade service, and high-volume querying can be used to copy a model's behaviour. Set rate limits and quotas per user and key, cap input and output tokens, cap agent steps, and alert on spend.
A practical checklist for LLM features
- Threat-model the feature: what data it reads, what tools it can call, what happens if it is manipulated.
- Give the model and its tools the asking user's permissions, nothing more.
- Require human approval for actions with side effects.
- Validate and encode every model output before it reaches another system.
- Filter retrieval by access labels; isolate tenants.
- Keep secrets and authorisation rules out of prompts.
- Pin and verify models, datasets and libraries; scan the code around the model.
- Rate-limit, cap tokens and steps, and alert on spend.
- Log prompts, retrieved sources, tool calls and outputs (minus sensitive data) for audit.
- Run evals for quality and for known attack prompts on every change.
Frequently asked questions
What is the difference between the OWASP Top 10 and the OWASP Top 10 for LLM applications?
The classic OWASP Top 10 lists the most critical web application risks, such as broken access control and injection. The LLM list covers risks specific to applications that use large language models, such as prompt injection and excessive agency. An LLM-powered web app should be checked against both.
What is the number one risk for LLM applications?
Prompt injection is LLM01 in the 2025 list. It covers both direct attempts by users and indirect injection through content the model reads, such as web pages, documents and emails.
Can prompt injection be fully prevented?
Not with current models. Defences reduce it, but the reliable approach is to limit what a manipulated model can do: least-privilege tools, human approval for side effects, output validation and logging.
Does static analysis find LLM vulnerabilities?
Static analysis finds flaws in the code around the model, such as unsafe handling of model output that leads to injection. It does not test model behaviour such as susceptibility to prompt injection; that needs threat modelling, design controls and adversarial testing.
Building an LLM feature and want these controls designed in from the start? See LLM development and RAG development, or hire AI agent developers who build agents with least privilege, approvals and tracing by default. For the code itself, read how to secure AI-generated code.
