MCP Server Governance Starts With the Version You Approved

MCP server governance has to approve a specific version of a server, because the name on a package says nothing about what its next release will do. Bill Doerrfeld argues in a recent article that engineering leaders need internal standards for the Model Context Protocol, and this piece extends that one claim.

Doerrfeld reports that MCP adoption is outrunning governance

Doerrfeld’s article is built around interviews with Angie Jones, VP at the Agentic AI Foundation (AAIF). It argues that engineers have to move from using agents to building them, and that most do not yet have the skills. It reports that Claude has served more than one billion MCP tool calls, a figure shared by MCP co-creator David Soria Parra, and that MCP tool calls on ChatGPT reached 98 times their January level by August 2026, according to the AAIF.

From that adoption, the article concludes that leaders should put internal standards around MCP in place. Jones’s position, as reported, is that downloading an MCP server off the internet is not a secure practice, and that engineers need to decide how servers are governed and what control planes sit around them. The article also urges leaders to build on open standards that are stable and governed by a neutral body.

An MCP server is executable code that runs with your developer’s privileges

The MCP project’s own Security Best Practices document describes local MCP servers as binaries that are downloaded and executed on the same machine as the MCP client. Among the risks it lists are arbitrary code execution with the client’s privileges, no visibility into the commands being executed, and data exfiltration. Its mitigation section says that a client offering one-click local server setup must show the exact command, without truncation, and must get explicit user approval before running it. It also recommends running servers in a sandbox with minimal default privileges.

That guidance is written for the teams who build MCP clients. It protects the moment of installation. It says less about what happens after the developer clicks approve. A command that names a package without a version can resolve to a newer release on a later run, and the consent dialog showed the command, which is a different thing from the code it fetches.

The postmark-mcp case shows why approval by name fails

On 25 September 2025, the email company Postmark published a notice about a malicious npm package called postmark-mcp. According to Postmark, an attacker created a fake package impersonating its name, built trust over 15 versions, and then added a backdoor in version 1.0.16 that secretly BCC’d emails to an external server. Postmark stated that the package was not an official Postmark tool and that it had not published its own MCP server on npm before the incident. It advised users to remove the package, check their email logs, and consider rotating any credentials sent by email during the compromise period.

Consider how an ordinary review would have handled it. A team that vetted the package at an early version would have read code without the backdoor. If its standard recorded the approval against the name postmark-mcp, every later release inherited that approval, including 1.0.16. The review described code that was no longer running. A second check would also have caught it earlier: the package carried the name of a real company that, by its own account, had not published it.

MCP server governance needs a version pin and a publisher check

Doerrfeld’s article calls for internal standards without specifying them, so what follows is my proposal and is not drawn from his article or from any vendor’s product. An approved-servers list should record five things for each entry: the publisher, confirmed against the vendor’s own documentation or repository; the exact version or commit; the name of the reviewer and the review date; the credentials and scopes the server receives; and the person who owns the entry. Configuration files then reference the pinned version, and an upgrade goes through the same review as a new dependency, with someone reading the diff.

Leaders can track one number: the share of MCP servers configured on developer machines and in agent environments that resolve to a version on the list. A team that cannot produce that number does not yet know which code holds its credentials.

There are limits. Pinning only applies to code you run. A remote MCP server hosted by a provider can change on the provider’s side with no version number visible to you. For those servers the control shifts to what the server can reach. The same Security Best Practices document recommends a minimal initial scope set with incremental elevation, and warns that broad tokens expand the blast radius of a compromise. Review also costs time, and a small team may decide to allow only servers published by the vendor whose API they wrap. Neutral governance of the protocol, which the article rightly values, operates at a different layer: a well-run standard does not vet the individual servers built on it.

Why This Matters for Engineering Leadership

Doerrfeld’s reporting shows MCP use growing faster than the internal rules around it. From an AI governance view, an MCP server is a delegate that acts with real credentials on an agent’s behalf, and accountability depends on knowing which code holds those credentials today. A list of approved names answers a weaker question. A list of pinned versions, each with a reviewer and an owner, answers the one that matters after an incident, and it is far cheaper to keep than an email log audit across every team that installed the wrong package.

FAQ