The agent supply chain is bigger than your dependency tree.
Your dependency tree ends where your lockfile ends. An agent's supply chain keeps going: MCP servers, skills, tool descriptions, and every update those pick up after you approved them.
The short version
- The agent supply chain is every artifact an agent pulls into your environment: packages, MCP servers, skills and prompts, plus the dependencies behind each one.
- It repeats the npm pattern with two dangerous differences: agents invoke what they install autonomously, and there is no lockfile between an agent and a server that updates itself.
- Monitoring 58,000+ published skills and servers shows the same gaps at scale: no verifiable provenance, silent updates, and scope that grows after approval.
- The controls are inventory as capabilities, pinning by content, scanning before first use, and verified evidence at runtime.
The agent supply chain is every artifact an AI agent pulls into your environment in order to work: the packages it installs, the MCP servers it connects to, the skills it loads, the prompts and tool descriptions it reads, and the dependencies sitting behind each of those. It is bigger than your dependency tree, most of it carries no verifiable origin, and parts of it change after you approved them.
Software teams spent a decade learning to manage package risk. The agent version of the problem arrived faster, and it does not wait for a human to run install.
What is actually in the chain
When we map an agent environment in an assessment, the inventory rarely matches what the team believes it approved. A coding agent with one approved MCP server typically also carries: the server's own dependency tree, the credentials the server holds, every tool description that server sends into the model's context, any skills the team added for workflow, and the registries all of the above were fetched from.
Each element is input the agent will act on. From monitoring more than 58,000 published skills and MCP servers across the public registries, the baseline looks like the early package ecosystems: most artifacts carry no verifiable signal about who wrote them, version history is thin or absent, and content routinely changes after publication without any notice to the people who installed it.
How this differs from npm
The comparison to the JavaScript dependency crisis is fair, and it undersells the problem in two specific ways.
Agents invoke what they install. A vulnerable npm package waits for your code to call it. A vulnerable or malicious MCP tool can be invoked by an agent through its own reasoning, steered by nothing more than text in a tool description or a document the agent read. The human who approved the dependency is not in the loop at invocation time.
There is no lockfile at the connection. When a package updates, your lockfile pins you to the version you reviewed until you choose to move. When an MCP server updates, connected agents get the new tools and the new descriptions immediately. Review happened once; the artifact keeps evolving.
The failure patterns we see
Four patterns repeat across the ecosystem data and our assessments.
Typosquatting and namesquatting. Servers and skills published under names close to popular ones, waiting for a developer, or an agent resolving a name, to pick the wrong one.
Scope creep. An artifact ships with one narrow, useful capability and expands toward sensitive operations across updates. Adoption happened at the narrow version; risk arrives with the wide one.
Silent mutation. Tool descriptions reworded in ways that steer agent behavior, authentication removed "for developer convenience", new endpoints appearing in a patch release.
Transitive trust. MCP servers that call other services, creating trust relationships nobody mapped. Your agent trusts the server; the server trusts something you have never heard of.
The direction of travel makes this more pressing, not less. SEP-2640 proposes letting MCP servers ship skills directly, which moves skill installation from a deliberate human act to a side effect of connecting a server. The Agent Skills format is an open standard and the proposal is well designed, but it widens the same channel: more executable influence arriving with less explicit review.
Approval is an event. The supply chain is a process. Any control that only runs at approval time is auditing a version of your environment that no longer exists.
What to enforce
The npm decade produced a playbook: provenance, pinning, scanning, and continuous monitoring. The agent version applies the same ideas at the points where agents differ.
- Inventory as capabilities, not names. Track what each artifact can do (tools, credentials, network reach), not just what it is called. A name tells you nothing when the content behind it moves.
- Pin by content. Hash what you approved: the server's tool definitions, the skill files, the descriptions. When the hash changes, re-review before agents keep using it. This is the lockfile the connection never had.
- Scan before first use. Skills and tool descriptions are text; deterministic checks for injection patterns, exfiltration endpoints and permission over-reach are cheap and run in seconds, before the artifact ever reaches a model's context.
- Verify at runtime. Record what agents actually invoked, against which policy, and compare it with what the supply chain was supposed to provide. Drift shows up as a diff, not as an incident.
The takeaway
Treat every artifact an agent consumes as a supplier with autonomous access to your systems. Evaluate it before adoption, pin what you approved, scan what arrives, and keep verifiable evidence of what actually ran. The package ecosystems took ten years to learn this. The agent ecosystem gets to skip the decade, if it chooses to.
Oktsec Signal grades the repositories, packages, MCP servers and CLIs that agents depend on. They audit the skill file. We audit the repository it ships in. See Signal →