What breaks when MCP servers are fetched at runtime instead of promoted through a catalog?

Why runtime fetches turn MCP servers into a moving target

Promoting an MCP server through a catalog makes it a controlled artifact: teams can pin a version, review the change, and know which code is eligible to run. Fetching at runtime replaces that governed path with a live dependency that can change between executions, which means the same request may land on different code, different permissions, or different trust assumptions.

That shift matters because the registry is no longer just a discovery layer. It becomes part of the execution path, so any drift in metadata, transport, or upstream content can change behavior without a corresponding review event. A cataloged promotion path creates a stable release boundary; runtime fetches remove that boundary and turn the server into an always-current input.

For MCP specifically, this is not a minor operational preference. The server itself is often the place where authorization, tool exposure, and downstream access decisions are defined. The MCP authorization specification assumes the server is a defined resource with explicit authorization behavior, which is much easier to govern when deployment is promoted rather than resolved ad hoc at runtime.

What version certainty, reviewability, and rollback discipline actually require

Version certainty means operators can answer a simple question: which exact server code executed for this request? Reviewability means that code, its configuration, and its trust surface were approved before use. Rollback discipline means a bad release can be reverted to a known previous state, not merely hidden behind a new fetch the next time the registry is consulted.

Those three properties depend on stable release identity. If the registry can silently point to a different implementation, even a well-run approval process loses force because the reviewed object is no longer guaranteed to be the running object. The problem is not just software freshness, it is the collapse of change control into lookup time.

This is why curated promotion and immutable release references are safer than dynamic resolution for operational MCP fleets. MCP Security Guide is useful here because it treats MCP servers as governed security objects, not just endpoint strings to resolve on demand.

Why provenance and policy enforcement fail when the runtime decides what runs

When code is promoted through a catalog, provenance can be tied to a reviewed version, a known owner, and an approved policy set. Runtime fetches weaken that chain because policy is now enforced against a moving target. If the registry changes, the provenance story changes with it, and the team may no longer be able to prove that the executed server matched the approved artifact.

That is also where rollback discipline breaks down. A rollback only works when the prior version is still identifiable, retrievable, and trustworthy. If your execution model depends on whatever the registry serves at the moment of launch, then recovery becomes a re-fetch problem instead of a controlled restoration problem.

Security teams should treat this as an architecture choice with direct blast-radius implications. When MCP servers are fetched on demand, the runtime path can inherit the same exposure patterns seen in software supply chain compromise and malicious package substitution, which is why the AI Supply Chain Security and AI-BOM Guide is relevant to the broader control model.

Practitioner Guidance

What to verify: Confirm that every MCP server used in production has a pinned version, an auditable approval record, and a rollback target that is independent of the live registry. If you cannot reproduce the exact server binary or package after the fact, you do not have meaningful change control.

Decision rule: If the registry can alter the executable server between runs, require promotion through a catalog or a release pipeline before the server is allowed to serve production traffic. Treat runtime fetches as acceptable only for non-production discovery or tightly constrained evaluation paths.

Common mistake: Teams often secure the transport but ignore release identity. TLS protects the connection, not the governance model, so a trusted channel does not fix an ungoverned runtime fetch.

Practitioner takeaway: The real boundary is not where the server is discovered, it is where the server becomes an approved, immutable release. Once that boundary disappears, you lose the ability to explain, review, and recover what actually ran.

Related resources from NHI Mgmt Group

• What breaks when access to servers and databases is managed through broad network reach instead of roles?
• What breaks when AI tools are exposed through loosely governed MCP servers?
• What breaks when MCP servers rely on custom middleware instead of a standard interceptor model?
• What happens when an MCP server is launched through a runtime wrapper instead of being containerized first?