AI supply chain risk splits into three surfaces for practitioners

At a glance

What this is: This analysis argues that AI supply chain risk breaks into three separate surfaces, and traditional SCA only covers one of them well.

Why it matters: It matters because IAM, NHI, and AI security teams need to govern runtime-loaded tools, model artifacts, and agent behaviors as distinct control problems, not one scanning workflow.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read ARMO's analysis of AI supply chain risk across frameworks, models, and MCP tools

Context

AI supply chain risk emerges when security tools assume every threat will appear as a versioned package with a published vulnerability. AI workloads do not behave that way, because model weights, runtime-loaded tools, and MCP server connections can all enter the environment after the manifest is signed off. That is why AI supply chain scanning must be treated as a control problem, not a single product category.

The identity angle is real even when the article is not about human IAM. Model loaders, agent tools, and MCP servers effectively become governed runtime actors, and their secrets, permissions, and trust boundaries need lifecycle control. In practice, the question is whether teams are scanning declared software or governing the components the workload actually uses after startup.

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 AI workflows complicate IAM and NHI governance?

A: AI workflows complicate governance because they increase the number of actions, permissions, and delegated decisions happening in a shorter time window. That creates more identity sprawl, more implied access, and less time for review. Traditional periodic governance models struggle when access changes faster than oversight cycles can observe it.

Q: What do security teams get wrong about model file scanning?

A: They assume that a clean repository scan means the model is safe to load. In practice, the risk often appears at deserialisation or conversion time, where unsafe formats can execute code or hide malicious behavior. Integrity checks need to happen at load time, not only in source control.

Q: How should teams respond when an MCP tool behaves differently from its description?

A: Treat that as a governance failure, not just a detection event. Isolate the tool, review its provenance, compare declared and observed behavior, and remove access to any internal data or APIs it touched. Behavioral drift in agent tools is exactly where prompt-level abuse becomes operational risk.

Technical breakdown

Why SCA only covers one AI supply chain surface

Traditional software composition analysis works because it maps manifests to package versions and then checks those versions against known CVEs. That model fits LangChain or vLLM dependencies reasonably well, but it fails once AI workloads load tools dynamically, invoke plugins at runtime, or ship with embedded model artifacts that are not packages at all. The result is partial visibility dressed up as completeness. Runtime reachability helps by filtering out unused code paths, which is especially important in framework-heavy AI stacks where most integrations are never exercised.

Practical implication: pair dependency scanning with runtime reachability so teams only triage vulnerabilities that the workload can actually execute.

Model artifact integrity is a different control problem

Model weights, LoRA adapters, embeddings, and training artifacts are not governed by CVE-style vulnerability records. Their risk is often in how they are parsed or loaded, especially when formats such as pickle can execute code during deserialisation. That makes integrity verification a load-time concern, not just a repository-scanning concern. Format-aware controls such as safer serialization choices and signature checks are central because a clean package scan tells you nothing about whether the model file itself is trustworthy.

Practical implication: verify model artifacts at load time and refuse unsafe formats where a safer alternative exists.

Behavioral payloads in MCP and agent skills

The third surface is unique to agentic AI. In MCP tools, skills, prompt templates, and similar artifacts, the malicious payload can live in the prose itself, not the code. A tool description can embed instructions that steer an agent to exfiltrate data or bypass policy while still behaving correctly from a code perspective. That is why static scanning alone is weak here. Security teams need provenance, trust boundaries, and post-installation behavioral monitoring to understand whether a tool is acting within its declared envelope.

Practical implication: monitor tool behavior after installation, not just the code that implements it.

Threat narrative

Attacker objective: The attacker wants to make the AI workload execute untrusted logic while appearing clean to pre-deployment scanning.

1. Entry occurs when AI teams ingest a trusted package, model artifact, or agent skill that appears benign at review time.
2. Escalation follows when runtime loading, deserialisation, or tool invocation activates functionality that was not visible in the original manifest.
3. Impact occurs when the workload executes malicious code, loads poisoned artifacts, or follows embedded instructions that expose data or change model behavior.

NHI Mgmt Group analysis

AI supply chain governance needs three control domains, not one scanner. The article shows that component vulnerabilities, artifact integrity, and behavioral payloads are structurally different problems. A package scanner can support the first domain, but it cannot claim coverage over model parsing or agent instruction abuse. Practitioners should stop describing AI supply chain risk as a single control category and treat it as three distinct governance surfaces.

Runtime evidence is now the deciding control plane for AI workloads. The article makes clear that pre-installation review is only a floor-plan view. Runtime loading, deserialisation, and first-invocation tool execution determine what actually exists in memory and what the agent can do. For IAM and NHI teams, that means the governable identity is not only the deployment artifact but the runtime actor that appears after startup.

Model artifact integrity is the hidden trust assumption in AI pipelines. The most important failure mode is not just a vulnerable package, but the assumption that a downloaded model or adapter is inert until used. It is not. That hidden assumption creates a trust gap between procurement, CI, and runtime enforcement. Teams should treat model files like governed inputs with provenance, not as passive assets.

Behavioral payloads create a new form of governance debt in agentic AI. Tool descriptions, skills, and prompt templates can carry malicious intent without obvious code indicators. This is the point where AI governance and NHI governance intersect, because the control problem is about what a system is authorised to do at runtime. The practical conclusion is that declared behavior and observed behavior both need enforcement.

Surface-specific controls will define the next phase of AI security tooling. The market is moving away from single-dashboard claims toward control coverage by artifact type. That will reward teams that can separate scan results from runtime verification and map both to policy. The right question is no longer whether a platform scans AI workloads, but which AI surface it actually governs.

What this signals

AI supply chain governance is converging with identity governance because runtime-loaded tools, models, and agents now behave like governed actors with their own trust boundaries. Teams that only scan manifests will continue to miss the component that matters most: what the workload loads, invokes, and authorises after startup.

Runtime trust gap: The next control gap is not whether an artifact passed review, but whether the runtime state still matches the approved state. That is the same governance problem identity teams already know from offboarding and privilege drift, except now it applies to AI tools, adapters, and model inputs.

The practical direction is to bind AI inventory, provenance, and behavioral monitoring together, then map them to established control frameworks such as the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 where agent identities are in scope.

For practitioners

• Separate AI supply chain controls by surface Create distinct workflows for package CVEs, model artifact integrity, and agent or MCP behavioral review so one control does not masquerade as full coverage.
• Add runtime reachability to framework scanning Use runtime evidence to suppress unused LangChain, vLLM, and plugin findings so remediation focuses on code paths the workload actually loads.
• Block unsafe model formats where possible Prefer safer serialization formats and refuse pickle-based artifacts unless there is a compensating control for load-time inspection and provenance.
• Monitor MCP tools and agent skills after install Baseline the observed behavior of tools, skills, and prompts after deployment, then alert when their actions diverge from declared purpose or approved data access.
• Tie AI inventory to runtime verification Maintain a runtime-derived inventory of loaded models, tools, and adapters so scanners can validate what is actually present rather than what was merely declared.

Key takeaways

• AI supply chain risk is not one scanning problem but three distinct control problems.
• Pre-deployment scanning is necessary, but runtime verification decides what the workload can actually do.
• Identity and governance teams need lifecycle controls for tools, models, and agents, not just package hygiene.

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.
• Runtime-Derived AI-BOM: An inventory of the models, tools, adapters, and components that actually loaded and ran in an AI workload. Unlike a declared bill of materials, it reflects live system state, which is essential when components appear only at runtime or are pulled dynamically from external sources.
• 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 Artifact Integrity: The property that what a system executes is the same thing reviewers, scanners, and build controls approved. In software supply chains and AI bundles, integrity has to extend beyond source files to compiled caches, embedded scripts, and packaged payloads.

What's in the full article

ARMO's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdown of how the three AI supply chain surfaces are scanned in production environments.
• Examples of runtime-derived AI-BOM evidence used to separate declared inventory from loaded components.
• Operational comparison of SCA, model scanning, and behavioral baselining across AI workloads.
• Implementation details for reachability analysis, deserialisation controls, and MCP behavior monitoring.

👉 ARMO's full post covers the surface-by-surface scanning model and the runtime evidence needed to validate it.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and agentic AI identity. It helps security practitioners connect runtime trust, lifecycle control, and access governance across modern identity programmes.