Half of Them Can Run Shell Commands: What a Capability Audit of 500 MCP Servers Says About the Software You Installed by Name

Reco published its State of Agent Security 2026 report on 26 August 2026, and the useful part is not the headline. The headline is that only 20 percent of AI tools in enterprise environments sit under any form of IT oversight, which is a number most security leaders will read, accept and file. The useful part is buried one layer down, in a methodology that did something nobody else has bothered to do at scale: rather than survey what people think they are running, the researchers took 500 published Model Context Protocol servers from the npm registry, confirmed the source of each, and read what the code can actually do. The rest of the study rests on anonymised platform telemetry from 62 large enterprises across financial services, healthcare, retail and telecommunications between 1 January and 1 August 2026, plus vulnerability disclosures pulled from the National Vulnerability Database covering January 2025 to June 2026. Three different lenses, one uncomfortable picture.

Here is the capability profile of those 500 servers, and it is worth reading slowly. Half of them can execute shell commands. More than 80 percent can read or write files on the local system. Roughly 75 percent can make outbound network calls. Twenty seven percent expose a listening network endpoint, and half of those endpoints ship with no authentication at all. And 62 percent combine command execution, file access and network egress in a single component. Take that last sentence, strip the words model context protocol out of it, and hand it to any security reviewer you have ever worked with. A piece of software that runs arbitrary commands, reads and writes the local file system and reaches the open internet is not a connector. That is the standard functional description of a remote access tool. If a vendor submitted it through procurement with that capability list on the form, it would get a threat model, a network placement decision and a named owner before anybody installed it. It arrived instead as a one line entry in a configuration file, added by a developer on a Tuesday because a demo needed it.

The gap between how these components are chosen and what they can do is structural rather than careless, which is exactly why it will keep happening. An MCP server is presented in a directory by purpose: a Jira server, a Postgres server, a browser server, a file system server. Purpose is what you search for, purpose is what you evaluate, and purpose is what goes in the ticket if a ticket exists at all. Nothing in the install path surfaces capability. Compare this to two permission models that took the industry a decade of painful incidents to build. A mobile app must declare the permissions it wants and the operating system shows them to the person installing it. A browser extension must declare host permissions and the store shows a warning when an extension can read data on every site. MCP has no equivalent surface today. The name is the marketing and the manifest is the risk, and at present only one of those two is visible at the moment of the decision.

The vulnerability curve in the same report tells you this component class is not sitting still. The researchers tracked 637 vulnerabilities across agent and large language model tooling, of which 525 were disclosed in the past 18 months, and 111 carry a critical rating at CVSS 9.0 or above. The monthly disclosure rate ran below five during 2023 and 2024 and has averaged around 29 since January 2025, a more than sixfold increase. Be fair about what that curve measures, because it is not purely a statement about code quality. A large part of it is researcher attention arriving in a newly interesting area, which is what happened to container runtimes, to CI systems and to every popular web framework before it. But both readings land in the same operational place. Whether the code got worse or the eyes got sharper, you now own a component class with an active and accelerating advisory stream, and if you cannot produce a list of which ones you run and at what version, you have no way to act on any single advisory in it. We made this argument three days ago about agent frameworks and the Langflow flaw on the CISA exploited list, and the Reco data is the base rate underneath that anecdote.

The adoption figures explain why the list does not exist, and the most instructive number is the contrast rather than any single value. In the enterprise telemetry, 79 percent of third party applications were properly authorised, which means the software as a service governance programme those companies built over the past decade is working roughly as designed. Against that, small and midsize companies carried an estimated 414 unsanctioned AI tools per 1,000 employees. Both facts are true at once, and the reconciliation is simple: AI tooling is not arriving through the channel the governance programme watches. It arrives through an OAuth consent screen a member of staff clicks in ten seconds, through a browser extension, through a plugin in a code editor, through a line added to a local configuration file that no inventory system has ever read. Your controls are not failing. They are pointed at a door that people have stopped using.

The framework mapping is conventional, and saying so is the point, because nothing here requires a new control family. ISO 27001 already expects an inventory of assets, secure configuration, access provisioned against documented authorisation, management of supplier relationships and management of technical vulnerabilities, and an unauthenticated listening endpoint attached to a shell execution capability fails several of those at once. The SOC 2 common criteria expect changes to be authorised, expect logical access to be granted and reviewed against approval, and expect vulnerabilities to be identified and remediated on a defined timeline, none of which can be evidenced for software that no register lists. ISO 42001 asks for an inventory of AI systems with a recorded purpose and a named owner, and an MCP server that a developer added last quarter is an AI system component whether or not procurement saw the request. If any of this runs within reach of a payment page, the PCI DSS expectations on inventory, patch timelines and script integrity follow it there directly. Be precise about what tooling does for you: Vanta, Drata, Secureframe, Sprinto, Thoropass and Hyperproof will confirm that your asset management policy is approved and that your access review ran on schedule, and they will not tell you that a file system MCP server with network egress is running on eleven laptops. Our compliance readiness tool, our ISO 42001 material and the asset management, secure development and supplier templates in our policy templates library all assume somebody maintains the underlying list, and that assumption is precisely what is failing here.

The counterargument deserves proper weight rather than a token sentence. A capability is not a vulnerability, and a file system server that reads files is doing the job it exists to do, so the 80 percent figure on file access is a description of the category rather than an indictment of it. The sample is a published catalogue drawn from a package registry, which is not the same population as the servers any particular organisation actually runs, and a curated internal set will look very different from an open registry. Reco sells posture management for software as a service and AI estates, so the report is not disinterested, and the honest way to read any vendor research is to separate the measurements from the conclusion the vendor would like you to draw. Do that here and the measurements survive intact, because the two findings that matter are not capability findings at all. Twenty seven percent exposing a listening endpoint is a deployment decision. Half of those endpoints shipping without authentication is a default configuration, and a default that ships open is a defect regardless of what the component is for.

The exercise for this week takes an afternoon and produces something durable. First, build the list from the places the software actually lives rather than from a survey: pull the connected applications and third party OAuth grant report from your Google or Microsoft tenant and filter for AI and agent platforms, then search developer machines and repositories for MCP configuration files, including the Claude desktop configuration, project level configuration files and editor settings. Second, classify every entry by capability rather than by name, recording three yes or no answers for each: can it execute commands, can it read or write local files, can it make outbound network calls. Third, treat any server holding all three as a privileged component, which means a named owner, a written purpose and a review date, not a removal order, since most of them will be legitimate. Fourth, find every listening endpoint in that inventory and verify authentication today, because that is the finding with the shortest path to an incident and the shortest path to a fix. Fifth, add MCP servers and agent tooling to the same vulnerability management scope, patch service level and advisory monitoring you already apply to your web stack, which satisfies the ISO 27001 asset requirement and the ISO 42001 inventory requirement in one action. Sixth, publish a small sanctioned catalogue with a fast approval route, because 414 tools per 1,000 employees is not a discipline problem, it is unmet demand finding the path of least resistance. The industry spent the past two years asking whether the model could be trusted. The measurement that came back this week is that most of the risk is sitting in a small helper process that reads your files, opens a socket and never asked anyone for permission.