The AI supply chain stopped being about model providers.

For most of the last two years, "AI supply chain risk" meant one question: which model API are we calling, and can we trust the vendor behind it. OpenAI, Anthropic, Azure OpenAI, Bedrock — pick a provider, sign the DPA, write the policy, move on.

That mental model is now badly out of date.

The Model Context Protocol — the open spec Anthropic shipped in late 2024 — turned model access into something closer to a package ecosystem. Any team can stand up an MCP server. Connect Claude (or any MCP-compatible agent) to a vendor's MCP server, or to your own internal one, and three things happen at once:

• The model can call any tool that server exposes.
• The model can read any resource that server makes available.
• The model can pull in any prompt that server registers.

All three pipe straight into the model's working context on every turn. The boundary between "third-party software" and "your model's input" essentially disappears.

That's not a feature concern. It's a software supply chain — and most security teams haven't started treating it as one.

The actual surface

MCP servers expose three kinds of capability. Each one is its own audit surface.

Tools. Functions the model can invoke. create_record, delete_table, send_email, transfer_funds — whatever the vendor decided to expose. The model decides when to call them based on the conversation. Every new tool a server adds is, in practice, a new privileged action your AI can take, often without re-review.

Resources. Data the model can pull on demand: rows, files, system docs, live queries. Resources are how vendor data ends up inside model context, and where prompt-injection vectors arrive. A poisoned row in a resource is a poisoned row in the model's reasoning.

Prompts. Server-registered prompt templates the model can invoke. Less talked about, more interesting — prompts are vendor-authored instructions the model is meant to follow. A vendor changing a registered prompt can change how the model behaves across every customer that connected to them, without shipping any model update at all.

A typical org running AI in production today connects to somewhere between five and forty MCP servers across teams: a dev tool, a project tracker, a CI server, a CRM, a knowledge base, several internal services. Each one is a versioned third-party dependency that mutates on its own schedule. There is no package.json for any of it.

What "supply chain" means here

A real supply chain has three properties: inventory (you know what's installed), provenance (you know who made it and when it changed), and review (something — usually a human plus an automated check — gates new versions before they reach production).

Map that onto MCP today:

• Inventory. Most orgs cannot list every MCP server their teams have connected to. Connections happen at the developer-machine and agent-config layer, not through a managed integration system.
• Provenance. When an MCP server adds a tool — say, last Tuesday a vendor quietly shipped bulk_export — there is no notification, no diff, no changelog. The next time your model talks to that server, the new capability is live.
• Review. Almost no organization gates MCP server updates. Whatever the server says it can do today is what your AI can do today.

A useful test for any AI ops team this quarter: ask your AppSec lead whether they can produce, in under ten minutes, a list of every MCP server connected to your AI agents and the tools each one exposes. If the answer is no, the supply chain is unmanaged.

The first move is inventory

The control plane for this comes later — gating, allow-lists, change approvals, deprecation policies. None of it works without inventory first. You cannot govern what you cannot list.

A workable starting point is small:

1. Enumerate every MCP server in use. Across agents, IDEs, internal services. Put it in one place — even a wiki page beats nothing.
2. For each server, capture today's surface. Tools, resources, prompts. The raw output of tools/list, resources/list, prompts/list is the canonical artifact.
3. Diff over time. When tools/list changes between snapshots, that is the same class of event as a dependency version bump. Treat it like one.
4. Decide on an approval model. New tools should require review the same way a new npm package should. Most orgs are nowhere near this; it is fine to start with notification and work toward gating.

This is unglamorous, audit-friendly work. It is also exactly the kind of work that prevents the call where someone asks why your model exfiltrated a customer record using a tool nobody on the security team knew existed.

Why this is urgent now

Two trends are converging. AI agents are moving from chat surfaces into actual work — tickets, deploys, reports, customer outreach, payments. And the MCP ecosystem is past the early-adopter phase: vendor-published MCP servers are a normal way to integrate with a SaaS product now. Both trends mean the gap between "what the AI can do" and "what your security and IT teams have audited" is widening week by week, not narrowing.

The teams that are ahead on this don't have a more sophisticated stack. They have an inventory, a diff, and an owner.

If you want a fast first artifact, MCP Inspect renders any MCP server's tools, resources, and prompts into a shareable report — exactly the thing to attach to a security review. That's the inventory step. The diff and the owner are the next two.