Most AI security attention now goes to prompts and agents, yet the fraud model, the malware classifier and the face matcher in production are still exposed to the older attacks the LLM lists barely mention. The OWASP Machine Learning Security Top 10 (ML01:2023 to ML10:2023) names those attacks: evasion, poisoning, inversion, membership inference, theft, supply chain, transfer learning, skewing, output tampering and direct model manipulation. This page keeps OWASP's IDs and names, says what each one means for a team that trains or buys predictive models, and gives the first control to put in place, with a mapping to MITRE ATLAS and the OWASP Top 10 for LLM Applications. It is written for ML engineers, MLOps and AppSec teams and the security architects who review model deployments. For the wider control set, see the AI Model Security Guide.
Status note, checked 9 November 2026: the OWASP project page lists this as a Lab project and says the current version "is in draft and is being modified frequently". The risk pages are dated 2023 and carry no newer version number, so treat the list as a vocabulary for threat modelling, not a compliance baseline, and check the project repository for changes before you cite an ID in a policy.
The Top 10 at a glance
One naming difference: the project index lists ML06 as "AI Supply Chain Attacks", while the ML06 risk page is titled "ML Supply Chain Attacks"; this page uses the risk page title.
OWASP gives each entry sample scores for exploitability, detectability and technical impact, but stresses that they describe one example scenario only. The "lifecycle stage" column is ours: it shows where in the ML lifecycle the defence has to sit, which is usually more useful than the score.
| OWASP ID | Risk | What the attacker changes or takes | Lifecycle stage to defend | Deep dive |
|---|---|---|---|---|
| ML01:2023 | Input Manipulation Attack | Inference inputs, crafted to cause a wrong prediction | Inference | Adversarial Examples and Evasion Attacks Guide |
| ML02:2023 | Data Poisoning Attack | Training data or labels | Data collection and labelling | AI Data Poisoning and Backdoors Guide |
| ML03:2023 | Model Inversion Attack | Takes information about training subjects from outputs | Inference API | AI Model Security Guide |
| ML04:2023 | Membership Inference Attack | Learns whether a record was in the training set | Training and inference API | Membership Inference Attacks |
| ML05:2023 | Model Theft | Takes the parameters or a functional copy | Storage, serving and API | Model Extraction and Distillation Defence Guide |
| ML06:2023 | ML Supply Chain Attacks | Packages, MLOps platforms, model hubs | Build and platform | AI Supply Chain and AI-BOM Guide |
| ML07:2023 | Transfer Learning Attack | A pre-trained base model that is then fine-tuned | Model sourcing and fine-tuning | Fine-Tuning and LoRA Security Guide |
| ML08:2023 | Model Skewing | Feedback data that drives retraining | Feedback loop and retraining | AI Data Poisoning and Backdoors Guide |
| ML09:2023 | Output Integrity Attack | Predictions between the model and their consumer | Serving path and integration | AI Model Security Guide |
| ML10:2023 | Model Poisoning | The model parameters directly | Model storage and registry | Securing the model registry itself |
1. Input Manipulation Attack
The risk: OWASP uses this as an umbrella for adversarial attacks: inputs deliberately altered so the model mispredicts. Its scenarios are an image changed by small perturbations so a classifier mislabels it, and network traffic shaped to slip past an ML-based intrusion detector.
First defence: OWASP lists adversarial training, robust models and input validation. In practice, start by deciding which predictions are security decisions (fraud, malware, identity matching) and never let one model score be the only control for them: keep a rule layer or a second signal behind it. Then test robustness before release with an adversarial evaluation harness; see the Adversarial Robustness Toolbox Guide.
2. Data Poisoning Attack
The risk: an attacker manipulates training data so the model behaves as they want. OWASP's example is mislabelled spam injected into a spam classifier's training set through a compromised data store.
First defence: treat training data as a controlled asset. OWASP recommends validation and verification, multiple labellers, separation of training and production data, access control, monitoring and auditing, a held-out validation set and ensembles trained on different subsets. The identity point is access control: list every human and pipeline identity that can write to the training bucket or labelling tool, and remove the ones that do not need it.
3. Model Inversion Attack
The risk: the attacker reverse-engineers the model from its outputs to recover information about the people or records it was trained on. OWASP's scenario recovers personal details from a face recognition model.
First defence: limit what the inference API returns and to whom. Require authentication for model endpoints, return a label or a rounded score instead of full probability vectors where the business case allows, and log inputs and outputs so query patterns can be reviewed. OWASP also lists input validation, monitoring and retraining.
4. Membership Inference Attack
The risk: the attacker determines whether a specific record was in the training set, which can itself disclose something sensitive (a patient in a disease cohort, a customer in a debt dataset). OWASP's own description frames it as manipulating training data, which reads oddly: the better-established meaning, used by MITRE ATLAS AML.T0024.000 Infer Training Data Membership, is inference from the model's outputs.
First defence: reduce overfitting (OWASP names L1 and L2 regularisation), add noise or train with differential privacy for sensitive datasets, and minimise the training data. See the Differential Privacy Guide.
5. Model Theft
The risk: the attacker gets the model's parameters, either by stealing the files or by rebuilding a working copy through queries. OWASP's scenario is a competitor reverse engineering a valuable model.
First defence: OWASP lists encryption, strict access control with two-factor authentication, backups, obfuscation, watermarking, legal protection and monitoring. Split the problem in two: weight files are a secrets-style storage problem (see Securing AI Model Weights), while extraction through the API is a rate limiting and query monitoring problem.
6. ML Supply Chain Attacks
The risk: OWASP points out that the ML supply chain has more parts than ordinary software: MLOps platforms, data management and model management tools, and model hubs. Its three scenarios are a tampered Python dependency, an inference platform exposed to the internet without authentication, and an impersonated organisation account on a model hub serving a malicious model.
Evidence: the PyTorch torchtriton attack matched the first scenario, using dependency confusion to collect SSH keys and environment variables from nightly users. ShadowRay matched the second: internet-exposed Ray clusters were used to run code and take cloud keys, AI API tokens and other credentials.
First defence: verify package signatures and hashes, install from vetted sources, never expose MLOps dashboards or job APIs to the internet, and keep cloud and API keys off training and serving nodes where short-lived workload identity can replace them. See the Ray and AI Compute Cluster Security Guide and the MLflow and Kubeflow Security Guide.
7. Transfer Learning Attack
The risk: a pre-trained model carries behaviour the attacker planted, and fine-tuning on your task keeps it. This is the predictive-model version of a backdoored foundation model.
First defence: OWASP lists trusted datasets, monitoring and updating training data, isolating training from deployment, differential privacy and security audits. Add provenance: record where every base model came from, pin it by hash and evaluate the fine-tuned result on triggers and edge cases, not only on accuracy. See the AI Model Provenance and Watermarking Guide.
8. Model Skewing
The risk: the attacker shifts the distribution of data the model learns from, usually through a feedback loop such as user reports or outcome labels that feed retraining.
First defence: OWASP recommends access control over the MLOps system and its feedback loops with logging, authenticity checks on feedback data (signatures and checksums), validation and cleaning, anomaly detection and comparing predictions with real outcomes. Our addition: cap how much any single source can contribute to a retraining batch, so one account or one API client cannot move the model alone.
9. Output Integrity Attack
The risk: the model is fine but its output is changed on the way to the system that acts on it, for example a tampered score between a serving endpoint and a decision engine.
First defence: OWASP lists digital signatures or secure hashes on results, TLS on the channel, validation of results, tamper-evident logs of inputs and outputs, patching and monitoring. Authenticate the consumer and the producer to each other with workload identity or mutual TLS rather than a shared API key.
10. Model Poisoning
The risk: the attacker manipulates the model's parameters directly, without touching the data. Anyone with write access to the model registry or artefact store can do this.
First defence: OWASP mentions regularisation, robust design and cryptographic protection of parameters. The control that does the most is the last one: sign model artefacts at the end of training, verify the signature at deployment, and restrict registry write rights to the training pipeline's own identity. See the AI Model Poisoning Incident Playbook for response.
Mapping to OWASP and ATLAS
The ML list and the OWASP Top 10 for LLM Applications overlap in only a few places. Use the ML list for predictive models and both lists for LLM systems that are also fine-tuned or retrained. ATLAS IDs were checked against the current MITRE ATLAS data (November 2026) and 800-53 IDs against Rev. 5; the mapping is ours.
| OWASP ML | Nearest OWASP LLM 2025 entry | MITRE ATLAS | NIST SP 800-53 Rev. 5 |
|---|---|---|---|
| ML01 Input Manipulation | None (LLM01 Prompt Injection is the language-model analogue) | AML.T0043 Craft Adversarial Data; AML.T0015 Evade AI Model | SI-10, SI-4 |
| ML02 Data Poisoning | LLM04 Data and Model Poisoning | AML.T0020 Training Data Poisoning; mitigation AML.M0007 Sanitize Training Data | SI-7, AC-6 |
| ML03 Model Inversion | LLM02 Sensitive Information Disclosure | AML.T0024.001 Invert AI Model | AC-6, SI-4 |
| ML04 Membership Inference | LLM02 Sensitive Information Disclosure | AML.T0024.000 Infer Training Data Membership | RA-3 |
| ML05 Model Theft | LLM10 Unbounded Consumption (model extraction is one of its scenarios) | AML.T0024.002 Extract AI Model | AC-6, SI-4 |
| ML06 ML Supply Chain | LLM03 Supply Chain | AML.T0010 AI Supply Chain Compromise; mitigation AML.M0014 Verify AI Artifacts | SR-3, SI-7 |
| ML07 Transfer Learning | LLM03 Supply Chain; LLM04 Data and Model Poisoning | AML.T0018.000 Poison AI Model | SR-3 |
| ML08 Model Skewing | LLM04 Data and Model Poisoning | AML.T0031 Erode AI Model Integrity | SI-7, SI-4 |
| ML09 Output Integrity | LLM05 Improper Output Handling (consumer side) | No direct technique; treat as a serving-path integrity control | SI-7 |
| ML10 Model Poisoning | LLM04 Data and Model Poisoning | AML.T0018 Manipulate AI Model | SI-7, AC-6 |
For the full adversarial ML taxonomy behind these categories, see the Adversarial ML Taxonomy Guide.
Where to start
- Inventory models that make security or high-impact decisions. Fraud, abuse, malware, identity verification and credit models get the full list; internal analytics models get ML05, ML06 and ML10 only.
- Close the platform exposure first (ML06). Find MLOps dashboards, job APIs, notebooks and model servers reachable without authentication, and move credentials off those hosts.
- Lock the write paths (ML02, ML08, ML10). One owner per training dataset, feedback source and registry; writes only from the pipeline's own identity; signed model artefacts verified at deployment.
- Harden the inference API (ML03, ML04, ML05). Authentication, per-client rate limits, minimal output detail and query logging reviewed for extraction patterns.
- Add adversarial evaluation to release gates (ML01, ML07). Robustness and trigger tests run on every new model or base model, with results kept as release evidence.
- Measure it. Track the share of production models with signed artefacts, the number of unauthenticated ML endpoints (target zero), identities with write access per training store, and the drift alerts reviewed within your agreed time.
Standards and references
- OWASP: Machine Learning Security Top Ten project
- OWASP: Machine Learning Security Top Ten 2023 risk pages (ML01 to ML10)
- OWASP: Top 10 for LLM Applications 2025
- MITRE: ATLAS (Adversarial Threat Landscape for AI Systems)
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: AI Model Security Guide · AI Threats and Model Security Guide · OWASP Top 10 for LLM Applications Guide · Adversarial ML Taxonomy Guide