Key takeaways
- It has been demonstrated, and the research predates the OWASP list by years.
- Do not treat withheld confidence scores as a complete defense against extraction.
The OWASP Machine Learning Security Top 10 is a dedicated OWASP project cataloging ten distinct ways a deployed machine learning model can be attacked, from data poisoning and model theft to output-integrity tampering — separate from, and broader than, OWASP's own LLM-focused top-10 list. Maintained by project leaders Shain Singh, Sagar Bhure and Ben Kereopa-Yorke, the project's own site states its aim is "to deliver an overview of the top 10 security issues of machine learning systems," covering any deployed ML model — not only generative or language models. Two of its ten categories, model theft and input manipulation, have documented real-world demonstrations going back nearly a decade, and NIST's own independent taxonomy converges on the same core attack classes.
This guide draws directly on the OWASP Machine Learning Security Top 10 project's own page, the project's own published list at mltop10.info, NIST's own AI 100-2e2025 publication page, and the original academic paper demonstrating model extraction attacks — each fetched and read for this guide, not paraphrased from a secondary summary.
What makes the ML Top 10 different from the OWASP LLM Top 10?
Per the OWASP Machine Learning Security Top 10 project's own page, "the primary aim of the OWASP Machine Learning Security Top 10 project is to deliver an overview of the top 10 security issues of machine learning systems." The project's own reference document at mltop10.info identifies itself as the "OWASP Machine Learning Security Top 10 (2023 edition) — Draft release v0.3," maintained by project leaders Shain Singh, Sagar Bhure and Ben Kereopa-Yorke.
That scope is deliberately broader than the separate OWASP Top 10 for LLM Applications project, which targets risks specific to large-language-model applications — prompt injection, insecure output handling, excessive agency in an agent loop. The ML Top 10 instead targets the model layer itself, across any deployed machine learning system: a fraud-detection classifier, a predictive-maintenance regression model running on a factory gateway, a computer-vision model embedded in a camera, or a generative model — the risks in this list apply regardless of whether the model ever produces natural-language text.
What are the ten risk categories?
Per mltop10.info's published 2023-edition list:
| Code | Category | What it means |
|---|---|---|
| ML01:2023 | Input Manipulation Attack | Crafted inputs cause incorrect predictions |
| ML02:2023 | Data Poisoning Attack | Corrupting training data to compromise model integrity |
| ML03:2023 | Model Inversion Attack | Extracting sensitive information from a trained model |
| ML04:2023 | Membership Inference Attack | Determining whether a specific record was used in training |
| ML05:2023 | Model Theft | Unauthorized acquisition or replication of a model |
| ML06:2023 | AI Supply Chain Attacks | Compromise via vulnerable dependencies or third-party components |
| ML07:2023 | Transfer Learning Attack | Exploiting a pre-trained base model to attack systems built on top of it |
| ML08:2023 | Model Skewing | Degrading model performance through manipulation or bias injection |
| ML09:2023 | Output Integrity Attack | Tampering with model outputs after generation |
| ML10:2023 | Model Poisoning | Corrupting the model itself during development or deployment |
Is model theft (ML05) a theoretical risk, or has it actually been demonstrated?
It has been demonstrated, and the research predates the OWASP list by years. "Stealing Machine Learning Models via Prediction APIs" (Tramèr, Zhang, Juels, Reiter and Ristenpart) showed black-box model extraction attacks: an adversary with no access to a model's parameters or training data can duplicate its functionality purely by querying its public prediction API. The paper validated the technique against logistic regression, neural network and decision tree models, and — critically for anyone relying on a commercial ML API — tested it against two real production services, BigML and Amazon Machine Learning. The attacks worked even when confidence scores were withheld from the API response, meaning a common "defense" (returning only the top predicted label, not the model's certainty) does not by itself stop extraction.
Does an independent standards body confirm these are real categories, not just one project's opinion?
Yes. NIST's own publication, AI 100-2e2025 ("Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations"), independently documents the same underlying attack classes — its publication keywords explicitly include "data poisoning" and "evasion," and NIST's own publication page describes its purpose as providing "a taxonomy of concepts" and defining "terminology in the field of adversarial machine learning," while identifying "current challenges in the life cycle of AI systems" and mitigation approaches. Two independently developed references — a practitioner-maintained OWASP top-10 list and a formal NIST taxonomy — converging on the same core attack categories (poisoning, input manipulation/evasion, extraction-style attacks) indicates these are structural weaknesses in how ML systems get built and deployed, not an idiosyncratic framing from one organization.
A workable starting point
Inventory every deployed ML model and its exposed prediction interface— an internal API, a public endpoint, or an embedded on-device model — before assessing which ML Top 10 categories actually apply; ML05 (model theft) and ML01 (input manipulation) both require the model to be reachable in the first place. Do not treat withheld confidence scores as a complete defense against extractionThe Tramèr et al. research found extraction attacks succeeded even without confidence scores in the response — rate limiting, query-pattern monitoring and output watermarking are the controls the research and later work point toward instead. Track training-data provenance and pipeline integrity(ML02, ML10) the same way you would track a software supply chain, since a poisoned training set or a tampered model artifact is indistinguishable from a correctly trained model until it fails in production. Record every ML model, its training data source and any third-party or pre-trained components it builds onbefore threat-modeling it — see AI-BOM for embedded AI devices for what to capture, and cross-reference MITRE ATLAS and NIST AI 100-2e2025's adversarial ML taxonomy for the broader attack-technique detail behind each ML Top 10 category.
SoftWSP's device and firmware assessments can factor in an embedded or cloud-connected ML model's exposed prediction interface alongside conventional firmware risk: see Device & Firmware Security.
This guide summarizes the OWASP Machine Learning Security Top 10 project's own page, its own published list at mltop10.info, NIST's own AI 100-2e2025 publication page, and the Tramèr et al. model-extraction paper cited above, each fetched directly for this guide on 5 November 2026. It is not a substitute for the current OWASP or NIST publications or the cited paper itself, and does not constitute security advice.
Sources
- OWASP Machine Learning Security Top 10 project (official OWASP project page)
- OWASP Machine Learning Security Top 10 (2023 edition, draft release v0.3) — full ML01–ML10 list, mltop10.info
- NIST AI 100-2e2025: Adversarial Machine Learning — A Taxonomy and Terminology of Attacks and Mitigations (publication page)
- Tramèr, Zhang, Juels, Reiter, Ristenpart: "Stealing Machine Learning Models via Prediction APIs" (arXiv:1609.02943)
Frequently asked questions
What is the OWASP Machine Learning Security Top 10, and is it the same as the LLM Top 10?
No — they are two separate OWASP projects covering different attack surfaces. Per the OWASP Machine Learning Security Top 10 project's own page, "the primary aim of the OWASP Machine Learning Security Top 10 project is to deliver an overview of the top 10 security issues of machine learning systems," and the project is maintained by project leaders Shain Singh, Sagar Bhure and Ben Kereopa-Yorke. The project's own reference site, mltop10.info, identifies the current document as the "OWASP Machine Learning Security Top 10 (2023 edition) — Draft release v0.3." The OWASP Top 10 for LLM Applications, by contrast, is a separate OWASP project covering risks specific to large-language-model applications (prompt injection, insecure output handling, excessive agency). The ML Top 10 targets the broader category of deployed machine learning models generally — classifiers, regression models, neural networks — including non-generative ML systems an LLM-focused list does not cover.
What are the ten risk categories, and what does each one mean?
Per mltop10.info, the ten 2023-edition categories are: ML01:2023 Input Manipulation Attack (crafted inputs cause incorrect predictions); ML02:2023 Data Poisoning Attack (corrupting training data to compromise model integrity); ML03:2023 Model Inversion Attack (extracting sensitive information from a trained model); ML04:2023 Membership Inference Attack (determining whether a specific record was used in training); ML05:2023 Model Theft (unauthorized acquisition or replication of a model); ML06:2023 AI Supply Chain Attacks (compromise via vulnerable dependencies or third-party components); ML07:2023 Transfer Learning Attack (exploiting a pre-trained base model to attack systems built on top of it); ML08:2023 Model Skewing (degrading model performance through manipulation or bias injection); ML09:2023 Output Integrity Attack (tampering with model outputs after generation); and ML10:2023 Model Poisoning (corrupting the model itself during development or deployment, distinct from poisoning its training data).
Has model theft (ML05) actually been demonstrated against a real, deployed system?
Yes, and the foundational research predates the OWASP list itself. "Stealing Machine Learning Models via Prediction APIs" (Tramèr, Zhang, Juels, Reiter and Ristenpart) demonstrated black-box model extraction attacks — duplicating a model's functionality purely by querying its public prediction API, with no access to its parameters or training data — against logistic regression, neural network and decision tree models, and validated the technique against two real commercial services, BigML and Amazon Machine Learning. The attack worked even when the APIs withheld confidence scores from their responses, meaning hiding the model's certainty is not by itself a sufficient defense against extraction.
Does any other standards body document the same attack categories independently?
Yes. NIST's own publication AI 100-2e2025, "Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations," independently documents the same underlying attack classes — its own publication keywords list includes both "data poisoning" and "evasion," and the publication's stated purpose, per NIST's own publication page, is to "provide a taxonomy of concepts and define terminology in the field of adversarial machine learning" and "identify current challenges in the life cycle of AI systems" together with mitigation approaches. That two independent standards efforts — OWASP's practitioner-oriented top-10 list and NIST's formal taxonomy — converge on the same core categories (poisoning, evasion/input manipulation, extraction-style attacks) is a sign these are recognized, structural weaknesses in how ML systems are built and deployed, not one organization's particular framing.
In this cluster
Questions about this page?