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, its origins need verification 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 needs to go beyond the approved server name. A coding agent with one approved MCP server may also depend on: 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 can influence execution. Oktsec Signal reviews dependency characteristics; teams still need to verify the exact installed artifact, its privileges and its update path.

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. An npm package can execute during installation, import or runtime. 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. Depending on the host’s approval settings, the human who approved the dependency may not review each invocation.

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. A remote MCP server can change the tools and descriptions it returns without a local package update. Whether an agent receives and may use those changes depends on its client and approval controls. Review happened once; the artifact keeps evolving.

Review scenario: consider a server whose tool list grows from three to nine after approval. Without change detection, a team may continue relying on a review of the smaller surface.

Failure patterns to review

Review these four classes of supply-chain risk:

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 distribute skills directly. Connecting can make skills discoverable; the host still needs to approve their use. The Agent Skills format is an open standard. Server delivery makes provenance, content integrity and approval part of the client’s operating controls.

Approval is an event. The supply chain is a process. A review at approval time can become stale when an artifact, its permissions or its remote behavior changes.

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.

  1. 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.
  2. Pin by content. Hash what you approved: the server's tool definitions, the skill files, the descriptions. When the hash changes, review again before agents keep using it. This is the lockfile the connection never had.
  3. Scan before first use. Skills and tool descriptions are text; deterministic checks can identify known injection patterns, suspicious destinations and risky configuration, before the artifact ever reaches a model's context. Include the skill’s scripts and supporting files as well as SKILL.md. Oktsec Signal also grades the repository, workflows and install paths around it.
  4. Verify at runtime. Record what agents actually invoked, against which policy, and compare it with what the supply chain was supposed to provide. A difference can flag drift for investigation; it does not guarantee prevention.
agent-env · supply chain viewpinned
1mcp: repo-tools   9 tools · hash e3a1… pinned
2skill: refunds    source: vendor · signed ok
3skill: deploy-fast no provenance     review
4mcp: notes-helper  tool set changed since approval → blocked
5evidence → reported for review
The same environment, seen as pinned capabilities with provenance instead of a list of names.

The takeaway

Review both the source of each artifact and the access it can influence. Evaluate it before adoption, pin what you approved, scan what arrives and keep verifiable evidence of what actually ran. Revisit the review when the artifact or its operating environment changes.

To inspect the dependencies your agents use, explore AI supply chain security with Signal. See how source review connects a suspicious pattern to the code your team needs to examine.