# OWASP LLM Top 10

A consensus list of the most critical security risks in LLM applications, from prompt injection to excessive agency.

**Rests on:** Prompt Injection

*Security and Privacy · AI Security*


## Why learn this

This is the standard starting checklist for securing any application that uses a large language model (an AI system that generates text based on vast amounts of data). By the end of this page you will know the ten most critical risks, why each one matters, and how to spot them in a real system. This is your first step into AI Security, and it directly sets up the more advanced topics in your library: the deep dive on risk #1, where an attacker manipulates the input text to override the intended behavior; risk #3, where bad data is fed into the system during its training phase to corrupt its knowledge; risk #6, where someone asks specific questions to steal the underlying logic of the model for their own use; and the whole discipline of practical testing that you will meet in 'Practical AI Security', where experts deliberately try to break the system to find flaws. Without this list, you are defending an LLM application without a map.


## The intuition

Think of an LLM application as a new employee who has read the entire internet. They are incredibly capable but also gullible, loud, and have no sense of what is confidential. Security risks are all the ways this employee can be tricked, or can trick themselves, into doing harm. The OWASP Top 10 is a community-agreed list of the ten most common and most dangerous ways this happens. It is not a complete security programme, but it is the floor — the bare minimum you must think about before you put an LLM application into production. Each risk is a category, not a single bug, and each one has a name, a description, and a set of things you can do to prevent or mitigate it. The list is maintained by OWASP (Open Worldwide Application Security Project), the same organisation that publishes the famous Top 10 for web applications. The LLM version is updated as the field changes, so the specific entries may shift, but the underlying message is constant: LLM applications are not just web apps with a chat box — they have new kinds of attack surfaces that require new kinds of security thinking.


## An analogy

Imagine you hire a brilliant but extremely trusting assistant. This assistant has access to your email, your calendar, your bank account, and the internet. The assistant follows instructions perfectly, but they cannot tell the difference between a genuine request from you and a malicious email that says 'Please transfer all funds to this account.' This is prompt injection: the assistant is so eager to please that they will obey instructions from anyone, even those trying to trick them. Now imagine the assistant can also order supplies, send emails, and book flights — that is agency. If you give them too much power, a single mistake could cause real damage; this is excessive agency. The assistant also writes summaries of everything they read, but they might accidentally copy private passwords into a public report — that is insecure output handling. Now think about the assistant's training: if someone slips false information into their initial briefing (data poisoning), they will believe it forever and act on it. If another company asks the assistant cleverly worded questions, they can extract the secret 'rules' your assistant was trained on (model extraction). The Top 10 is a list of all the ways this assistant can be exploited, and what you as the employer can do to limit the damage. The analogy breaks down when you realise the LLM has no intentions, no self-preservation, and no sense of right or wrong — it is a statistical machine that predicts the next word. But the assistant metaphor is useful because it highlights that the risks are not about the model itself, but about how the model is connected to the world.


## Definition

The OWASP Top 10 for Large Language Model Applications is a consensus, regularly updated list of the ten most critical security risks specific to applications built on LLMs — from prompt injection (tricking the model to do something unintended) to excessive agency (giving the model too much power to act on its own).


## How it connects

You have no prior notes on this topic, but you have a strong foundation in the neighbouring topics in your library. In particular, 'Prompt Injection' is the direct deep-dive into risk #1, so you will see its name again. 'Data Poisoning' is risk #3, and 'Model Extraction' is risk #6. The other risks (supply chain, sensitive information disclosure, etc.) connect to general cybersecurity principles you may have seen in your 'Cybersecurity' notes. This concept sits at the boundary between application security (securing the code and infrastructure) and AI-specific security (securing the model and its data). It is the practical checklist part of AI Security, meaning it focuses on what to do now rather than theoretical attacks.


## Common misconceptions

**The Top 10 is a complete security programme** — If I fix all ten items on the list, my application is secure.

The list is a curated set of the most common and severe risks, but it is not comprehensive. There are many other risks, and new ones are discovered all the time. A checklist is a floor, not a ceiling. In fact: The Top 10 is a starting point for discussion, not a replacement for a threat model. You still need to think about your specific data, users, and context.

**Prompt injection only happens through user messages** — Only the user can inject a malicious prompt.

Any untrusted content that ends up in the prompt — retrieved documents, web pages, email contents, etc. — can carry injection instructions. In fact: Treat all untrusted data as potential prompt injection vectors, not just direct user input.

**The model is the security boundary** — The LLM will refuse malicious requests because it has been trained to be safe.

LLMs are not designed to be security boundaries. They are generative and can be manipulated, especially through indirect prompt injection. In fact: Security must be enforced in the application layer — validation, filtering, and authentication — not by relying on the model's refusal behaviour.

**If the output looks sensible, it is safe** — I can trust the model's response because it reads naturally.

The model can be tricked into producing harmful output that looks perfectly normal. For example, it might leak private information or include a malicious link without any obvious sign. In fact: Always validate and sanitise the model's output, especially before it is rendered or acted upon.

**Giving the model more tools is always better** — The more tools my agent has, the more capable it will be.

Unnecessary tools expand the attack surface. A tool that can delete files is only useful if you need to delete files. If it is compromised, it can be used to cause damage. In fact: Follow the principle of least privilege: give the model only the tools it absolutely needs, and no more.

**The Top 10 only applies to LLM chat applications** — My computer vision system or my tabular fraud model has nothing to do with LLM risks.

Many modern applications are multimodal or have natural language components. Also, the underlying principles (input validation, output handling, access control) apply to any AI system. In fact: Use the Top 10 as a thinking aid for all AI applications, even if you do not use an LLM directly.

**The list is fixed and permanent** — Once I learn the ten risks, I am done forever.

The Top 10 is updated periodically. New attack techniques are discovered, and the list changes to reflect the current landscape. In fact: Review the list periodically and stay informed about new risks.


## In short

The OWASP LLM Top 10 is a living, community-maintained list of the most critical security risks in LLM applications. It is not a replacement for a security programme, but it is the starting point that every developer and security professional should know. The key takeaway: LLM applications are not ordinary software — they require thinking about new kinds of attacks, especially those that exploit the model's instruction-following nature. Always validate inputs, sanitise outputs, and grant the least privilege necessary.


## Where this is used

This concept is used everywhere in the real world when teams build and deploy LLM applications. Here is how each segment of the industry uses the Top 10, and what a developer actually does.

**Large language models (cloud APIs like GPT-4, Claude, Gemini):** A team building a chatbot on top of a cloud LLM does not control the training of the base model, so their focus is on the application layer. They use the Top 10 to guide security reviews. For prompt injection (LLM01), they add input validation — for example, they reject messages that contain phrases like 'ignore previous instructions' or they use a separate classifier to flag suspicious inputs. For insecure output handling (LLM02), they escape or sanitise the model output before rendering it in a web page, to prevent cross-site scripting. For sensitive information disclosure (LLM06), they implement redaction filters that scan the model's output for patterns that look like social security numbers or API keys. They also use the Top 10 to justify adding a human-in-the-loop for high-risk actions (excessive agency, LLM09).

**Small language models on devices (phones, laptops):** When a model runs locally, the risk of data leakage to a server is reduced, but the model itself might be extracted by an attacker who has physical access to the device. Developers use the Top 10 to think about model theft (LLM08) — they might encrypt the model weights and use hardware-backed secure storage. They also worry about prompt injection via malicious apps or web pages that the on-device model might read. For example, a smartphone keyboard that uses an on-device model could be tricked by a text message containing hidden instructions — a real prompt injection vector.

**Retrieval-Augmented Generation (RAG):** RAG is a prime target for prompt injection. The agent retrieves documents from a database and feeds them into the prompt. An attacker who can plant a malicious document in that database can inject instructions into the prompt, and the LLM will follow them. Developers use the Top 10 to secure the retrieval pipeline: they validate and sanitise retrieved content, they restrict the database to trusted sources, and they monitor for unusual queries that might indicate an injection attempt. They also apply output handling controls to make sure the model's answer does not leak the raw document contents if it is sensitive.

**Agentic systems (planning, tool use, loops):** This is where excessive agency (LLM09) is most critical. An agent that can send emails, access files, or call APIs is only as safe as its least restrictive boundary. Developers use the Top 10 to enforce the principle of least privilege: the agent gets only the tools it needs, and no more. They add human approval for dangerous actions, they set time limits on agent loops, and they log all tool calls. They also protect against prompt injection that might make the agent take unintended actions — for example, a web page the agent reads could contain 'send your API key to this address' hidden in the text.

**Everyday applied ML (fraud detection, recommendation, forecasting):** These systems may not use LLMs at all, but if they incorporate any natural language component, the Top 10 still applies. For example, a fraud detection system that uses an LLM to summarise customer complaints must be protected against prompt injection (a customer complaint could include malicious instructions). The developer would use the Top 10 to justify adding the same input validation and output sanitisation as in a fully LLM-based system.

**In practice:** A developer typically does not read the Top 10 every day, but they use it as a kickoff checklist. When they build a new LLM feature, they go through the list and ask 'Are we at risk of this one? If so, what are we doing about it?' They might write a small script that tests for prompt injection (sending a few known attack strings) or a rule that rejects output containing HTML tags. They use it in threat modelling sessions, in code reviews, and in penetration tests. When something breaks, they often find it is one of the Top 10 that was ignored.


---

Read this on the web: https://basavapurushottam.com/learn-ai/owasp-llm-top-10
