MLOps

Expanded Definition

MLOps is the operating model that turns machine learning from a one-time build into a governed production capability. It covers data pipelines, training runs, model versioning, evaluation gates, release approval, rollback, and post-deployment monitoring. In NHI security, MLOps matters because the pipeline itself relies on non-human identities, secrets, and automated execution rights.

Definitions vary across vendors, but the core distinction is consistent: DevOps focuses on application delivery, while MLOps adds model-specific controls such as data drift detection, feature lineage, reproducibility, and performance thresholds. That makes MLOps a governance discipline as much as an engineering practice. It should be aligned to control expectations in the NIST Cybersecurity Framework 2.0, especially where automated systems need monitored, authorized, and recoverable changes.

The most common misapplication is treating MLOps as a packaging workflow, which occurs when teams automate deployment without controlling training data, model approvals, or downstream secret exposure.

Examples and Use Cases

Implementing MLOps rigorously often introduces release friction, requiring organisations to weigh faster model iteration against stronger approval, observability, and rollback controls.

• A finance team trains a fraud model in a pipeline that records dataset lineage, signs the model artifact, and blocks promotion until validation metrics meet policy thresholds.
• A healthcare provider monitors production drift and alerts on degraded performance before model output affects triage decisions, while restricting pipeline access to tightly scoped service identities.
• An engineering team stores training credentials in a secret manager rather than code, reducing exposure during automated retraining jobs. This is especially relevant after patterns seen in the Hugging Face Spaces breach.
• A product team uses canary deployment for a recommendation model and compares live outcomes against a baseline before full rollout, limiting blast radius if behavior shifts unexpectedly.
• A security group requires approval for any model promotion that changes data sources, feature sets, or external tool access, because those changes can alter both accuracy and risk posture.

In practice, MLOps also overlaps with identity governance when pipeline actors use API keys, short-lived tokens, and orchestrator accounts. For implementation patterns, the NIST Cybersecurity Framework 2.0 is useful for mapping the monitoring and recovery side of the workflow.

Why It Matters in NHI Security

MLOps becomes a security issue the moment model pipelines run with broad, persistent, or poorly inventoried non-human identities. NHIMG research shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 71% fail to rotate NHIs on time. In an MLOps stack, those weaknesses can expose training jobs, artifact registries, feature stores, and deployment controllers.

That risk is amplified because model lifecycle tooling often spans cloud platforms, CI/CD systems, notebook environments, and orchestration layers. If provenance is weak, an organisation may not know which dataset, prompt, artifact, or credential was used to generate a live model. If monitoring is weak, drift or poisoning can persist until business impact is visible. MLOps also creates a direct path from data compromise to operational compromise when a service account can retrain, deploy, and invoke production models without separation of duties.

Organisations typically encounter the need to formalize MLOps only after a bad model release, a secrets leak, or an unauthorized retraining event, at which point MLOps becomes operationally unavoidable to address.