OWASP LLM Top 10

This is the standard starting checklist for securing any LLM application. 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: prompt injection (the deep dive on risk #1), data poisoning (risk #3), model extraction (risk #6), and the whole discipline of red teaming that you will meet in 'Practical AI Security'. Without this list, you are defending an LLM application without a map.

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.

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. 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.

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).

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.