The OWASP Top 10 for LLM Applications, Explained

The OWASP Top 10 for LLM applications is the closest thing the industry has to a shared vocabulary for LLM security risks. It is maintained by the OWASP GenAI Security Project, and the current edition is the 2025 list. Most summaries of it repeat the ten names and stop. This guide goes further: for every entry you get what it means in practice, a realistic example, how to test for it, and the control that actually closes it.

The 2025 list at a glance

The official names and IDs below are taken from the OWASP GenAI Security Project. The example and control columns are my own summary of how each risk shows up in real applications.

What changed from the 2023/24 list

The 2023/24 edition had a different shape. Comparing the two lists side by side, the main movements are:

• Two new entries: System Prompt Leakage (LLM07) and Vector and Embedding Weaknesses (LLM08). Both reflect how teams now build: long system prompts carrying business logic, and RAG pipelines everywhere.
• Model Denial of Service became Unbounded Consumption (LLM10). The scope widened from availability to cost and resource abuse, which matters when every token is billed.
• Overreliance became Misinformation (LLM09). The focus moved from the user trusting too much to the model producing false content in the first place.
• Training Data Poisoning became Data and Model Poisoning (LLM04), covering fine-tuning and embedding data as well as pre-training.
• Insecure Output Handling was renamed Improper Output Handling (LLM05), and Supply Chain Vulnerabilities is now simply Supply Chain (LLM03).
• Sensitive Information Disclosure rose from sixth to second, and Excessive Agency moved from eighth to sixth.
• Insecure Plugin Design and Model Theft no longer have their own entries. Plugin risk is now largely covered by Excessive Agency and Supply Chain.

For agent-heavy systems, OWASP has also published a separate OWASP Top 10 for Agentic Applications (the 2026 edition, released in December 2025). It targets autonomous agents that plan and act across multi-step workflows. It complements the LLM list rather than replacing it; if you are building agents, read both, and see AI agent security for the controls I apply.

Every risk, explained

LLM01:2025 Prompt Injection

Prompt injection is any input that changes the model's behaviour in a way the developer did not intend. Direct injection comes from the user's own message; indirect injection arrives inside content the system reads, such as a web page, a PDF, an email or a tool result. Because instructions and data share one channel, there is no complete fix at the model layer.

Example: an agent that triages support tickets and can issue refunds reads a ticket containing a hidden line addressed to the model, asking it to refund an unrelated order. Test: plant payloads in every channel the system ingests, including filenames, HTML comments, image ALT text and white-on-white text, then check whether any privileged tool fires. Fix: put authorisation in the tool using the real user's identity, separate untrusted content from instructions, and require human approval for irreversible actions. The full playbook is in prompt injection.

LLM02:2025 Sensitive Information Disclosure

The model reveals data it should not: personal data, credentials, internal documents, or another user's records. The model usually is not the root cause; it repeats whatever ended up in its context or training data.

Example: a customer chatbot loads the last fifty orders into context to be helpful, and a user asks it to list "recent orders similar to mine". Test: ask for other users' data by name, ID and description; try to extract anything placed in context; check logs and traces for PII you did not expect to store. Fix: fetch only what the current user is entitled to see, redact before data reaches the model, scan output for secrets and PII, and never fine-tune on data you would not be willing to have reproduced.

LLM03:2025 Supply Chain

LLM applications depend on third-party models, adapters, datasets, libraries and tool servers. Any of these can be outdated, tampered with or simply not what its name claims.

Example: a team downloads a fine-tuned model from a public hub because it scores well, without checking who published it or what format the weights use. Test: inventory every model, dataset, plugin and tool server; check signatures, licences and maintainers; flag any pickle-based weight files and unpinned versions. Fix: pin versions, prefer safe serialisation formats such as safetensors, verify checksums, keep an AI bill of materials, and review third-party tool servers as carefully as code. The same thinking applies to MCP security.

LLM04:2025 Data and Model Poisoning

An attacker influences the data a model learns from or retrieves, to bias outputs, degrade quality or plant a backdoor that activates on a trigger phrase. This covers pre-training, fine-tuning and embedding data.

Example: a knowledge base accepts documents from a shared drive, and someone adds a file that subtly rewrites the official procedure for approving supplier payments. Test: trace every path by which data enters training sets and indexes, and check who can write to each; run evaluation sets before and after each data or model update and investigate unexplained shifts. Fix: restrict and log writes to data sources, review ingestion, track data lineage, and gate model updates on a fixed evaluation suite.

LLM05:2025 Improper Output Handling

Model output is passed to another component without validation or encoding. This turns an LLM into a delivery mechanism for classic web vulnerabilities: XSS, SQL injection, command injection, SSRF and path traversal.

Example: a chat UI renders model replies as raw HTML, so an injected instruction that makes the model emit a script tag runs in the victim's browser. Markdown image links that leak data through the URL are a common variant. Test: coax the model into producing markup, SQL fragments, shell metacharacters and external URLs, then follow each output to wherever it lands. Fix: treat model output as untrusted user input. Encode for the context it is rendered in, validate against a schema, parameterise queries, and never pass output to eval, a shell or a template engine.

LLM06:2025 Excessive Agency

The system gives the model more functionality, permission or autonomy than the task needs, so a manipulated or simply mistaken model can do real damage. OWASP frames the root causes as excessive functionality, excessive permissions and excessive autonomy.

Example: an assistant that only needs to read and summarise emails is wired to a mailbox integration that can also send and delete, using a service account with access to every mailbox. Test: list every tool, the permissions behind it, and whether any action runs without confirmation; then try to reach each one through injection. Fix: expose only the tools the task needs, narrow each tool's scope, run downstream calls with the end user's identity, and require approval for high-impact actions. See agentic AI development for how to design this in from the start.

// Excessive agency is fixed in the tool definition, not the prompt.
const tools = {
  // Read-only, scoped to the signed-in user's mailbox.
  listMyEmails: tool({
    inputSchema: z.object({ limit: z.number().int().max(20) }),
    execute: ({ limit }, { session }) =>
      mail.list({ owner: session.userId, limit }),
  }),
  // No send, no delete. If drafting is needed, create a draft
  // that the human reviews and sends themselves.
  createDraftReply: tool({
    inputSchema: z.object({ threadId: z.string(), body: z.string().max(4000) }),
    execute: ({ threadId, body }, { session }) =>
      mail.createDraft({ owner: session.userId, threadId, body }),
  }),
};

LLM07:2025 System Prompt Leakage

The system prompt is exposed, revealing whatever it contains. OWASP is explicit that the prompt should not be treated as a secret or a security control. The real risk is what developers put in it: credentials, internal rules, role logic or filtering criteria an attacker can then work around.

Example: an extracted prompt contains a database connection string and the line "users with the admin role may see all records", which tells an attacker exactly what to impersonate. Test: run extraction attempts such as translation requests, "repeat the text above", role-play and encoding tricks; then read your own prompt and assume it is public. Fix: move secrets to the server, enforce permissions in code, and write prompts you would be comfortable publishing.

LLM08:2025 Vector and Embedding Weaknesses

Weaknesses in how embeddings are generated, stored and retrieved in RAG systems. These include missing access control on the vector store, cross-tenant leakage, poisoned documents in the index, and embedding inversion that can recover source text.

Example: a multi-tenant SaaS keeps all customers in one collection and filters results after retrieval, so a crafted query surfaces another tenant's contract. Test: query for content you should not be able to see; inspect whether access filters run inside the vector query; plant a document containing instructions and see whether it changes answers. Fix: store ACL metadata on every chunk and filter at query time, separate indexes by trust level, validate content at ingestion and log every retrieval. The detail is in RAG security.

LLM09:2025 Misinformation

The model produces false or misleading content that looks credible, and people or systems act on it. Hallucination is the main cause, made worse by over-trust in confident answers.

Example: a coding assistant suggests installing a package that does not exist. If an attacker later registers that name, developers who follow the suggestion install malware. A support bot inventing a refund policy is the business version. Test: ask questions whose answers are not in your sources and check whether the system admits it; verify citations actually support the claims. Fix: ground answers in retrieved sources with citations, let the system say "I do not know", validate package and API names automatically, and put a human in the loop where errors are costly.

LLM10:2025 Unbounded Consumption

The application allows excessive or uncontrolled inference, leading to denial of service, runaway cost (sometimes called denial of wallet) or model extraction through mass querying.

Example: a public chatbot with no per-user limits is scripted to send maximum-length prompts all night; or an agent loops on a failing tool call indefinitely. Test: send oversized inputs, high request rates and prompts designed to trigger long outputs or recursive tool calls, and watch latency and cost. Fix: rate-limit per user and per key, cap input and output tokens, bound agent steps and tool calls, set budget alerts, and keep a kill switch.

How to use the list in a real assessment

The list is a coverage tool, not a test plan. In my own assessments (Sheikh Mujtaba), I map each entry to the specific components of the system under test, then build test cases against those components. A useful order of work:

1. Draw the data flow. Every input channel, every data source, every tool, every place output is rendered or executed.
2. Map each OWASP entry to components. LLM05 maps to every output sink; LLM08 maps to the vector store; LLM06 maps to the tool list.
3. Prioritise by blast radius. An agent that can move money or delete records outranks a chatbot that can only talk.
4. Test with reproducible cases and keep them as regression tests, as described in AI red teaming.
5. Report against the IDs. Using LLM01:2025 and friends in findings gives developers and auditors a shared reference.

Key takeaways

• The 2025 OWASP Top 10 for LLM applications runs from Prompt Injection (LLM01) to Unbounded Consumption (LLM10).
• System Prompt Leakage and Vector and Embedding Weaknesses are new for 2025; Model Denial of Service and Overreliance were reframed.
• Most entries are system risks: data, tools, output handling and cost, not just the model.
• Authorisation belongs in code and tools, never in the system prompt.
• Treat model output as untrusted input to every downstream component.
• Use the list for coverage, then turn each test into a regression case.