Why do exposed model registry tokens create supply-chain risk?

Why This Matters for Security Teams

Exposed model registry tokens are dangerous because they turn a single credential leak into a trusted path for tampering. A registry token can often publish, overwrite, or retag artifacts that downstream pipelines and applications assume are legitimate. That makes the risk supply-chain oriented, not just account-oriented. The OWASP Non-Human Identity Top 10 treats overprivileged machine credentials as a core control problem, and NHIMG research on Guide to the Secret Sprawl Challenge shows why secrets that are easy to distribute are also hard to contain.

Once a model artifact is altered, the impact can propagate through CI/CD, inference services, evaluation jobs, and downstream consumers that do not revalidate provenance on every pull. Current guidance suggests treating registry tokens as production-grade supply chain credentials, not convenience secrets. In practice, many security teams discover the exposure only after a suspicious artifact has already been consumed by multiple services, rather than through intentional review.

How It Works in Practice

Model registry tokens usually sit at the intersection of build systems, training jobs, deployment automation, and human workflows. If a token grants write access, an attacker does not need to compromise the model itself, only the control plane that publishes it. That is why a leaked token can be used to swap a safe model for a poisoned one, push a malicious dataset version, or alter metadata that changes what a deployment pipeline trusts.

Operationally, teams should separate read and write permissions, scope tokens to a single project or environment, and prefer short-lived credentials over long-lived shared secrets. The strongest pattern is to issue tokens just in time for a narrowly defined task, then revoke them automatically after use. For machine-to-machine identity, workload identity is a better primitive than static secrets because it establishes what the system is at runtime, not just what credential it copied. Standards such as NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 both support stronger identity governance, while NHIMG’s 52 NHI Breaches Analysis shows how reused credentials repeatedly become entry points for broader compromise.

• Use separate tokens for read, write, and administrative actions.
• Bind registry access to workload identity where possible.
• Set short TTLs and revoke on job completion, not on a human schedule.
• Verify artifact provenance before promotion to higher environments.
• Monitor for unusual tag changes, overwrites, and bulk pulls.

These controls tend to break down when model publishing is shared across many teams with legacy automation, because broad tokens become embedded in scripts and release processes that are difficult to unwind quickly.

Common Variations and Edge Cases

Tighter registry controls often increase release overhead, requiring organisations to balance deployment speed against tamper resistance. That tradeoff is real in environments with frequent retraining, multiple registries, or federated teams that publish models from different regions or business units.

Best practice is evolving for cases where registries support both human and agentic workflows. Some environments can enforce policy at the registry boundary, while others need controls deeper in the pipeline, such as signed artifacts, immutable tags, and approval gates for production promotion. Where model registries are mirrored across clouds, the exposure expands because one token may be accepted in several places unless trust boundaries are explicitly separated. The Salesloft OAuth token breach is a useful reminder that a valid token can still create broad downstream harm even when the initial leak seems narrow.

There is no universal standard for this yet, but current guidance is to combine least privilege, short-lived issuance, artifact signing, and continuous revocation checks. If those controls are missing, exposed model registry tokens become a supply-chain problem because the attacker can change what downstream systems trust, not just what a single account can see.

Related resources from NHI Mgmt Group

• Why do developer workspaces create supply-chain risk when identity is misvalidated?
• Why do CI/CD secrets create such a large blast radius in supply chain attacks?
• Why do exposed vector databases create more risk than a simple data leak?
• Why do short-lived OIDC tokens still create meaningful supply chain risk?