Your MCP Servers Are Vendors. Nobody Reviewed Them.

There is a category of software running inside most engineering organisations right now that has never appeared on a vendor register, never been through a security questionnaire, and never had an owner assigned to it. It is not shadow SaaS, because nobody signed up for anything. It is the collection of Model Context Protocol servers that developers have wired into Claude Code, Cursor and every other agent in the building, usually by pasting a configuration snippet from a README into a local settings file. The protocol has been extraordinarily successful, which is precisely the problem: the official MCP registry held roughly 9,652 records by May 2026, with thousands more listed across mcp.so, Smithery and Glama, and the overwhelming majority of them are small open source projects maintained by one person in their spare time.

The security research caught up during the first half of 2026 and the picture is not comfortable. Researchers disclosed more than 40 CVEs against MCP implementations between January and April, spanning the Python, TypeScript, Java and Rust SDKs, with roughly 30 filed inside a single 60 day window and command injection accounting for close to half of them. The Vulnerable MCP Project, which maintains a public database of the findings, tracked around 50 vulnerabilities and 24 CVEs across the March 2025 to February 2026 period, 13 of them rated critical, contributed by 32 separate researchers. In April 2026, OX Security published an analysis describing a systemic architectural flaw affecting an estimated 200,000 instances across a supply chain covering more than 150 million package downloads, and its central claim is the one worth sitting with: the weakness was not the result of sloppy individual implementations, it followed from what the specification required by default across every officially supported language.

The structural analysis is more alarming than the CVE count, because a CVE is a problem someone already found. Endor Labs examined 2,614 MCP implementations and found that 82 per cent use file system operations prone to path traversal, 67 per cent use sensitive APIs associated with code injection, and 34 per cent use APIs susceptible to command injection, with smaller proportions exposed to cross site scripting, SQL injection and open redirect. Those figures do not describe 2,614 compromised servers. They describe a population where the classical application security weaknesses of the last two decades have been reintroduced wholesale into a new layer, largely by developers who were solving an integration problem rather than writing a security boundary. A June 2026 research note from Tenet Security documented an attack it called agentjacking, showing that the injection surface is not limited to the server code at all, but extends to every data source that server exposes to the agent.

What makes this different from an ordinary dependency problem is what an MCP server is holding. A typical npm package receives inputs and returns outputs. An MCP server, by design, holds credentials to something valuable and exposes tools that act on it: a database connection, a repository token, a ticketing system API key, a cloud account role, a shared inbox. It sits between an agent that will do what it is told and a system that will do what it is asked. A path traversal weakness in a logging library is a bug. The same weakness in a filesystem MCP server that an agent invokes hundreds of times a day, on a developer laptop that also holds production credentials, is an access control failure with a language model driving it. The blast radius is set by what you handed the server, not by how much code it contains.

The compliance mapping here is unusually clean, which is helpful, because it means you do not need a new framework to justify the work. ISO 27001 Annex A control 5.19 covers information security in supplier relationships and 5.21 covers managing security in the ICT supply chain, and a third party component holding a live credential to your production database is squarely within both regardless of whether money changed hands. Annex A 8.28 on secure coding and 8.25 on the secure development lifecycle apply to any MCP server your own team writes, and given the structural findings above, they apply with some urgency. Control 8.9 on configuration management is the one most teams will fail on first, because MCP configuration typically lives in a per developer settings file that no configuration baseline covers. If you report against SOC 2, the CC6 series on logical access and CC9.2 on vendor and business partner risk both assume you can enumerate who and what has access, and an agent tool layer nobody inventoried defeats that assumption quietly. Under ISO 42001, MCP servers are components of the AI systems in your inventory, and the supplier due diligence clauses expect you to have looked at them.

The compliance automation platforms will not surface this, and it is worth being precise about why rather than waiting for a connector. Vanta, Drata, Secureframe, Sprinto and Thoropass build their continuous monitoring on systems that emit structured records: the identity provider, MDM, cloud accounts, the code repositories, the HR system. That coverage is genuinely strong for what it covers. An MCP server configured in a local file on an engineer laptop produces no OAuth consent event, no SaaS tenant, no SCIM record and no billing line. There is nothing for a connector to subscribe to. This is a control you have to author yourself, with a named owner, a written policy and evidence that comes from endpoint management and code review rather than from an integration dashboard. Teams that assume their GRC platform has this covered because it covers vendors are relying on a definition of vendor that the tooling never applied here.

The practical work fits into a fortnight and starts with counting, because almost nobody knows their real number. Sweep the developer fleet for MCP configuration files and produce a single list of every server in use, who added it, what credential it holds and what tools it exposes. Expect the list to be longer than anyone predicted and expect at least one entry nobody can account for. Then sort it into three groups: servers published by a vendor you already have a relationship with, servers from a maintained open source project with real review activity, and servers that are one persons weekend repository. The third group is where you spend your attention, and the honest answer for several of them will be removal rather than remediation.

For everything that stays, apply the controls you would apply to any privileged integration, because that is what these are. Pin versions rather than tracking latest, so a compromised release does not arrive automatically overnight. Scope every credential the server holds to the minimum the tools actually need, and prefer a read only token wherever the agent does not genuinely need to write. Run servers that touch sensitive systems in a container rather than directly on a laptop with production access. Require a review before any new MCP server joins a shared configuration, with the review question being what this thing can reach rather than whether it is convenient. For servers your own team writes, treat them as internet facing application code and put them through the same static analysis and code review as anything else, with particular attention to path canonicalisation and to any place a tool argument reaches a shell. Log tool invocations somewhere your security team can see, because an agent tool call is an access event and should be treated as one.

None of this is an argument against MCP, and it would be a poor one. The protocol solved a real integration problem and the productivity gain from agents that can actually reach your systems is not in dispute. The argument is that the layer grew faster than the governance around it, in exactly the pattern the industry has now repeated with cloud, with SaaS, with containers and with open source dependencies. Each time, the correction arrived after an incident, and each time the organisations that came through it well were the ones that started counting before they were forced to. The counting exercise here takes a couple of days. The next time an MCP server ships a backdoored release, and the pattern of 2026 suggests there will be a next time, the difference between an interesting security bulletin and a genuine incident will be whether you already knew which of your systems that server could touch.