Self-hosted MCP registries turn tool governance into a control point

At a glance

What this is: This is a guide to self-hosted MCP registries, showing why a private, signed and scanned source of truth is the governance layer that production MCP deployments need.

Why it matters: It matters because IAM and platform teams need a way to control which MCP servers can be approved, distributed and loaded before scattered distribution channels create audit and provenance gaps.

Context

MCP governance breaks when approved servers are treated like ad hoc code drops instead of governed identity-bearing artifacts. A self-hosted registry fixes that by turning the approved server list into a controlled source of truth, which is the first prerequisite for any durable MCP security guide model.

The problem is not only distribution, but trust. When teams pull servers from repositories, zip files, or public registries, they lose inventory, provenance, and admission control at the point where those tools enter production.

Key questions

Q: What breaks when MCP servers are distributed through GitHub repos or zip files instead of a registry?

A: The organisation loses inventory, provenance, signed identity and admission control. That makes it impossible to know which MCP servers are approved, which version is running, and whether the artifact that reached production is the one that was reviewed. A registry exists to close that trust gap before runtime, not after an incident.

Q: When should organisations prioritise a self-hosted MCP registry over public distribution channels?

A: As soon as MCP servers touch production systems, customer data or systems of record. At that point, the risk is no longer about convenience but about who can approve artifacts, how versions are pinned, and whether security evidence can survive audit and incident review. Public channels are upstream sources, not governance boundaries.

Q: What are the signs that MCP governance is failing?

A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

Q: How should teams govern MCP servers once they are discovered?

A: Classify recurring MCP servers as managed access objects, not personal tooling. Put approved servers behind a shared control point, assign ownership, restrict who can use them, and remove direct local registrations that cannot be reviewed or logged. That approach keeps productivity while restoring observable access governance.

Technical breakdown

Why a registry is the admission control for MCP servers

A self-hosted MCP registry is not just storage. It is the admission point where an organization decides which MCP servers are allowed into circulation, which versions are pinned, and what evidence must exist before runtime loading. That matters because MCP servers are executable tool surfaces, not static documents. Once the registry becomes the policy boundary, signing, scanning, version pinning, and provenance can be enforced before distribution instead of after exposure. Without that boundary, the organisation is relying on informal distribution trust and hoping downstream controls will compensate.

Practical implication: Treat registry admission as the control that decides whether an MCP server is governable at all.

Why OCI packaging matters for identity and audit

Packaging MCP servers as OCI artifacts gives the registry a stable integrity model: digests can be pinned, signatures can be verified, and attestations can travel with the artifact. That is stronger than mutable repositories or ad hoc zip files because the identity of the artifact is no longer tied to a path or a branch name. It also aligns MCP distribution with broader cloud-native artifact controls, which makes registry governance easier to integrate with existing platform security patterns.

Practical implication: Use immutable OCI digests so the loaded server is the same artifact that was reviewed and approved.

Why registry and runtime policy must share one audit chain

A registry can approve an MCP server, but a runtime decides what actually loads and what it can do. If those two layers keep separate policy languages or separate logs, governance fragments at the seam. The article’s core architectural point is that the registry, runtime policy, and audit trail should be chained together so the organisation can prove what entered, what executed, and what was denied. That is the difference between cataloguing software and governing it. Read the Ultimate Guide to NHIs: Regulatory and Audit Perspectives.

Practical implication: Connect registry admission, runtime enforcement, and audit logging into one control chain.

Threat narrative

Attacker objective: The objective is to get a malicious or compromised MCP server approved, distributed, and loaded as if it were trusted software.

1. Entry occurs when teams source MCP servers from public repositories, npm packages, zip files, or informal shares instead of a governed registry.
2. Credential or artifact trust is then abused because mutable sources make it impossible to know which server version or provenance is actually running.
3. Escalation follows when a compromised or malicious server reaches IDEs and production runtimes without a scanning gate, signed attestation, or pinned digest.
4. Impact is uncontrolled tool execution, weak auditability, and a larger blast radius when compromised MCP servers touch production systems or data.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Self-hosted MCP registry governance is now a baseline control, not an optional platform nicety. Once MCP servers move into production, the registry becomes the only place where approval, signing, version pinning, and audit can be made consistent across teams. A patchwork of repos and zip files leaves too much room for shadow distribution and unreviewed tool surfaces. The practitioner conclusion is simple: if there is no governed registry, there is no durable MCP control plane.

Provenance only has value when it survives the handoff into runtime. The article correctly distinguishes between build evidence and artifact safety, which is where many supply-chain models stop too early. A signed build record does not prove the server is safe to load, and a runtime log does not prove what was originally reviewed. The registry needs to carry both artifact identity and security evidence forward.

Shadow MCP is a governance failure, not just a discovery problem. When developers can still fetch servers from internet sources, the organisation has not centralised trust, it has merely added another catalog. That is why the article’s emphasis on inventory and controlled admission matters more than the packaging format itself. The practitioner conclusion is to treat unmanaged MCP use as a policy exception that must be eliminated, not monitored indefinitely.

Air-gapped and disconnected operation changes the registry requirement from convenience to survivability. Federal, defense, healthcare and OT teams cannot depend on online registry availability or upstream trust at runtime. That means the registry has to function as a self-contained control environment, not a proxy for public distribution. The practitioner conclusion is to design for isolated operation from the start, because retrofit is where governance usually collapses.

Registry and runtime are complementary control planes, and separating them reintroduces the same fragmentation the registry was meant to remove. The article’s strongest architectural point is that curation without enforcement is incomplete. The implication is that platform teams should evaluate MCP governance as an end-to-end system, not as a set of independent tools.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Read next: MCP Security Guide

What this signals

Registry-first governance is becoming the practical boundary for MCP security. Teams that continue to treat MCP servers as informal artifacts will keep rediscovering the same failure pattern: no inventory, no provenance, and no defensible audit trail. The stronger model is a governed admission layer that decides what is approved before any runtime sees it.

Supply-chain evidence has to move with the artifact. If review, scan and signing evidence can be separated from the server itself, then the evidence is only loosely attached to the trust decision. A self-hosted registry should make artifact identity, provenance and enforcement travel together so platform teams can prove what was approved and what was loaded.

For practitioners

• Inventory every MCP server source Sweep IDEs, agent runtimes, CI/CD systems and developer endpoints to find where MCP servers are actually coming from before you standardise the registry boundary.
• Stand up a self-hosted admission point Implement a registry that mirrors approved MCP servers, enforces scanning before admission, and serves approved artifacts through the MCP registry API.
• Require immutable artifact identity Pin approved MCP servers to OCI digests and reject floating tags or mutable references that can change after review.
• Attach provenance to the artifact itself Store signing, review and scan evidence as signed attestations that travel with each MCP server instead of keeping the evidence in a separate system.
• Align registry and runtime policy Use one policy model for admission, tool-level permissions and audit so that a server cannot be approved in one place and governed differently in another.

Key takeaways

• A self-hosted MCP registry changes MCP governance from informal distribution to controlled admission, signed provenance and auditable enforcement.
• The article’s core warning is that GitHub repos, zip files and public registries do not provide a reliable inventory or audit boundary for production MCP servers.
• The governance answer is to treat the registry, artifact policy and runtime enforcement as one control chain rather than three separate problems.

Related NHI Mgmt Group resources: MCP Security Guide · Ultimate Guide to NHIs: Regulatory and Audit Perspectives · CI/CD Pipeline Identity Security Guide · Shai Hulud npm malware campaign

Key terms

• Self-hosted MCP registry: An internal registry that owns approval, signing, versioning and distribution of Model Context Protocol servers. It becomes the organisation’s controlled source of truth for what can be loaded, what version is approved, and what evidence exists for audit and incident response.
• Artifact Attestation: Evidence that a build output was produced by a trusted process and has not been altered before execution. It is a practical control for software and AI supply chains because it helps separate approved runtime inputs from files that merely look legitimate.
• Tamper-Evident Audit Logs: Tamper-evident audit logs are records of security and system activity designed to reveal any unauthorized change. They use cryptographic hashing, chained entries, or signed timestamps so deletions, edits, or insertions become detectable during review. In identity and security operations, they support accountability, incident investigation, and regulatory evidence.
• Pinned digest: A fixed cryptographic reference to an artifact version that prevents silent changes after approval. For MCP servers, digest pinning turns version selection into a verifiable control instead of a mutable pointer that can be replaced without obvious warning.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.