Model and dataset registry security: Controlling Who Can Publish, Promote and Load AI Artefacts

A model registry decides which weights reach production, yet in many organisations anyone with a write token can register a new version, move the production alias to it, and have serving infrastructure load it on the next deploy. Model and dataset registries (MLflow Model Registry, Amazon SageMaker Model Registry, Hugging Face Hub organisations and their cloud equivalents) are the control point between training and serving, and they deserve the same rigour as a software release pipeline. This guide covers access models, promotion controls, integrity and provenance records, dataset versioning, and the tokens and service accounts that read and write these registries. It is written for ML platform engineers, MLOps leads and security architects; it goes deeper on the registry itself than the broader Model Supply Chain Guide.

Key takeaways

• Separate who can register from who can promote. Registering a candidate version and moving a production alias or approval status are different privileges and should belong to different identities.
• Aliases are mutable pointers. MLflow aliases such as @champion and approval states in SageMaker trigger deployments, so changing them is a production change that must be logged, reviewed and alerted on.
• Bind every version to evidence. A registered version should carry its training run, dataset version, file hashes, signature and evaluation results, or it should not be promotable.
• Datasets need the same controls as models. Write access to a heavily downloaded dataset is a poisoning path; version, pin and restrict it like model weights.
• Registry tokens are high-impact NHIs. Leaked write tokens let an attacker replace a model that many users download; use fine-grained, per-repository tokens owned by service accounts.

What a registry controls, and why it is an attack surface

A registry records named models, numbered versions, and metadata. In MLflow each registered model has versions starting at 1, tags, descriptions, and lineage to the run or logged model that produced it. In SageMaker, model packages are versioned inside model package groups, each version has a ModelApprovalStatus, and with the SageMaker project templates a change from PendingManualApproval to Approved initiates CI/CD deployment. On the Hugging Face Hub, models and datasets are git repositories in an organisation namespace, so every push is a new commit.

That makes the registry a target for three things: replacing an artefact (a poisoned or malicious version under a trusted name), redirecting a pointer (moving an alias or approval to an attacker's version) and reading private artefacts (weights and datasets that are intellectual property or contain personal data). MITRE ATLAS records these under AI Supply Chain Compromise (AML.T0010, with Data AML.T0010.002 and Model AML.T0010.003 sub-techniques), Publish Poisoned Models (AML.T0058) and Manipulate AI Model (AML.T0018). OWASP LLM03:2025 Supply Chain notes that model cards give no guarantee of origin and that an attacker can compromise a supplier account on a model repository. See the OWASP LLM Top 10 LLM03 Supply Chain Guide.

Access models compared

Whatever the platform, define three roles per model family: producer (training pipeline identity that may register new versions), approver (a human group or gated pipeline that may change aliases or approval status) and consumer (serving identity with read access to approved versions only). Human data scientists should normally have producer rights in a development registry and read rights in production. Platform guidance is in the MLflow and Kubeflow Security Guide, the Amazon SageMaker Security Guide and the Hugging Face Security Guide.

Promotion controls: aliases, stages and approvals

MLflow deprecated model stages in version 2.9.0 in favour of aliases and tags, and an alias is a mutable, named reference: reassigning champion to another version changes what production serves. SageMaker approval status works the same way through its CI/CD templates, and moving a version from Approved to Rejected triggers deployment of the latest version still marked Approved. Controls that make promotion safe:

• Gate on evidence: allow promotion only when the version carries required tags, for example the MLflow docs' own example of pre_deploy_checks: "PASSED" or validation_status, written by the evaluation pipeline identity, not by the person requesting promotion.
• Two-person rule: the identity that registered a version must not be the one that promotes it.
• Serve by immutable reference: have serving resolve the alias at deploy time and record the concrete version and file digest it loaded, so an alias change after deployment is visible.
• Rollback by pointer: keep the previous approved version available and roll back by moving the alias, which is faster and safer than re-registering.

Integrity and provenance records

The Hugging Face Hub runs every file under 2 GB through a malware scanner at each commit and scans pickle files, and its documentation advises loading models from trusted users and organisations, relying on signed commits and preferring formats that do not execute code on load. Scans are a signal, not a guarantee: OWASP notes that static inspection of model binaries offers little assurance about hidden backdoors. Git signing only proves the committer; it does not prove the weights are safe.

Dataset registries and versioning

• Version and pin: train from a specific dataset commit or snapshot and record it on the model version. Never train from a moving "latest".
• Restrict writes: the Lasso research behind the Hugging Face API tokens exposure found 655 leaked tokens with write permission and said write access could have altered 14 heavily downloaded datasets. Dataset write rights belong to a curation pipeline, not to every contributor.
• Gate access to sensitive data: use private repositories or gated datasets, and resource groups to keep them visible only to authorised members.
• Track provenance and licence: see the AI Training Data Provenance and Copyright Exposure Guide, and the AI Data Poisoning and Backdoors Guide for poisoning controls.

Where identity fits

Most registry writes are made by non-human identities: training pipelines, evaluation jobs and deployment controllers. Hugging Face user access tokens come in read, write and fine-grained roles, and an organisation member's token acts with both the token's permission and the member's organisation role, so a personal write token can push to every organisation repository the person can write to. On Enterprise plans, service accounts are organisation-owned identities with no password and no interactive sign-in, accessed only through fine-grained tokens scoped organisation-wide or per repository, with rotation that invalidates the previous token immediately. Team and Enterprise organisations can also enforce a token policy of "Only access via fine-grained tokens" or "Require administrator approval". The equivalent on cloud registries is a dedicated IAM role per pipeline. In every case: one credential per pipeline, scoped to the repositories it needs, owned by a service account rather than a person, held in a secrets manager. See the CI/CD Pipeline Identity Security Guide.

How to implement

1. Inventory: list every registry, model, dataset, alias or approval workflow and the identities with write or promote rights. Record it in the AI Register and AI Inventory Template.
2. Cut default access: change MLflow's default permission from READ where models are sensitive, move Hub members to no_access or contributor plus resource groups, and remove personal write tokens from pipelines.
3. Split roles: create producer, approver and consumer identities per model family and test that the producer cannot promote.
4. Require evidence tags: start in report-only mode, listing promoted versions that lack lineage, dataset version, digests or evaluation tags; then block promotion without them.
5. Add signing and verification: sign at registration and verify at load in serving, failing closed on a missing or invalid signature after a pilot period.
6. Turn on audit and alerts: export registry audit logs to the SIEM and alert on alias and approval changes.
7. Rollback plan: document the previous approved version for each production model and rehearse an alias rollback.

Decision guidance

• Self-hosted MLflow or managed registry: self-hosted MLflow gives control but you own authentication, TLS and the backing store; managed registries inherit cloud IAM and logging, which suits regulated teams.
• Public hub or internal mirror: pulling third-party models directly from a public hub at serving time ties production to someone else's account security. Larger organisations should mirror approved versions into an internal registry pinned by commit and digest.
• Small teams: at minimum use fine-grained tokens per pipeline, pin by commit or version number, and require a second person for production alias changes.

Detection and measurement

• Events to alert on: alias or approval change outside a change window, a new version registered by a human identity in production, deletion or rename of a model repository, permission or token policy changes, and downloads of private models by unfamiliar identities. Hub audit logs record who acted, the action, a description, anonymised IP and time, and can be exported through the organisation audit log API.
• Metric: evidence coverage: percentage of production model versions with lineage, dataset version, digests, signature and evaluation tags.
• Metric: write surface: number of identities with write or promote rights per production model; trend down.
• Metric: token hygiene: percentage of registry tokens that are fine-grained and owned by service accounts, and age of the oldest unrotated token.
• Metric: pinned consumption: percentage of serving deployments that load by immutable version and verify the digest.

Framework mapping

Common failure patterns

• Personal write tokens in pipelines: a leaked token carries the owner's full organisation write rights, as the 2023 Hugging Face token exposure showed.
• Anyone can move the alias: registration and promotion rights are the same, so a compromised notebook can redirect production.
• Default READ for all users: private models and prompts are readable by every authenticated user of a shared tracking server.
• Loading by name and "latest": serving resolves the newest version at start-up, so any new registration goes live without review.
• Trusting scan badges as proof: malware scanning finds known malware, not backdoored weights.
• Datasets left open: models are locked down while the datasets that train them accept writes from many contributors.

Practitioner checklist

• Inventory registries, models, datasets, aliases and every identity with write or promote rights.
• Separate producer, approver and consumer identities and test that producers cannot promote.
• Remove broad default read access on shared registries holding sensitive models.
• Replace personal tokens with fine-grained, per-repository tokens owned by service accounts.
• Require lineage, dataset version, digests, signature and evaluation tags before promotion.
• Serve by immutable version and verify digests or signatures at load time.
• Pin datasets by commit or snapshot and restrict dataset writes to a curation pipeline.
• Export registry audit logs and alert on alias, approval, permission and token policy changes.
• Rehearse rollback by alias for every production model.

Standards and references

• MLflow: Model Registry documentation
• MLflow: Authentication and permissions documentation
• AWS: Amazon SageMaker developer guide, Model Registry
• Hugging Face: Hub documentation (tokens, organisations, resource groups, service accounts, audit logs, malware and pickle scanning)
• OWASP: Top 10 for LLM Applications 2025
• MITRE ATLAS: AI Supply Chain Compromise
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: Model Supply Chain Guide · Model Signing and OpenSSF Model Signing Guide · MLflow and Kubeflow Security Guide · Hugging Face Security Guide · Non-Human Identity (NHI) Guide