MCP Server Security Begins Below the Version Number
A pinned version number does not pin the packages beneath an MCP server or the tools it advertises. Corelight's measurements, a registry census and Uber's gateway point toward what locking, diffing, admitting and rolling back the tool surface could look like.
On an administrator's workstation, an AI coding assistant started one MCP server 162 times in a week. Corelight, which published its measurements on 10 November 2026, reports that the server's dependencies were resolved fresh whenever its environment rebuilt, and the release tag in the configuration stayed where it was. That gap, between the version number a team reads and the code that actually runs, is the part of MCP server security that a version pin cannot reach.
My impression is that much of the practical advice on this subject stops at the top level server version: pin it, skim the release notes, move on. That advice is incomplete rather than wrong. The sentence from Corelight's write up that I keep returning to is the plainest one: pinning a package's version doesn't necessarily pin the packages it depends on.
Where MCP server security actually breaks
The numbers from the review are concrete. Cloud Security Alliance Labs reports that one community server, configured to a single release tag and commit, was rebuilt 19 times over five weeks and ran with 15 distinct dependency sets. Help Net Security, reporting the Corelight work on 13 November, counts 23 of one server's 69 packages changing versions, among them the cryptography library, the JSON Web Token library and the MCP software development kit itself.
The mechanism is less dramatic than the outcome. Corelight describes the launcher resolving dependencies fresh whenever the environment rebuilt. The launcher was uvx, which does its work in one step, and that path skipped the project's hash pinned lock file. As a result, about 60 transitive packages, meaning the dependencies of dependencies, were pulled from PyPI each time the environment rebuilt. The word quiet is mine rather than Corelight's. As I read the mechanism, no step in that chain was a decision about the cryptography library, and that is what makes the change easy to miss.
Pinned MCP server dependency drift at launch
Two things teams tend to merge are worth separating. The release tag is a decision the author made and published. The installed dependency tree is what the machine produced later, on its own schedule, and a review of the first tells a reviewer very little about the second. Corelight is careful to call this a setup choice rather than a flaw in MCP itself (Cybersecurity News), and that distinction matters. On the evidence I have, the protocol is not where the failure sits. The gap lies between the protocol and the step where code is fetched. The Corelight measurements are an example of MCP server dependency drift, and the label is mine rather than Corelight's, but that is my reading of where pinned MCP server dependency drift lives.
Freezing the launch path has a price
Corelight's remedy is simple to state. It froze five servers by pinning each to a commit, installing from a hash pinned lock file, launching them directly and turning off update checks. Each of the five completed an MCP handshake and offered the same tools as before. That last clause deserves weight, with its scope attached. Five cases cannot show that the two layers can be handled separately in general, but in these five the freeze left the tool list where it was.
Freezing has a cost. Help Net Security reports that in one frozen server, 40 packages were older than the versions the launcher would have pulled that same day, and some were security sensitive. Freezing ages code. A freeze trades silent change for silent age: the packages stop moving because nobody asked them to, while the calendar carries on regardless.
The remedy also separates installation from launch: install once, verify, then start the server without resolving anything new. My view is that the frozen state is a starting position rather than a resting one. The interesting question is when the lock file gets reopened, by whom, and against which diff. Five frozen servers is not a sample large enough to settle anything, but it is enough to show that the question can be asked on purpose rather than by accident.
MCP server security at the tool surface
The second kind of drift does not live in the packages. It lives in what a server tells a client it can do. A single author census of a public MCP registry snapshot, covering 21,643 servers as of August 2026 and posted as a preprint in mid September, found that half of multi version servers changed what they advertise, and about two in five did so silently (arXiv). The same work counts 370 servers that moved their endpoint host while keeping a stable name.
The census associates silent drift with nearly threefold higher odds of a high severity finding. The author presents that as correlational, and it should be read that way. A server that drifts silently may simply be badly kept, for reasons that also produce findings. My hypothesis, which a correlational design cannot establish, is that the trouble sits in change over time rather than in any single state of a server. That is a thin base for a claim of this weight, resting on one preprint and one rater.
The more structural point sits in the registry itself. According to the census, none of the 72,606 version records in the registry carries tool definitions (arXiv PDF). Whatever a version record captures, it does not capture the tool descriptions a model reads, so a reviewer who follows version numbers is looking at a different object.
The protocol addresses part of this, though only part. The June 2025 specification asks servers that declare the listChanged capability to send a notification when the tool list changes (MCP specification). The text dated 28 July 2026 says the tool set may change over time but must not vary per connection, and it routes notifications to clients that opened a subscriptions listen stream with toolsListChanged (MCP GitHub). The per connection rule is a sensible line to draw. It governs variation between connections, not change over time, which is where the census points. It is too early to judge how many clients implement the 2026 notification rules, and a notification may not reach every place a server runs.
The census's zero count for MCP tool poisoning deserves the same care. The scan was single rater and pattern based, and the zero covers only overt poisoning, meaning poisoning that a pattern can see. A tool description that steers a model without tripping an obvious pattern would not appear in that count, so the zero is not evidence that the tool surface is clean.
MCP gateway admission and rollback, as Uber runs them
Uber's write up, dated 1 October 2026, is a concrete public description of admission and change control, with the caveat that its scale is far from typical. Uber reports more than 800 MCP servers and more than 5,000 tools under management (Uber Engineering). In the MCP gateway's design, the registry is the control plane, holding the catalogue, ownership and enablement state, while a proxy gateway carries the traffic as the data plane.
The admission rule is the part I would copy first. Every server and tool starts disabled, and the owning team has to review and enable it. Discovery is not exposure. A tool that shows up in a catalogue has not yet been given the right to act, and that distinction is easy to lose when a catalogue looks tidy. It also connects back to the dependency argument: a server that arrives through a launch path nobody reviewed has been admitted without anyone deciding to admit it.
Change control is the other half. Every change to a tool description triggers a config change, diff style review, after which owners approve and deploy, and can roll back to a previous known version. Yahoo Tech's coverage adds that the gateway enforces charter policies at the tool level and applies PII redaction automatically (Yahoo Tech).
Industry observers have drawn parallels to older patterns. Kelly Goetsch of Pipe17 said the design resembles gateways built first for APIs and later for GraphQL (LAVX News). I think that comparison is fair. The API world already knew about catalogues, owners and change review. What differs with MCP is who reads the diff. A change to a tool description changes what a model is told it can do with a tool, so the review is partly about behaviour, and a schema comparison alone will not show that.
A ZenML summary of Uber's write up notes limited independent evaluation of reliability, agent task quality, latency or cost (ZenML). Few enterprises operate anywhere near that scale, so what transfers is the shape of the controls rather than the numbers. For anyone asking what an MCP gateway is, the Uber split offers a working answer: an MCP server exposes tools, while a gateway sits between agents and those servers, deciding which tools are enabled and carrying the calls.
Treating a server as a dependency that holds keys
I think an MCP server holding an API key or an administrator credential is a dependency with privileges, and that framing is a sensible place to start. Dependencies get locked as well as pinned. Installation gets separated from launch. The tool surface gets diffed on every change, rather than only when a version number moves. Tools get admitted one at a time by someone who carries the consequences of enabling them. The rollback target becomes a known tool surface as well as a known binary.
Read this way, MCP supply chain security is less about trusting a publisher than about deciding who reviews what a server is allowed to fetch and say. InfoWorld approaches a related point from another direction. Its argument is that MCP and A2A define how agents present credentials but do not govern them, and it calls for identity management, AI context governance and agent operations layered on top (InfoWorld). Uber handles part of that inside its own gateway, and the two overlap without being the same. A gateway can say which tool is enabled. It does not, by itself, settle which identity ought to hold the credential behind that tool.
The site has covered the protocol's rise in Model Context Protocol Becomes the Default Agent Standard, and the governance side in Agentic AI Governance: From Policies on Slides to Code in Production.
Some caution applies in both directions. Corelight sells network detection and response products, so its framing carries commercial interest. It did not name the 35 servers it reviewed, and its sample is not representative of the wider ecosystem. It found no compromise on the workstation, and it describes the attacks it cites as general npm and PyPI incidents rather than confirmed MCP specific compromises. Lagermann, from Corelight, says he sees the same pattern in customer environments. That is anecdote rather than measurement (Help Net Security).
A pinned tag records a promise an author made on one day. The tool list can change on any later day, and the person holding the credential behind the server may be the last to hear about it. I do not have a neat answer to who ought to watch it, and I suspect the answer differs from one organisation to the next. Is it the server's author, the team that enabled the tool, or the group that keeps the catalogue? Whichever it is, someone has to be the one woken when the list changes on a Sunday.