MLSecOps applies the DevSecOps habit of building security into the delivery pipeline to machine learning systems. It covers training data, model files, training jobs, deployment and monitoring, because attackers can target any of those stages, not only the application code that wraps the model.
Why is ML security a different problem?
A normal application behaves as its code says. A model behaves as its data taught it. That moves part of the attack surface from code to data and to the artifacts produced from it.
NIST's report on adversarial machine learning (NIST AI 100-2e2025) organizes attacks by the stage of the lifecycle. During training, poisoning attacks occur: in data poisoning an adversary inserts or modifies training samples, and in model poisoning the adversary controls the model and its parameters. During deployment, the trained model faces evasion attacks that change its predictions, and privacy attacks that try to infer sensitive information about the training data or the model. The report also covers attacks specific to generative AI.
DevSecOps tooling does not look at any of that. A dependency scanner will not notice that a training set was altered, and a static analyzer will not see a model whose weights were tampered with.
What stages does MLSecOps cover?
Data. Where did the training and evaluation data come from, who can write to it, and can you reproduce the exact version used for a given model?
Training. Training jobs run code, pull packages and hold credentials to data stores. They deserve the same isolation and secrets handling as a build pipeline.
Model artifacts. A model file is an artifact like a container image. Record where it came from, hash it, store it with access control, and treat formats that can execute code on load as untrusted input.
Serving. Inference endpoints take untrusted input. Rate limits, input validation, logging and abuse monitoring apply, and generative systems add prompt injection and output handling concerns.
Monitoring. Track drift, unusual query patterns and failure cases, and decide in advance what triggers a rollback.
How does it relate to a risk framework?
NIST's AI Risk Management Framework (AI 100-1) organizes work into four functions: Govern, Map, Measure and Manage. It states that these are not a checklist and not necessarily an ordered set of steps. MLSecOps is a way to make the Measure and Manage functions routine, by running checks in the pipeline rather than reviewing them by hand before a launch. Govern still has to come first: someone must own the risk and decide what is acceptable.
A constructed example
A team fine-tunes a classifier on support tickets and deploys it weekly. They add four controls. Training data is stored as versioned, hashed snapshots, and the model card records the snapshot used. The training job runs in an isolated environment with read-only access to that snapshot. The pipeline hashes the output model and refuses to deploy a file whose hash is not in the registry. The endpoint logs inputs and flags clients that send unusually high volumes of near-duplicate queries. None of this is exotic, and each control answers one attack type in the NIST taxonomy.
How to check or apply this
- Inventory your models, their data sources, training code, dependencies and who can deploy them.
- Version and hash datasets and models, and record the link between them.
- Give training and evaluation jobs least-privilege credentials and no outbound access beyond what they need.
- Scan the Python and system packages in training and serving images the same way you scan applications.
- Test models for the attack types that fit your use case, using the NIST taxonomy as the checklist, and write down what you decided not to defend against.
- Log and monitor inference traffic, with a documented rollback path.
Safeguard's SBOM and dependency scanning cover the packages around a model, and its MCP Guardrail and agent identity features apply when models act through tools. They do not replace data governance or model evaluation work.
Quick check
Is MLSecOps just DevSecOps with a new name?
No. It borrows the idea of automated checks in the pipeline, but the assets and attacks differ. Data poisoning, model tampering and evasion have no direct equivalent in an ordinary build.
Do we need MLSecOps if we only call a hosted model through an API?
You skip training and hosting risks, but you still own input handling, prompt injection exposure, secrets, logging and the dependencies in your own application. Scope the practice to what you operate.
Sources
- NIST AI 100-2e2025, Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations
- NIST AI 100-1, Artificial Intelligence Risk Management Framework 1.0
Last reviewed: 18 October 2026.
