MLSecOps is the discipline of integrating security practices into the machine learning lifecycle, in the way DevSecOps integrates security into software delivery. It spans data security, model security, supply chain security for ML dependencies, runtime monitoring, and incident response for machine learning systems.
- Security built into the ML lifecycle rather than added after a model ships
- Spans data, model, supply chain, runtime monitoring, and incident response
- The framing engineering teams adopt once bolt-on security proves inadequate
- Evaluate tooling by lifecycle stage covered, not only by threats detected
Why is MLSecOps important?
MLSecOps matters because it is the operational framing most engineering organizations reach for once they realize ML security cannot be bolted on after the model ships. The parallel with DevSecOps is exact: the same recognition, arriving a decade later for a different asset class.
The reason bolt-on fails is that several ML risks are decided before deployment. Training data provenance and dependency selection are both settled during development, and no runtime control recovers a poisoned dataset or an unlicensed corpus. By the time a model reaches production, some of its security properties are already fixed.
Practice is consolidating around shared standards, with the Linux Foundation's OpenSSF and NIST converging on common approaches alongside a growing practitioner community. That makes the discipline easier to adopt than it was when every organization improvised. The buying implication is specific: evaluate tooling by which lifecycle stages a vendor covers rather than only by which threats it detects, because a product covering one stage well can leave the rest untouched.
What is MLSecOps?
MLSecOps is the practice of embedding security controls and review into every stage of the machine learning lifecycle, from data acquisition through deployment and monitoring. It is a process discipline rather than a product category, and it usually requires ML engineering and security to share ownership.
Five domains make it up. Data security covers provenance, integrity, access control, and handling of sensitive material in training and retrieval sets. Model security covers protection of model artifacts and resistance to adversarial manipulation, along with evaluation before release. Supply chain security covers ML dependencies and pretrained models, plus the frameworks a pipeline is built on. Runtime monitoring covers behavior in production, including drift and anomalous use. Incident response covers what happens when an ML system fails or is attacked, which requires playbooks most organizations do not yet have.
MLSecOps overlaps with AI security posture management and differs in emphasis. Posture management assesses systems as they exist. MLSecOps is concerned with how they came to exist, and with keeping security decisions inside the pipeline that produces them.
Types of MLSecOps practices
Practices group by lifecycle stage, which is also the axis worth using in a tooling evaluation.
Data-stage practices cover dataset provenance tracking, integrity verification, poisoning resistance, and classification of sensitive content. Controls are preventive, and gaps here cannot be closed later.
Development-stage practices cover dependency scanning, pretrained model vetting, secure pipeline configuration, and secrets management in training code. These map closely onto existing DevSecOps tooling.
Evaluation-stage practices cover adversarial testing, red teaming, bias and robustness assessment, and release gating. This is where a model's readiness is decided rather than assumed.
Deployment-stage practices cover access control, isolation, artifact signing, and version tracking into production.
Runtime practices cover monitoring, drift detection, inference-time inspection, and incident response. This is the stage that overlaps most with AI runtime security, and the one an enterprise consuming third-party models has the most control over.
MLSecOps & Onyx
Onyx integrates with the MLSecOps lifecycle by providing inventory, posture, and runtime evidence that the ML engineering team and the security team can share. The shared artifact is the point: most MLSecOps friction comes from the two groups working off different records of what exists and what state it is in.
In practice Onyx contributes to the deployment and runtime stages, with discovery establishing which models and agents reached production, posture scoring assessing exposure and privilege, and inline inspection covering inference and tool use. The data and development stages remain the ML team's ground, and Onyx contributes supply chain visibility across models, agents, and MCP servers rather than controls inside the training pipeline. Being clear about that division is more useful than claiming the full lifecycle.
