The OWASP Top 10 for LLM Applications:What Every Developer Needs to Know

What Is the OWASP Top 10 for LLM Applications?

OWASP (Open Web Application Security Project) publishes ranked lists of critical security risks to help developers understand and address the most important threats in their field. The Web Application Security Top 10 is the most widely known, covering risks like SQL injection and XSS. As large language models became widely deployed in production applications, OWASP created a separate list specifically for them.

The OWASP Top 10 for LLM Applications covers risks that are unique to, or significantly amplified by, the use of a language model. These risks do not appear in traditional web application security lists because they depend on the probabilistic, natural language reasoning of an LLM. The list was first published in 2023 and updated in 2025 to reflect the rapid growth of agentic AI systems.

Why Does AI Need Its Own OWASP Top 10?

Traditional application security assumes that code behaves deterministically. Input A always produces output B, and every action the software can take is explicitly listed in the source code. Large language models break both assumptions. A model's output depends on its training, its context window, and probabilistic sampling. It can take actions through tools that no developer explicitly coded for a given input.

This creates entirely new risk categories. A SQL injection attack targets the database layer. A prompt injection attack targets the model's reasoning layer and can redirect the entire application's behaviour in ways that traditional input validation cannot prevent. The OWASP LLM Top 10 exists because these risks require different thinking, different defences, and different security tests.

LLM01: What Is Prompt Injection and Why Is It the Number One Risk?

Prompt injection is ranked first because it is the root cause or amplifier of most other LLM attacks. It occurs when an attacker embeds malicious instructions into content that the model processes as input. The model cannot reliably distinguish between instructions from the developer and instructions from an attacker embedded in user input or retrieved content.

There are two main forms. Direct injection: the attacker puts malicious instructions into their own user message to override the system prompt. Indirect injection: the attacker embeds instructions in external content the agent will read later, such as a webpage, an email, or a document. When the agent retrieves that content, it may follow the embedded instructions as if they were legitimate.

LLM02: What Is Sensitive Information Disclosure in LLM Applications?

LLM applications often have access to sensitive information: system prompts containing business logic, retrieved documents with private data, and credentials injected into the context. Sensitive information disclosure occurs when the model reveals this data in its outputs, either because an attacker asked for it directly, or because the model included it unnecessarily in a response.

Prevention: treat the context window as a security boundary. Do not include credentials, personal data, or proprietary business logic in the prompt unless the model genuinely needs it for the task. Use output filtering to detect and block responses that contain sensitive patterns like email addresses, API keys, or financial data.

LLM03: What Are Supply Chain Vulnerabilities in AI Systems?

AI supply chain vulnerabilities cover the risks in the components your LLM application depends on: the base model, fine-tuning datasets, plugins, libraries, and third-party integrations. A compromised model weight file, a poisoned fine-tuning dataset, or a malicious plugin can undermine the security of your entire application even if your own code is clean.

Prevention: use models from verified sources and verify checksums of downloaded model files. Audit third-party plugins before including them. Monitor for changes in model behaviour after updates, as a supply chain compromise may alter outputs in subtle ways. Apply the same dependency security practices to AI components that you apply to npm or PyPI packages.

LLM04: What Is Data and Model Poisoning?

Data poisoning is an attack on the training or fine-tuning phase. An attacker inserts malicious examples into the training dataset so that the model learns to behave in a specific harmful way when triggered by a particular input pattern. The result is a model that appears to function normally but produces attacker-controlled outputs under specific conditions.

This risk is particularly relevant for organisations that fine-tune models on their own data or use retrieval-augmented generation (RAG) with external knowledge sources. If an attacker can inject content into your RAG knowledge store, they can influence the model's responses for all users who query that topic, even without touching the model weights themselves.

LLM05: What Is Improper Output Handling?

Improper output handling occurs when an application uses LLM-generated content in a downstream system without validating or sanitising it first. If LLM output is passed to a web page without encoding, it can cause XSS. If it is passed to a database query without parameterisation, it can cause SQL injection. If it is passed to a shell command without validation, it can cause command injection.

The LLM is the source of the output, but the vulnerability is in how the application handles that output. Prevention: treat all LLM output as untrusted data, exactly as you treat user input. Apply the same validation and encoding rules. Never pass LLM output directly to a shell, a database query, or an HTML renderer without sanitisation.

LLM06: What Is Excessive Agency in LLM Applications?

Excessive agency occurs when an LLM agent is given more capabilities, permissions, or autonomy than it needs for its task. This becomes a critical risk when combined with prompt injection: if the agent can be manipulated through its inputs and has broad tool access, an attacker can trigger any action the agent is capable of taking.

The three dimensions of excessive agency are: too many tools (functions the agent does not need), overly permissive tools (write access when read access would suffice), and too much autonomy (the agent takes irreversible actions without human confirmation). Prevention: apply the principle of least privilege to every tool, permission, and autonomous decision the agent can make.

LLM07: What Is System Prompt Leakage?

System prompt leakage occurs when an attacker extracts the contents of the system prompt through carefully crafted user messages. The system prompt typically contains business logic, persona instructions, security rules, and sometimes credentials. When leaked, it reveals the internal architecture of the application and can be used to craft more effective attacks.

Prevention: do not rely on the system prompt as a security boundary. Treat it as moderately confidential, not secret. Never store API keys or hard-coded credentials in the system prompt. Use output filtering to detect responses that repeat the system prompt verbatim. Assume the system prompt can be extracted and design your security controls accordingly.

LLM08: What Are Vector and Embedding Weaknesses?

Vector databases are used in retrieval-augmented generation (RAG) systems to find relevant documents for the model's context. Embedding weaknesses occur when an attacker can manipulate the vector store or the documents it indexes. A maliciously crafted document can be made to rank highly for certain queries, ensuring it is always included in the context for those queries.

This is a form of indirect prompt injection at the retrieval layer. Prevention: control who can add documents to your vector store with the same rigour you apply to a database. Validate and sanitise documents before indexing. Consider using metadata filtering to limit which documents are eligible for retrieval based on the user's permissions and the query context.

LLM09: What Is Misinformation Risk in LLM Applications?

Misinformation risk, sometimes called hallucination risk, occurs when an LLM confidently produces inaccurate or fabricated information and the application passes this to users or downstream systems without verification. This is not an attack: it is an inherent property of generative models. However, it becomes a security and liability risk when the application is used for decisions in high-stakes domains.

Prevention: implement retrieval-augmented generation to ground responses in verified sources. Add citation requirements to the prompt so the model must reference a source for factual claims. Build human review steps for high-stakes outputs. Do not use LLM output as the sole basis for consequential decisions such as medical advice, legal guidance, or financial recommendations.

LLM10: What Is Unbounded Consumption?

Unbounded consumption covers denial-of-service and cost exploitation attacks against LLM applications. Because LLM API calls are billed per token, an attacker who can force the model to generate very long outputs or submit very large inputs can cause significant financial damage. Recursive prompts, jailbreaks that bypass output length limits, and prompt flooding are all forms of this attack.

Prevention: set maximum input and output token limits. Implement rate limiting per user and per session. Set billing alerts and hard spending caps at the API key level. Monitor for anomalous token consumption patterns and alert on sudden spikes. Consider requiring authentication before allowing access to LLM-powered features.

How Do You Prioritise the OWASP LLM Top 10 for Your Application?

Not all ten risks apply equally to every application. Here is a practical prioritisation guide based on application type.