A small, named group, and fewer people than can train or experiment. Separate the right to write a model from the right to promote it, require a second reviewer, and record what was checked. A registry that lets any contributor overwrite the production model is a deployment path with no review.
Why promotion is a security event
A model in production runs inside your service and may be loaded from a file that can contain code. Changing it changes behavior for customers. Promotion deserves the same care as merging to a main branch, and often more, because tests for model behavior are weaker than tests for code.
Use graded permissions
Registry tools differ, but the pattern is common. As an example, MLflow's basic authentication defines five levels: READ, USE, EDIT, MANAGE and NO_PERMISSIONS. READ is read only, USE adds use, EDIT adds update, and MANAGE adds delete and managing others' access. The default for a user is READ.
| Role | Suggested level |
|---|---|
| Researcher experimenting | EDIT on their own experiments |
| Training pipeline account | EDIT on one experiment and its registered model |
| Serving system | READ or USE on the production model |
| Release owner | MANAGE on registered models, kept to a few people |
| Everyone else | READ or none |
Map your own tool's permissions onto this, and avoid giving the serving system anything beyond reading.
Checks before promotion
- Provenance. Which code, data and base model produced it? Link the run and the commit.
- File format. Prefer formats that cannot carry code, and scan files you did not create.
- Dependencies. Scan the training and serving environments for known vulnerabilities.
- Behavior tests. Run your evaluation set and a few adversarial cases.
- License and data review. Confirm the data and base model licenses allow the use.
- Second approval. Someone other than the author approves.
- Rollback. Keep the previous version ready, and test the rollback.
Record the decision
Store who approved, when, which checks passed, and the digest of the model file. That record is also the kind of evidence an auditor or customer may ask for. See model intake policy for engineering teams and what a model signature does not tell you.
Common failure modes
- A shared service account that every pipeline uses, so you cannot tell who promoted what.
- Promotion by overwriting a file in a bucket that many people can write to.
- No record linking the deployed model to its training run.
- Admin rights granted for convenience and never removed.
A first month plan
Week one, list who can write to the registry and storage. Week two, remove write access that is not needed. Week three, add the second approval. Week four, test a rollback.
Safeguard's policies, gates and guardrails and its compliance and evidence automation can support approval records and enforce rules on changes. A free scan is at gold.safeguard.sh/scan.
Quick check
Should the training pipeline be able to promote?
Usually not. Let it register a candidate, and let a person or gated process promote it.
Is one reviewer enough?
It is a good start. Use more for high impact models.
Sources
Last reviewed: 19 October 2026.
