The OWASP Top 10 for LLM applications and for machine learning, used as a working checklist

Why this matters

When a team designs its first AI application, the hardest part of a security review is knowing what to ask. Experience with web applications helps, but not enough: an injection that arrives inside a retrieved document, an output that becomes a command, or a training set altered weeks before release has no direct counterpart in a classic application checklist.

The Open Worldwide Application Security Project (OWASP) publishes two lists that fill that gap: the Top 10 for LLM Applications and the Machine Learning Security Top 10. They are the most widely shared vocabulary for AI application risk, which makes them useful twice over: as a checklist for your own review, and as a common language when a supplier, an auditor or a developer says "that is an excessive agency problem".

The exam uses them the same way. A scenario describes a design or an incident, and the question turns on naming the risk correctly and choosing the control that addresses it. That requires knowing what each entry means, which list it belongs to, and where the lists stop, because the trap in many questions is an answer that names a fashionable list entry when the real failure is something older.

The lesson

Why OWASP publishes separate lists for LLM applications and for machine learning systems

The two lists look at different systems and different owners.

The LLM Top 10 is about applications built around a large language model, usually one the organisation did not train. The attack surface is the prompt, everything that gets assembled into it (system prompt, user text, retrieved documents, tool results), and everything the application does with the output. Its readers are application developers and architects.

The ML Security Top 10 is about machine learning systems in general, including classifiers and detectors that never generate text: a fraud model, a malware classifier, an image recogniser. The attack surface is the training data, the training pipeline, the model artefact and the inference interface. Its readers are data scientists and machine learning engineers.

Some risks appear on both, such as poisoning and supply chain, because a large language model is also a machine learning model. The difference is which part of the system each list puts under the microscope: the LLM list the application around the model, the ML list the pipeline that makes it.

The LLM list has also been revised. The current list is the 2025 edition, and the earlier 2023 list used names that CY0-001 still uses, so you need both vocabularies:

• Insecure Output Handling became Improper Output Handling.
• Model Denial of Service broadened into Unbounded Consumption, which also covers runaway cost and copying a model's behaviour through heavy use of its interface.
• Model Theft is no longer a separate entry; extraction through the interface sits under Unbounded Consumption, and theft of the artefact itself remains on the ML list as Model Theft.
• Overreliance is now covered by Misinformation, which joins the model producing false content with people trusting it unchecked.
• Insecure Plugin Design is no longer a separate entry; its concerns are mostly covered by Excessive Agency and Improper Output Handling.
• Training Data Poisoning widened into Data and Model Poisoning.
• System Prompt Leakage and Vector and Embedding Weaknesses are new.

Walking the LLM list against an application design, risk by risk

Take one design and walk the list against it. An invented retailer runs a support assistant: it answers from a knowledge base through retrieval-augmented generation, can look up a customer's order, can open a ticket, and renders its answers in a web chat widget.

• LLM01 Prompt Injection. Instructions arriving in the user's message (direct) or inside a retrieved document or ticket history (indirect) override the developer's intent. Ask: what untrusted text reaches the prompt, and what could it make the assistant do?
• LLM02 Sensitive Information Disclosure. Can the assistant reveal another customer's order, internal notes from the knowledge base, or personal data? Ask whose permissions the lookups run with.
• LLM03 Supply Chain. The model, its provider, the embedding model, the orchestration libraries and any plug-ins are all dependencies. Ask where each came from and how a compromise of one would show.
• LLM04 Data and Model Poisoning. If the knowledge base or a fine-tuning set can be edited by many people, or ingests web content, it can be seeded.
• LLM05 Improper Output Handling. The widget renders model output. If that output can contain markup or script and the widget does not encode it, the model becomes a cross-site scripting vector. The same applies to output passed to a database query, a shell or a ticketing API.
• LLM06 Excessive Agency. Opening tickets is reasonable. The ability to close, refund or email, or a ticketing credential far broader than the task needs, is not. Ask which actions exist, under which identity, with what approval.
• LLM07 System Prompt Leakage. Assume the system prompt can be extracted. The finding is not the leak itself but anything in the prompt that should never have been there: credentials, internal URLs, or access rules enforced only by the prompt's wording.
• LLM08 Vector and Embedding Weaknesses. One vector store serving several audiences without access filtering lets one user retrieve another's content, and embeddings themselves can leak information about their source text.
• LLM09 Misinformation. Confident wrong answers about returns or warranty terms, acted on by customers or staff. Ask how answers are grounded and how errors are caught.
• LLM10 Unbounded Consumption. No per-user rate or token limits means one script can run up the bill, exhaust capacity for everyone else, or harvest enough outputs to imitate the model.

Ten questions, each answerable from a design document. That is the list doing its job.

Walking the ML list against a training pipeline

Now a different system: a fraud-scoring classifier retrained monthly on transaction data and labelled outcomes, served through an internal API that returns a score.

• ML01 Input Manipulation Attack. At inference, an attacker shapes a transaction so it scores as legitimate. This is the evasion attack, and it needs no access to training at all.
• ML02 Data Poisoning Attack. Corrupted training records or labels teach the model a wrong lesson, for example disputed transactions mislabelled as genuine.
• ML03 Model Inversion Attack. Repeated queries let an attacker reconstruct features of the training data from the model's outputs.
• ML04 Membership Inference Attack. An attacker determines whether a specific record was in the training set, which is itself a privacy breach when membership is sensitive.
• ML05 Model Theft. The model is copied, either by stealing the artefact or by querying the API enough to train a functional replica.
• ML06 AI Supply Chain Attacks. A compromised library, pre-trained component or dataset enters the pipeline.
• ML07 Transfer Learning Attack. A pre-trained base model carries hidden behaviour that survives the organisation's fine-tuning on top of it.
• ML08 Model Skewing. An attacker manipulates the data feeding a regularly retrained model, such as feedback or labels, so that its behaviour drifts in the attacker's favour over successive cycles.
• ML09 Output Integrity Attack. The score is altered between the model and the system that acts on it, so a sound model produces a wrong decision.
• ML10 Model Poisoning. The model's parameters themselves are tampered with, rather than the data it learned from.

The pipeline view shows where each lands: ML02, ML06, ML07 and ML08 in data and training; ML10 on the stored artefact; ML01, ML03, ML04 and ML05 at the inference API; ML09 downstream of it. Lessons 17 to 19 cover the evidence each leaves and the controls that contain them.

Turning a list entry into a test, a control and an owner

A list entry is a category, not a finding. It becomes useful when it is turned into three concrete things: a test that would show whether the risk is present, a control that reduces it, and an owner who keeps the control working. Without the owner, the review produces a document and nothing else.

Two habits make this stick. Record which entries were judged not applicable and why, because "not applicable" is a decision that can be wrong and should be revisited when the design changes. And rerun the tests when the system changes, since adding a tool to an assistant can turn a closed Excessive Agency finding into an open one overnight.

What a top-ten list leaves out, and why that is the scenario's trap

Both lists are awareness documents: short, ranked by broad consensus, and deliberately focused on what is distinctive about AI. That focus is their value and their limit.

What they largely leave to other guidance:

• Ordinary application and infrastructure security. An unauthenticated model endpoint, an API key committed to a repository, a storage bucket of training data open to the internet, or a missing patch on the inference server. None is an "AI risk", and all of them are how real AI systems get breached.
• Governance failures. Shadow AI, an unapproved use case, a missing owner, or data used outside its lawful purpose (lessons 31 and 33).
• Attacks that use AI rather than target it, such as deepfakes and automated reconnaissance (lessons 23 and 24).
• Your own context. A list ordered by general consensus says nothing about which risk is highest for this system, and it is not a threat model. Lesson 8 covers the resources and methods that fill that gap.

The scenario trap follows directly. A question describes an AI application and an incident, and one option names an impressive list entry while another names a plain control: authentication on the endpoint, a scoped credential, a patch. When the evidence shows the attacker came in through an exposed endpoint or a leaked key, the right answer is the plain control, however AI-flavoured the system is. Read for the actual path the attacker used, then name the category.