Security teams should assume every dependency is part of the attack surface, not just the application code. Use pinned and reviewed packages, isolate AI infrastructure inside a private cloud boundary, and keep secrets out of externally reachable paths. Treat CI/CD tools, package registries, and build runners as high-risk components that need continuous audit, provenance checks, and rapid rebuild procedures.
Why This Matters for Security Teams
AI infrastructure inherits the trust model of software delivery, which means package registries, build tools, model artifacts, and CI/CD runners can become entry points long before any model is deployed. The risk is not limited to malicious code in a package. It also includes tampered build scripts, dependency confusion, compromised service identities, and exposed secrets that let an attacker move from a development system into production AI workloads. Guidance from the NIST Cybersecurity Framework 2.0 is clear that governance, protection, detection, and recovery all need to extend across the full delivery chain.
Security teams often underestimate how quickly trust propagates through build automation. Once a runner, registry token, or signing key is accepted by default, every downstream artifact inherits that trust unless it is actively constrained. That is why AI supply chain risk should be treated as both a software integrity problem and an identity problem, especially where non-human identities control pipelines, package access, and deployment permissions. In practice, many security teams encounter this only after a poisoned dependency, leaked token, or compromised build runner has already been used to sign and distribute trusted artifacts.
How It Works in Practice
Reducing supply chain risk in AI infrastructure starts with limiting implicit trust at each stage of the lifecycle. Packages should be pinned, reviewed, and sourced through controlled repositories. Build environments should be isolated, ephemeral where possible, and prevented from reaching secrets or production systems unless strictly required. Provenance checks should verify what was built, by whom, and from which inputs, while artifact signing and verification should prevent tampering after the build completes.
Operationally, teams should separate controls across code, infrastructure, and identity:
- Restrict package installation to approved sources and block ambiguous or unapproved namespace lookups.
- Use short-lived credentials for build runners and avoid long-lived registry tokens where possible.
- Store secrets in dedicated vaults and inject them only at execution time, not into source control or build logs.
- Require signed artifacts, verified provenance, and repeatable rebuild procedures for critical AI components.
- Monitor non-human identities that can publish, promote, or deploy packages, because those accounts often carry the highest trust.
This is where the OWASP Non-Human Identity Top 10 becomes especially relevant: compromised service accounts, API keys, and workload identities can silently turn a clean pipeline into a trusted distribution channel for malicious code or model dependencies. NIST SP 800-53 Rev 5 Security and Privacy Controls provides the control basis for configuration management, access enforcement, audit logging, and system integrity checks that make this approach enforceable rather than aspirational. These controls tend to break down when build systems are shared across teams, because broad runner access and inconsistent logging make it difficult to trace which identity introduced a risky dependency.
Common Variations and Edge Cases
Tighter supply chain control often increases build overhead, requiring organisations to balance delivery speed against artifact integrity and investigative depth. That tradeoff is especially visible in fast-moving AI teams that rely on frequent model retraining, experimental dependencies, or ephemeral test environments.
Best practice is evolving for agentic AI and model-centric pipelines, where a package may not only contain code but also prompt templates, tool definitions, or orchestration logic. In these environments, dependency review should extend beyond traditional software packages to include configuration files, model weights, and agent tool manifests. There is no universal standard for this yet, but current guidance suggests treating every externally sourced input as potentially executable if it influences model behaviour or tool use.
Edge cases also appear in air-gapped or private-cloud deployments. Isolation reduces exposure, but it does not eliminate trust risk if the organisation imports unsigned artifacts, mirrors public registries without validation, or reuses broad service identities across environments. Teams should also distinguish between build-time and run-time trust: a package that is safe to inspect in a sandbox may still be unsafe to grant production credentials. For AI systems that depend on external model hubs, the control goal is not just to block untrusted code, but to prove provenance for the exact artifact that reaches inference or training.
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 MITRE ATLAS address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.SC-1 | Supply chain risk management applies directly to trusted-by-default AI build paths. |
| NIST AI RMF | AI RMF addresses governance and integrity risks across the AI lifecycle. | |
| OWASP Non-Human Identity Top 10 | Non-human identities often hold the trust that attackers abuse in pipelines. | |
| NIST SP 800-53 Rev 5 | SA-12 | Control-focused supply chain protections support provenance and integrity assurance. |
| MITRE ATLAS | AML.T0049 | ATLAS captures adversarial manipulation of ML assets and dependencies. |
Map AI delivery dependencies and providers, then enforce review and monitoring for high-risk suppliers.
Related resources from NHI Mgmt Group
- How can security teams reduce risk from supply-chain identities and build tokens?
- How should security teams reduce risk from supply chain compromise and trusted software paths?
- How should security teams reduce supply chain risk from malicious build dependencies in Rust projects?
- How should security teams reduce the risk of secret theft from npm supply chain attacks?
