AI Supply Chain Security for Agent Systems
AI supply chain security for agent systems: how dynamic tool loading, model provenance, and poisoned dependencies create risk — and how to lock it down.
AI supply chain security is the discipline of trusting everything your agent depends on — and agents depend on far more than traditional software. A conventional application has a dependency tree of libraries you can pin, hash, and scan. An AI agent adds foundation models it did not train, tool servers it loads at runtime, retrieval sources it did not author, and datasets whose provenance it cannot see. Every one of these is a supply-chain link, and most of them are dynamic in ways that classic software composition analysis was never built to handle.
This is not a hypothetical concern. The OWASP Top 10 for Agentic Applications lists agentic supply chain vulnerabilities (ASI04) as a distinct risk precisely because the agent supply chain behaves differently from the software supply chain. This post breaks the agent supply chain into its real components, explains why each is exploitable, and lays out the controls — signing, provenance, pinning, and runtime verification — that make it defensible.
It builds on our MCP tool poisoning and OWASP agentic testing posts and feeds directly into the AI agent attack surface map.
Why the Agent Supply Chain Is Different
Traditional supply-chain security assumes dependencies are declared, mostly static, and resolved at build time. You have a manifest, a lockfile, and a build step where you can verify hashes. Software composition analysis scans that tree, and you ship a known artefact.
Agents break three of those assumptions:
- Runtime resolution. Agents discover and load tools, plugins, and MCP servers while running, often with broad permissions. There may be no build-time manifest to scan because the tool set is assembled on the fly.
- Natural-language dependencies. A tool’s description is a dependency — the model executes against it. Poison the description and you have altered behaviour without changing any hashed binary. This is the tool-poisoning path covered in our confused deputy post.
- Opaque upstream. You did not train the foundation model, curate its data, or author the documents your RAG pipeline retrieves. Provenance is limited by default, and a silent model update can change your risk posture overnight.
The consequence: a rug pull, a typosquatted tool, or a hallucinated dependency can become a full compromise, and your existing SCA tooling may never see it.
The Layers of the Agent Supply Chain
To secure it, first enumerate it. An agent system has at least six supply-chain layers.
Foundation models. The model provider, its version, and its update cadence. A model swap — even a minor version bump — can change safety behaviour, tool-calling patterns, and susceptibility to injection. Treat model identity as a pinned dependency.
Model artefacts and fine-tunes. If you host open-weight models or fine-tunes, the weights are a supply-chain artefact. Poisoned or backdoored weights, tampered adapters, and unverified downloads are all in scope.
Tools and MCP servers. The largest and most dynamic surface. Each tool server is code plus a natural-language contract, both of which can be malicious, compromised, or silently updated.
Data and retrieval sources. RAG corpora, embeddings, and memory stores. A poisoned document in a retrieval source is a supply-chain compromise that surfaces as a runtime instruction. Provenance of ingested content matters as much as provenance of code.
Agent frameworks and libraries. The orchestration code itself — the traditional dependency tree, still fully in scope for classic SCA, plus framework-specific vulnerabilities around tool handling.
Prompts and configuration. System prompts, guardrail policies, and tool schemas that live in shared repositories or are fetched at runtime. A tampered system prompt is a supply-chain attack on the agent’s core instructions.
The Attack Patterns
Four patterns recur across the agent supply chain.
Rug pull. A benign tool server, model, or package earns trust, then updates to malicious behaviour after adoption. The version you reviewed is not the version running. This is the single most important reason to pin and re-verify.
Typosquatting and confusion. Attackers register tool or package names that resemble popular ones — github-mcp versus github_mcp — betting an agent or developer picks the wrong one. Confusion attacks also exploit ambiguous tool names across servers.
Hallucinated dependencies (slopsquatting). An LLM suggests a plausible-sounding package or tool that does not exist. Attackers pre-register the hallucinated name and wait for the model to recommend it and a developer or agent to install it. Verifying that every dependency exists in an official registry with real history defeats this.
Poisoned data and manifests. Malicious content in a retrieval source, or adversarial instructions in a tool manifest, that the agent later treats as authoritative. This is where supply chain and prompt injection converge.
Controls: Making the Supply Chain Defensible
The controls are concrete and mostly borrowed from mature software supply-chain practice, adapted for the agent’s dynamic layers.
Signed manifests and provenance. Require every MCP server, tool, and plugin to ship a signed manifest with hash verification. Use SLSA-style provenance where available. Reject unsigned or unverifiable dependencies rather than warning and proceeding. Cryptographic signing (for example Ed25519-signed manifests) lets the agent verify a tool is what it claims before loading it.
Pin and re-verify. Record a hash of every dependency — model version, tool manifest, package, and critical prompt or config — at approval time. Re-verify on each session and alert on drift. This is the direct defence against rug pulls: a changed hash blocks the load.
Runtime manifest validation. Compare what a tool’s manifest claims against what it does at runtime. Monitor network calls, file access, and system calls during tool execution, and flag any behaviour not declared in the manifest.
Registry and existence checks. Before adopting any dependency an LLM suggested, confirm it exists in an official registry with an established history. Reject freshly registered, no-history, or non-existent packages — the signature of a slopsquatting attack.
Least-privilege per dependency. Scope credentials and permissions to the individual tool, not the whole agent. A compromised tool should reach only what its function requires, capping the blast radius of any single supply-chain failure.
Model provenance discipline. Pin foundation-model versions, monitor for provider updates, and re-run your safety evaluations after any change. Treat a model update like a dependency bump: verified, tested, and logged — not silent.
Provenance logging. Every tool call and retrieval should record which source, which version, and which credentials were involved, so an incident can be traced to a specific supply-chain link.
Testing Your Supply Chain
In a staging environment mirroring production:
- Dependency inventory. Enumerate every model, tool, MCP server, retrieval source, and library. An incomplete inventory is the first finding.
- Integrity check. Verify every dependency has a signed manifest or verifiable hash. Flag anything unsigned.
- Drift test. Change a tool manifest or model version after approval and confirm the agent detects it and refuses.
- Slopsquat check. Audit dependencies for packages with no registry history or suspicious name similarity.
- Runtime behaviour test. Execute each tool and confirm its runtime behaviour matches its declared manifest — no undeclared network or file access.
- Blast-radius test. For each dependency, map what a compromise would reach. Anything beyond the dependency’s stated purpose is over-provisioning to fix.
These tests map to ASI04 in our OWASP testing guide.
FAQ
What is AI supply chain security? It is the practice of establishing and verifying trust across everything an AI system depends on: foundation models, model weights, tools and MCP servers, retrieval data, frameworks, and prompts. For agents it extends beyond classic software dependencies to include runtime-loaded tools and natural-language contracts that traditional software composition analysis does not cover.
How is the agent supply chain different from a software supply chain? Agents resolve many dependencies at runtime rather than build time, treat tool descriptions and retrieved documents as executable instructions, and rely on opaque upstream models. These properties make rug pulls, hallucinated dependencies, and poisoned manifests effective in ways they are not against static, hash-pinned software alone.
What is slopsquatting? Slopsquatting is registering a package or tool name that a language model is likely to hallucinate and recommend. When a developer or agent installs the plausible-but-invented dependency, the attacker’s code runs. Verifying that every dependency exists in an official registry with real history defeats it.
Can existing SCA tools secure my agents? Only partially. Software composition analysis covers the traditional library tree, which is still in scope, but it does not see runtime-loaded tools, poisoned tool descriptions, model provenance, or poisoned retrieval data. Agent supply-chain security adds signing, pinning, runtime manifest validation, and provenance logging on top of SCA.
Lock Down Your Agent Supply Chain
If your agents load tools at runtime, retrieve from external corpora, or depend on a hosted model you do not control, your supply chain is an active attack surface. We assess all six layers — models, artefacts, tools, data, frameworks, and prompts — with signing, drift, and provenance checks mapped to OWASP and NIST AI RMF.
Want to scope your dependency risk first? Book a 30-minute call, email security@aivyuh.com, or explore our enterprise assessments.
Related reading: