Model Lifecycle and MLOps Security
Model lifecycle and MLOps security
This domain tests control of the model after development: versioning, promotion, deployment, monitoring handoff and retirement. It is about the pipeline and the registry, not the code review that produced the model.
Core rules
- The model registry is the source of truth: immutable versions, lineage to data and code commit, approval status, and who promoted what.
- Separate environments and enforce promotion gates: evaluation results, security scan, bias and memorization tests, and an accountable approver.
- Protect model weights as high-value assets - they enable theft, cloning and offline attack. Restrict registry read access and log downloads.
- Feature stores and training data snapshots need the same access control and change tracking as production databases.
- Deployment patterns: canary and shadow releases, signed artifacts, rollback to a known-good version, and configuration managed as code.
- Retirement matters: revoke keys and endpoints, archive artifacts and logs per retention policy, and delete data where required.
Worked example
A fraud model shows a 12% precision drop after a pipeline refactor. Reasoning: compare the registry lineage of the deployed version against the previous one, confirm the feature definitions and training snapshot hashes match, and check whether an upstream feature job changed. The fix is a rollback to the last approved version plus a re-run of evaluation gates before re-promotion - not an ad hoc retrain on current data, which would destroy the evidence trail.
Traps
- Versioning code but not data snapshots or feature definitions.
- Letting engineers promote straight to production without a gate.
- Leaving old model endpoints and API keys live after retirement.
- Assuming drift is a quality issue only, not a security signal.