I Told Nine Maintainers Their MCP Servers Were Risky. One Fixed It. The Ones I Did Not Tell Did About the Same.

In June I started a weekly scan of every public Model Context Protocol server I could find. MCP is the plug standard that lets an AI agent reach tools, files and services, which makes an MCP server the part of the agent stack that actually touches things. The scan is read-only and static: it fetches source from GitHub, looks for ten specific patterns that widen the attack surface, and scores each server. Aggregates go on a public scoreboard. Per-server findings stay private for disclosure.

Sixteen weeks later I have eight security snapshots, 23 weekly catalog counts, a cohort of 1,934 servers scanned at both ends, and a disclosure experiment I did not design as an experiment. This is what the series shows. The short version is in the headline. The longer version is more uncomfortable, because it says the problem is not awareness.

Growth does not fix security, and telling people barely dents it. The ecosystem's security is the security of its first commit.

What I measured, and what the numbers mean

Every Saturday a script walks GitHub for repositories that describe themselves as MCP servers, records whether each is maintained, archived, or stale, and, for the active ones, fetches up to 12 source files and runs them past ten patterns. Shell commands built from strings. eval and exec. Outbound requests to URLs the code did not hard-code. Unsafe deserialization. Credentials sitting in the source. Each pattern has a weight, the weights add up to a score, and the score puts the server in one of three tiers: Low (no pattern found), Elevated, or High.

Three things the number is not. It is not a vulnerability count; a pattern is surface, not a confirmed hole, and every finding carries the file and line so a false positive is cheap to dismiss. It is not a ranking; I publish the aggregate and never a league table. And it is not complete: the scanner reads source, so a server that takes its risk from configuration or from a dependency it never calls directly does not show up here.

The patterns have not changed since June, which is the point. A series is only worth citing if the measure stays still while the world moves. It also means the series carries its failures on the record. Two sweeps this month went wrong, one because GitHub throttled the scanner and it counted refusals as missing servers, and the scanner now refuses to publish a run in which more than five percent of fetches fail. The build log has the dates.

The line that would not move

Here is the catalog: 2,413 servers on May 31, 3,353 on September 26. Up 39 percent in four months. Actively maintained servers went from 1,841 to 2,510. Ninety-six are archived. Another 854 have not seen a commit in six months, which in this ecosystem is a long time.

Here is the risky-pattern share across the eight security snapshots, June 18 to September 27: 35.6, 36.4, 36.3, 36.4, 36.7, 37.3, 37.5, 37.7 percent. The number of High-surface servers went from 51 to 78.

Read those two lines together. Nine hundred new servers arrived. The proportion carrying a risky pattern did not fall. It drifted up two points. Whatever the new arrivals learned from four months of agent-security headlines, it does not show in their source.

The cohort makes the same point from inside. 1,934 servers were scanned in both June and September. After 14 weeks, 1,668 of them, 86 percent, have exactly the same number of findings. 114 have fewer. 152 have more. Among the tier moves, 70 servers went from Low to Elevated and 62 the other way; 12 went Elevated to High and six came back down; five went straight from Low to High and two from High to Low. Net movement: toward more surface, not less.

Servers are published and then left. The share that gets safer over a summer is smaller than the share that gets riskier.

That is not laziness. Most of these repositories are one person's side project, built to solve one problem and pushed so others could use it. Nobody is paid to come back. Which is exactly why the first commit matters so much: for most MCP servers, the security posture at publication is the security posture forever.

Nine letters

In June I picked the 47 highest-surface servers as a disclosure cohort and prepared a private brief for each: the category in plain language, the file and line, one sentence on why it matters when an agent is driving, a 45-day grace period, and an offer to share the full brief. No exploit steps, ever. On June 12 I sent the first nine, by private security advisory where the repository had one enabled and by a sanitized issue where it did not. One brief was held back as a likely false positive.

Two maintainers closed the note the same night without comment. The rest went into triage or sat open. That is normal for unsolicited open-source disclosure and I do not read anything into it.

What I can read is the source, because the weekly sweep re-scores every server whether or not anyone answered. Fifteen weeks after the notes went out, of the nine servers I contacted: one has no findings left, one reduced its count, six are unchanged, and one has more findings than when I wrote.

Now the part I did not plan. The other 31 servers in the cohort were never contacted; a second wave of seven went out on September 11, too recently to judge, and the rest are still queued. So the cohort splits into told and not told, and the not-told group is a control I got for free. Among the 31: one fixed, two reduced, 22 unchanged, five worse.

One in nine told. One in 31 not told. With numbers this small I will not claim a difference, and a reader who wants to argue that telling people triples the fix rate has the arithmetic on their side. What I will claim is the thing both groups agree on. Roughly two thirds of high-surface servers were exactly as they were, and more got worse than got better, whether or not anyone wrote to them.

The maintainer whose server now scores clean closed my issue as completed the next morning, without a word, and the flagged patterns were gone by the next sweep. That was the whole interaction. It is also the only one of nine.

The identity gap is the same gap

The second scan the sweep runs asks a narrower question. For servers that take sensitive actions in source, meaning they write files, run shell commands, or write to a database, is there any authentication in front of that code? On June 18 the answer for network-facing, sensitive-action servers was no in 75.4 percent of cases. On September 27 it is no in 75.0 percent.

In absolute terms: 660 servers take a sensitive action with nothing in the source that checks who asked. 190 do check. 251 have auth but no sensitive action. 1,594 do neither. The most common unauthenticated combination is file writes alone, 350 servers, followed by file writes plus shell execution, 201.

Movement over the summer: 30 servers stopped taking sensitive actions, 24 started, 12 put auth in front of a sensitive action, six took it away. Twelve additions in four months, against 660 that need one.

This is the same gap I found from the other side last week. Retailers refuse AI agents at the door because they cannot tell a customer's agent from a scraper. Here is the reason from the agent's side: three quarters of the servers an agent might call have no idea who is calling either. In the MM Trust Layer Model this is the authorization layer, empty at both ends of the connection. The standards bodies are moving, with the IETF, the OpenID Foundation and the FIDO Alliance all carrying drafts. The servers are not.

What the categories say

Where the surface actually sits, counted as servers with at least one finding in the category:

Outbound requests to URLs the code did not hard-code: 941 servers. This is the big one and the least dramatic. A server that fetches whatever URL it is handed is a server that will fetch whatever a prompt injection tells the agent to hand it. It is the exfiltration half of Simon Willison's lethal trifecta, and it is in nearly half the ecosystem.

Code execution, eval and its relatives: 103. Command injection, shell commands built from strings: 54. Together, 157 servers where a string that arrives from outside can become a program that runs inside. The strongest single signal in the whole June batch was a server running eval on data it had just pulled from a remote endpoint.

Unsafe deserialization: 13. Hardcoded credentials in public source: 13. Thirteen public repositories with a key in them is not a large number. It is also not zero, in an ecosystem that has been in the news for exactly this since spring.

None of these is a confirmed vulnerability. All of them are the reason a security review would start.

What would move the number

Not more headlines. The summer supplied those, and the line did not bend. Four things would.

Registries that gate on a surface check. The scan I run is packaged as a GitHub Action that runs the same ten patterns on every pull request. Whether a registry or a client requires something like it before listing a server is the test of whether anyone with leverage wants the number to move.

Auth in the templates. Most MCP servers start from a scaffold. If the scaffold ships with an authentication check in front of the tool handlers, the 660 becomes a number that shrinks with every new server instead of growing. The first commit is the security; fix the first commit.

Client-side allow-lists for outbound requests, so the 941 stop being the agent's problem and become the operator's policy.

And a re-scan with a date on it. I will re-score the 47 on December 12, six months from the first notes, and publish the outcome whatever it is. If the told group has pulled away from the untold group by then, disclosure works at this scale and I will say so. If it has not, I will say that instead.

The ecosystem is going to keep growing. The question the series answers is whether growth was ever going to fix it. It was not.

If a third of the servers an agent can call carry a risky pattern and nobody with leverage is asking them to change, whose job is the number?

Charlie Major is a Product Development Manager at Mastercard. The views and opinions expressed in Major Matters are his own and do not represent those of Mastercard.