The MCP supply chain: 71% of public packages have one maintainer

A scan of the public MCP package ecosystem shows what most security teams suspected: the supply chain that AI agents depend on looks a lot like npm did in 2014. Of the 973 npm packages that name themselves after the Model Context Protocol, 71% have a single maintainer, 56% were published in the last 30 days, and 25% have no linked source repository. In tests, 9 of 11 MCP registries failed to detect malicious uploads.

The gap this is opening up is the same one that made the early npm era a graveyard of typosquat attacks and abandoned packages, except now the packages in question are not just installed on developer laptops. They run as operating system level services, configured by JSON files that often hold live API keys and database credentials, and they sit directly between an AI agent and every tool the agent is allowed to use.

What the MCP developer supply chain actually looks like in 2026

The Model Context Protocol, the open standard that Anthropic introduced and that most of the industry has now adopted, is a small but real piece of plumbing. An MCP server is a process that exposes a list of tools to an AI model: read a file, query a database, call an API, post to a chat channel. The protocol is simple enough that anyone can ship a server in a weekend, and that is exactly what has happened.

The npm registry now lists 973 packages whose names contain the string "mcp." That is the practical definition of the public MCP server ecosystem, and it is the dataset the Security Boulevard analysis pulled from. The findings are not subtle. 71% of those packages have a single maintainer, meaning the person who wrote the package is the only person who can push new versions, respond to security reports, or rotate a compromised credential. 56% were published in the last 30 days, which means the median package in the ecosystem is younger than most enterprises' vulnerability scanning cycles. A quarter of the packages have no source repository linked at all, so the only place a user can audit the code is the published tarball itself. Average package age, 98 days.

For comparison, the enterprise AI governance checklist for 2026 on this site treats MCP servers as a separate trust boundary from normal npm dependencies, and the data here is why. A typical dependency you pull from npm is a library, something your code calls into. A typical MCP server you install is a process you launch, with the ability to execute operating system commands against any parameter the agent decides to pass it. The trust model is different in kind, not in degree.

The credential exposure hiding in MCP config files

The second finding is the one most security teams have not seen yet. MCP servers are configured by JSON files that live on disk alongside the agent, and the default config format passes through API keys, database connection strings, and OAuth tokens in plaintext. The agent reads them at startup and uses them on every tool call.

GitGuardian's 2026 State of Secrets Sprawl report, also released this week, scanned public GitHub for that pattern. The result: 24,008 unique secrets sitting in MCP configuration files in public repositories, of which 2,117 were confirmed still live at the time of scanning. Live means the credential still worked, the API key still authenticated, the database still responded. The scan is not exhaustive, because the search pattern is fuzzy, but it is large enough to confirm that the practice is widespread, not rare.

The threat actor group tracked as WAVESHAPER has been observed specifically enumerating MCP config files in public repositories. The pattern is automated, fast, and opportunistic. Once the attacker has a working API key, the resulting activity looks like the legitimate agent, because it is the legitimate agent. The same observation is in the Lorikeet Security report on MCP supply chain attacks, which documented 30 CVEs tied to MCP server implementations and at least one confirmed North Korean supply chain hijack that used an MCP-adjacent npm package as the initial access vector.

The fix is not subtle either. Treat MCP config files the way you treat a private key file: keep them out of version control, rotate credentials on any commit, and assume any secret that touches a public repo is compromised. Runtime controls, the same layer that catches rogue agents at the OS level, are what close the gap once a credential does leak. Tools like git-secrets, trufflehog, and GitGuardian's own scanner can be wired into the agent development workflow the same way they are wired into backend workflows today.

Where the registries are failing, and what to do this week

The third finding is the most directly useful to act on. OX Security, a vulnerability research firm, recently disclosed a design-level remote code execution issue in the STDIO transport that most MCP servers default to. The transport, by design, passes configuration parameters directly into operating system command execution without input validation. Anthropic has called this expected behavior, and the protocol specification does not require validation. That is fine for a local developer tool. It is a much bigger problem when the same code path is exposed to a network.

OX Security tested 11 major MCP registries, the public indexes that developers browse to find a server for, say, Slack or Postgres. 9 of them accepted malicious server uploads without detection. The Cloud Security Alliance published a parallel finding, calling the protocol architecture itself an attack surface, and recommended that registries implement mandatory static analysis and source repository verification before allowing a package to be published.

The throughline in all of this week's data is that the AI developer tooling ecosystem is outgrowing its security tooling at a rate of 10:1 on PyPI and 28:1 on npm. For every download of an AI security tool, there are 28 downloads of an AI coding tool. The asymmetric growth rate is not sustainable. The number of CVEs filed against AI coding tools and MCP-adjacent libraries grew from 3 in 2023 to 51 in 2025, and 78% of those CVEs are rated CRITICAL or HIGH in the National Vulnerability Database.

The good news is that the controls already exist. Static analysis on every AI-generated commit, secret scanning on every config file, registry allowlists for MCP servers, runtime containment for the agents themselves. None of this is new in principle. All of it is currently underinvested relative to the rate at which AI tools are being adopted. The practical guidance is the same as the practical guidance for npm in 2014. Pin versions, not floating tags. Audit the package source before installing. Prefer packages that link to a public source repository with multiple maintainers. Run the server in a least-privilege environment, ideally a container with a read-only filesystem. And if you are running an enterprise agent deployment, put the registry in front of a proxy that enforces these checks before any code ever reaches a developer laptop. The same pattern, the same playbook, the same data points. The only thing that has changed is which dependency tree is exploding fastest.