Use package identity, provenance and approval status as the control points for promotion. The goal is to make every model or agent artefact traceable from import to production, with scanning and attestation attached to the same object that is deployed. That reduces the chance of unreviewed content slipping into a live environment.
What “govern” means in a self-hosted AI supply chain
For self-hosted deployments, governance starts with treating the AI artefact as a controlled release object, not a loose dependency. That includes model files, adapters, prompts, agent packages, tool plugins, and any packaging metadata that determines what actually runs. If teams cannot name the artefact, prove where it came from, and show who approved it, they do not really control promotion.
Package identity should be the first stable control point because it lets teams track one object through import, inspection, approval, and deployment. The practical question is not just whether a model is “trusted”, but whether the exact version, source, and approval state are bound together so the deployed object is the same one that was scanned and reviewed.
This is why the governance model should follow the artefact across environments. The same object should carry the evidence needed to move forward, including provenance records, scanning results, policy decisions, and any exceptions granted for a limited time. If those records live in separate systems and can drift apart, the promotion process becomes easy to bypass.
Which controls should gate promotion into production?
Promotion should be blocked unless the artefact has passed a defined set of checks that travel with it. At minimum, teams need source traceability, provenance attestation, malware and dependency scanning, license or policy review where relevant, and an explicit approval state that cannot be overwritten informally after the fact. A release candidate that lacks one of those properties should remain quarantined, not “temporarily allowed” into production.
The strongest control pattern is to tie attestation to the same artefact identifier that is deployed. That way, the system can verify both the content and the decision history before it allows rollout. This is especially important for self-hosted environments because teams often assume they are safer than hosted services, even though the real risk is unreviewed code or model content entering a trusted internal runtime.
When the deployment process supports it, use a promotion workflow that distinguishes import, staging, and production as separate trust states. A package can be present in an internal registry without being approved for execution. That separation matters because a repository mirror, cache, or artifact store is not the same thing as a deployment decision.
For teams building an AI programme discipline around the full lifecycle, the AI Supply Chain Security and AI-BOM Guide is the clearest starting point because it maps models, data, packages, tools, and supporting components into a single governance model.
How do teams make provenance and approval operational?
Governance becomes real when provenance is machine-checkable and approvals are attached to a specific artefact digest, not a human memory or ticket comment. Teams should expect every promotion to answer three questions: what is this object, where did it come from, and why was it allowed to progress. If any one of those answers is missing, the object should not be promoted automatically.
Self-hosted environments also need a clear boundary between the source-of-truth repository and the runtime copy. Pulling an artefact into the cluster or server is not enough. The deployment should validate signature, digest, and approval status at the point of use, because supply chains fail when trust is assumed once and never rechecked.
Approval status is most useful when it is narrow and revocable. Treat approval as a time-bound policy decision tied to one version or one family of artefacts, not as a permanent trust label. That lets teams revoke a problematic package quickly if a new issue appears after release.
When the goal is to prevent unreviewed content from reaching production, the most important evidence is often the promotion record itself. Teams should be able to show the artefact identity, the scan results, the attestation, and the approver without reconstructing the trail from multiple tools after an incident.
Risk and Threat Considerations
Self-hosted ai supply chain fail when teams confuse internal hosting with internal trust. Malicious or unreviewed content can enter through package registries, model hubs, dependency managers, CI pipelines, or cached artefacts, then move quickly once it inherits production deployment privileges.
Failure mechanism: The attacker or defective release does not need to compromise the runtime first. It is enough to poison the import path, hide in a dependency, or exploit weak promotion controls so the wrong artefact is approved and deployed as if it were trusted.
Impact: The result can be model tampering, hidden backdoors, unsafe tool use, data exposure, or lateral movement through systems that trust the deployed artefact. In mature environments, the main loss is often not just a bad release, but the collapse of traceability needed to prove what actually ran.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while SLSA sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Self-hosted AI supply chains depend on trusted third-party artefacts and provenance. |
| NHI-05 — Overprivileged NHI | Promotion paths and deployers need least privilege to stop unsafe artefact release. | |
| NHI-07 — Long-Lived Secrets | AI supply chains often fail through exposed tokens used to publish or promote artefacts. | |
| Recommendation — Require provenance and approval checks before promoting third-party AI artefacts. Limit release and deployment privileges to the smallest approval set possible. Rotate publishing and deployment secrets used in AI release pipelines. | ||
| OWASP Agentic AI Top 10 | ASI04 — Agentic Supply Chain Vulnerabilities | Agent artefacts, tools and packages need provenance control before production use. |
| Recommendation — Verify artefact provenance and approval before deploying agent components. | ||
| SLSA | Supply-chain Levels for Software Artifacts | The question is about provenance and promotion integrity for deployed artefacts. |
| Recommendation — Adopt provenance and integrity checks for every artefact promotion step. | ||
Practitioner Guidance
What to prioritise: Start by defining the artefact boundary. Decide whether your promotion object is the model alone, the model plus adapters, the agent package, or the full deployable bundle, then enforce one identity for that object across registry, scan, and release steps.
What to verify: Before trusting the control, verify that approval cannot be granted to one version while a different version is deployed. If the attestation, scan result, and deployed digest are not bound to the same object, the process is not yet governable.
Common mistake: Teams often secure the repository but ignore the promotion path. That leaves a gap where artefacts can be copied, repackaged, or replayed into production without the original review context.
Practitioner takeaway: The control goal is not to inspect every AI component perfectly, but to ensure that nothing can cross from import to production without a provable identity, a current approval state, and evidence that follows the exact deployed object.
Related resources from NHI Mgmt Group
- How should security teams govern API keys used for generative AI access?
- How should security teams govern self-hosted AI models alongside commercial APIs?
- How should teams govern AI and cryptographic inventory alongside software supply chains?
- How should enterprises govern hybrid AI deployments with self-hosted and external models?