Unique MCP servers in active use: 4,524 (Source: Snyk, Evo ADS announcement (September 30, 2026))
The supply chain is now installed, not declared
A software supply chain used to be a list. Dependencies sat in a file, a reviewer read the changes, and a scanner checked them before release. AI coding agents are changing that habit.
The change centres on the Model Context Protocol, or MCP. It is a standard that lets an AI coding agent connect to outside tools: code repositories, databases, cloud systems and internal services. Snyk, the security vendor, describes the effect plainly. An agent with MCP access is more than a code suggester. In one session it can look up a ticket, pull records from a production database or call an internal service.
Each of those connections is a new part of the supply chain. Snyk's point is that it often arrives differently from a normal dependency. A developer installs an MCP server in a few seconds, and no review process stands behind it.
The lesson here is that the approval step has moved. It used to sit at the pull request. For agent tools, the decision now happens on a developer's machine, at the moment of use. Control has to move there too.
What Snyk found
Snyk published the figures alongside the general availability of a new feature. The numbers come from Snyk's scans of close to 10,000 developer setups.
Snyk adds that a majority of developers already have agents connected, through MCP, to tools and systems used in production.
Think of the shadow IT years, when staff signed up for cloud apps with a company card. IT learned about them later, from the invoices. MCP servers follow a similar path, except the tool can act inside a live session.
Why the usual checks miss it
Snyk says MCP servers do not pass through the build pipeline as scanned artifacts. Nobody reviews them as dependencies before a merge. They show up at runtime, often outside any process the security team can see.
The danger Snyk describes is concrete. A malicious server can act as soon as it starts. It can read files on the laptop, take credentials out, or reach systems inside the company network. Snyk's warning is that this can happen before security staff know the server exists. In Snyk's framing, this is the familiar malicious-package problem reaching developers by another route.
How the control works
Snyk's feature is called MCP Governance. It is part of Evo Agentic Development Security, which Snyk introduced in June. It follows three steps.
First, teams define which MCP servers are approved. The list can come from an existing inventory, a hand-built list, or servers the tool has already found. Second, the tool watches MCP activity on developer machines and flags any agent that reaches for an unapproved server. Third, it can log that use for audit or block it on the endpoint as the agent tries to connect.
Snyk says it works with Claude Code, Cursor, Codex and GitHub Copilot. It uses lightweight hooks that sit alongside the agent. Traffic does not pass through a separate proxy or gateway. Policy is set centrally, and enforcement happens locally. Snyk says this means no new infrastructure in the agent's path.
What the data does not show
This is a vendor announcement, and the figures are Snyk's own. The source does not describe how it chose the environments or defined a confirmed finding. Treat the numbers as one company's view, not an industry measure.
Snyk is also open about a limit. An approved list answers one question: is this agent allowed to reach this tool? It does not make the server a safe zone. Snyk says an agent working inside an approved server could still run a destructive shell command or send sensitive data somewhere it should not go. MCP Governance alone would not catch that. Snyk describes broader enforcement as work still to come.
Questions to put to your team
Can we list every MCP server running on developer machines today? If the answer is no, that list is the first job. Snyk notes that for many teams, seeing what agents actually connect to is the first real inventory they have had.
Who approves a new server, and how long does it take? If approval is slower than a seconds-long install, people will skip it.
Can we log or block use on the machine itself, across every agent our developers use? And what stops an approved tool from being misused? An approved list covers where agents connect. It does not cover what they do once connected.
Developers can add an agent tool in seconds, and the agent can use it at once. The question for leaders is whether anyone sees that moment.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Snyk.
