AI supply chain risk splits into three surfaces for practitioners

At a glance

What this is: ARMO breaks AI supply chain risk into three distinct surfaces, arguing that ordinary SCA only covers component vulnerabilities while missing model integrity and behavioural payloads.

Why it matters: IAM, NHI, and AI security teams need separate governance for runtime-loaded models, tools, and skills because pre-installation scanning alone cannot verify what actually executes in production.

Context

AI supply chain risk is broader than package hygiene. In AI workloads, the thing that fails is often not a dependency version but a runtime-loaded model, tool, adapter, or agent skill that never appeared in the original manifest. That creates a governance gap for identity, access, and trust decisions because the security model has to follow what loads and executes, not just what was declared at build time.

The practical boundary matters for AI governance and NHI security alike. If teams treat model artefacts, MCP tools, and agent skills as ordinary software packages, they will keep getting a clean scan against the wrong target. The result is a control gap that looks like compliance but leaves runtime behaviour, delegated access, and third-party supply paths largely unverified.

Key questions

Q: What breaks when AI supply chain scanning only covers packages and CVEs?

A: The scan becomes blind to runtime-loaded tools, model artifacts, and agent instructions that never appear as ordinary dependencies. That means a green SCA result can coexist with poisoned adapters, unsafe deserialisation paths, or malicious MCP behavior. Teams need separate controls for each surface, plus runtime evidence to confirm what actually executed.

Q: Why do model artefacts create supply chain risk even when no CVE exists?

A: Because the threat is the artefact itself, not a published vulnerability record. Model files can be poisoned, swapped, or loaded in ways that execute code or alter behaviour at runtime, so integrity and provenance matter more than traditional version tracking.

Q: How do security teams detect malicious MCP tools or agent skills?

A: They need two checks: review the instruction layer as a security artefact, then measure runtime behaviour against the declared work envelope. Code scanning alone is insufficient because the implementation may be benign while the description or tool intent is not.

Q: When should organisations prioritise runtime evidence over pre-installation scanning for AI workloads?

A: Whenever the workload dynamically loads models, tools, or skills after deployment. In those cases, pre-installation scanning is only a gate for declared inputs, while runtime evidence is the only way to confirm what actually executed and what access paths were opened.

Technical breakdown

Why SCA only sees one AI supply chain surface

Standard software composition analysis assumes a dependency graph of versioned packages with published CVEs. That works for AI framework code such as LangChain or vLLM, but it fails once workloads dynamically load tools, plugins, adapters, or model files at runtime. The scanner can only assess what was declared in the manifest, while AI systems often expand their effective attack surface after deployment. That is why a green pre-installation scan can coexist with real operational risk. Practical implication: use SCA for package-level issues, but do not treat it as proof of AI workload safety.

Practical implication: Pair package scanning with runtime evidence so findings reflect what the workload actually loads and executes.

Model artefact integrity is not a CVE problem

Model weights, fine-tunes, and LoRA adapters are not ordinary code dependencies. They can carry unsafe serialisation, poisoned training influence, or malicious behaviour that appears only when the artefact is loaded or invoked. Some formats, especially pickle-based ones, can execute code at load time, while others can be swapped through namespace or registry abuse without changing the manifest reference. This is a supply chain integrity problem, not a version-management problem. Practical implication: verify model files at load time and prefer safer artefact formats where the workflow allows it.

Practical implication: Treat every model load as a verification event, not a one-time build artefact check.

Behavioural payloads in MCP tools and agent skills

The third surface is the most unfamiliar: the payload lives in the natural-language description, tool spec, or skill instructions that shape agent behaviour. A malicious MCP tool can describe one action while quietly steering the agent toward data exfiltration, unsafe delegation, or policy bypass. Code scanning alone will miss this because the implementation may do exactly what the description says. This is where AI security and NHI governance overlap, because delegated tool use becomes an access problem as much as a software problem. Practical implication: baseline runtime behaviour and inspect tool descriptions as security artefacts.

Practical implication: Combine prompt-aware review with behavioural baselining to catch tool poisoning and trust abuse.

Threat narrative

Attacker objective: The attacker wants to turn trusted AI supply chain artefacts into execution, data access, or control paths that bypass ordinary pre-installation scanning.

1. Entry occurs when an AI workload pulls packages, model artefacts, or MCP tools that were not fully represented in the original manifest.
2. Credential or trust abuse follows when the workload accepts a runtime-loaded adapter, skill, or tool description as legitimate without verifying provenance or behaviour.
3. Impact occurs when the hidden payload executes code, changes model behaviour, or exfiltrates data through delegated agent actions.

Breaches seen in the wild

• Hugging Face API tokens exposed 2023: Lasso Security found 1,681 live Hugging Face tokens in public code, 655 with write access, reaching 723 organisations including Meta; all were revoked.
• xinference PyPI compromise 2026: Three xinference releases on PyPI carried a stealer for cloud, Kubernetes and registry keys, reportedly via a compromised bot account.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI supply chain governance now has three separate failure domains: component vulnerability, artefact integrity, and behavioural payload. Security teams keep collapsing them into a single scanning conversation because the dashboards look unified, but the control problem is not unified at all. Each surface has a different trust boundary, different evidence source, and different remediation cadence. The practitioner conclusion is simple: one scanner cannot be the governance model for all three.

Runtime evidence is the missing control plane for AI workloads: pre-installation scanning only tells you what was declared, not what executed. That matters because AI systems are increasingly assembled from dynamic loaders, remote model registries, and agentic toolchains. The governance gap is not just technical coverage, it is assurance over delegated behaviour, which is where NHI and agent identity risk begins to matter. The practitioner conclusion is to verify runtime state before trusting a clean build.

Behavioural payloads are the clearest sign that AI supply chain security has moved beyond SCA: when the malicious content lives in the instruction text, the old package-centric model is structurally misaligned. This is a control gap in provenance, not a tuning issue. It also exposes the boundary between software supply chain security and identity governance, because the agent is acting on behalf of a human or service principal. The practitioner conclusion is to govern the instruction layer as a security object.

AI supply chain security is becoming an assurance discipline, not a scanning discipline: teams need evidence that artefacts are authentic, load-time safe, and behaviourally consistent with their declared purpose. That aligns naturally with NIST CSF and OWASP-NHI thinking about identity, authorisation, and runtime trust, even when the immediate object is a model or tool. The practitioner conclusion is to treat AI supply chain evidence as part of broader security governance, not as an isolated DevSecOps task.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: AI Infrastructure Workload Identity Guide

What this signals

Three-surface AI supply chain governance: security teams should stop treating AI workloads as if dependency scanning is enough. The operating model now needs separate evidence for code dependencies, model artefacts, and behavioural instructions, because each surface fails differently and at a different point in the lifecycle.

The practical shift is toward runtime verification and provenance control, not more dashboard consolidation. That means build-time scanning remains useful, but only as one input into a broader trust decision for models, tools, and agent actions.

Third-party exposure makes this harder, not easier. According to the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

For practitioners

• Map AI workloads into three control surfaces Separate package vulnerabilities, model artefact integrity, and behavioural payload review into distinct workflow steps so one tool does not claim coverage for all three.
• Verify runtime-loaded artefacts before trusting the manifest Compare what the AI workload actually loads at runtime with what the deployment declared, especially for models, adapters, skills, and MCP tools.
• Prefer safer model formats and load-time checks Reduce dependence on pickle-based model files, apply load-time validation, and reject artefacts that cannot be validated against provenance expectations.
• Baseline tool behaviour after installation Observe agent tools and skills in operation, then flag deviations from the documented work envelope, unexpected calls, or silent data movement.

Key takeaways

• AI supply chain risk is not a single scanning problem because code, model artefacts, and behavioural instructions fail on different terms.
• Pre-installation SCA can still be clean while runtime-loaded models, adapters, or tools change the actual risk surface.
• Practitioners need runtime verification, safer artefact handling, and behavioural baselining before they can trust an AI workload as governed.

Key terms

• AI supply chain: The AI supply chain is the full chain of models, datasets, prompts, tools, and vendors that influence a deployed AI system. It matters because trust cannot be assigned to the application alone. Practitioners need provenance, ownership, and dependency visibility to govern risk.
• Model Artifact Integrity: Model artifact integrity is the assurance that a model file, weight package, or serving image has not been altered after it was approved. It depends on signing, provenance, and admission checks, because an unverified model can be swapped, tampered with, or retrained outside the intended trust chain.
• Behavioral Payload: Malicious intent embedded in a natural-language artifact such as a tool description, prompt template, or agent skill. The code may look normal, but the text itself directs the system toward exfiltration, policy bypass, or unsafe actions. This requires behavioral review, not just code scanning.
• Runtime evidence: Cryptographic proof collected from the environment a workload is using, such as image hashes, cloud-signed metadata, boot measurements or code signatures. It is the material a verifier checks to decide whether an identity should be trusted.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to govern non-human access, delegated trust, and identity risk across modern security programmes.