Module 14 — Registries, Distribution & Supply Chain

Phase 4 · Enterprise Architecture & Mastery. Module 13 governed how requests are controlled. This module governs which servers exist in the first place and how they earn trust — the supply-chain layer. Recall Module 8 T6: installing a server is running untrusted code, before any message is exchanged. Registries and distribution discipline are how an enterprise turns “anyone can add any server” into a governed catalog. Short but essential — supply-chain failures bypass every runtime control you built.

By the end you can:

Explain the role of public and private MCP registries.
Apply provenance, versioning, and pinning to control what runs.
Scope server discovery to identity/groups (tying distribution to entitlements).
Define an org policy for vetting and sandboxing third-party servers.

1. Why distribution is a security problem

Every other module assumed the servers in your environment are the ones you intended. Supply chain attacks break that assumption before runtime controls apply:

A server you install runs with whatever OS/network access its process inherits — it can read files, make network calls, exfiltrate — independent of MCP-level policy.
A server can be benign at review and malicious later (rug pull, Module 8 T3): a version bump silently changes a tool’s behavior or description (and descriptions are model-readable attack surface, Module 4).
A typo-squatted or impersonating server can masquerade as a trusted one.

So governance must cover what may be installed, from where, at which version, and reachable by whom — not just what a running server is allowed to do. This is the layer the gateway alone doesn’t cover.

2. Registries — the catalog of servers

A registry is a catalog of MCP servers (and their tools/metadata) that clients and gateways discover from. Two tiers:

Public / official registry — a community/ecosystem registry where MCP servers are published and discovered. Useful for finding servers, but public ≠ trusted: treat anything from it as untrusted until vetted.
Private / enterprise registry — an org-controlled catalog containing only vetted, approved servers. This is the backbone of enterprise governance: clients and the gateway discover from your registry, not the open internet. New servers enter only through your approval process (§4).

The registry is also where discovery happens — what servers/tools a given consumer can even see. That makes it an extension of your entitlement system (§3).

3. Provenance, versioning & pinning

Three disciplines that contain the “trusted then malicious” problem:

Provenance — know the source and authenticity of a server: who published it, signature/attestation, build origin. Prefer signed servers with verifiable provenance; reject unsigned/unknown-origin servers in regulated environments.
Versioning — track exact versions; treat a server as an immutable artifact at a given version, not a moving target.
Pinning — bind your environment to specific, reviewed versions. A new version must be re-reviewed and re-approved before it’s allowed — this is the direct defense against rug pulls (a version bump can’t silently change behavior if versions are pinned and re-vetted). Pin tool definitions too, and re-prompt for consent when a tool’s definition changes (Module 8 T3).

Together: only signed servers, at pinned and re-reviewed versions, from your private registry.

4. Scoping discovery to identity & groups (distribution = entitlement)

Distribution isn’t just “what exists” — it’s “what each consumer can discover and reach.” Tie the registry to your IdP:

Registry access scoped to IdP groups → role-based access to server groups: the finance team discovers and reaches the finance servers; engineering sees engineering’s. A consumer can’t invoke (or even see) servers outside its entitled groups.
Namespaces / server groups aligned to environments or business units provide logical isolation (the server-layer isolation from Module 12) and reduce blast radius: a compromised consumer reaches only its namespace.
Tool-group bundling (Module 13) complements this: the gateway exposes only the entitled subset of tools per role/tenant.

This makes discovery a first-class part of least privilege: you can’t attack a server you can’t see or reach.

5. Vetting & sandboxing third-party servers

Before a server enters the private registry, and how it runs once approved:

Vetting (entry gate):

Review source/provenance and what the server actually does (tools, the systems it touches, its network egress).
Inspect tool descriptions and schemas for injection/poisoning (Module 8 T3).
Assess required privileges; reject anything over-broad.
Approve a specific version; record who approved and why.

Sandboxing (runtime containment):

Run servers with least-privilege OS isolation — restricted filesystem, restricted/allow-listed network egress, minimal env/secrets, containerization.
Remember roots are a declared boundary, not enforcement (Module 5): back them with real OS/container sandboxing so a misbehaving server cannot exceed them.
Isolate per tenant/business-unit where risk warrants (Module 12).

Vetting decides if it runs; sandboxing limits what it can do if it misbehaves anyway — defense in depth around the supply-chain boundary.

6. Milestone exercise

Define your org’s policy for adding a server to the catalog:

Vetting checklist — the concrete checks a server must pass to enter the private registry (cover provenance, tool/description review, required privileges, egress).
Approval — who approves, what’s recorded, and how a version bump is handled (tie to pinning + re-review).
Scoping — how the server is scoped to IdP groups / namespaces so only entitled consumers discover and reach it.
Sandboxing — the runtime isolation you’d impose, and how it backs up roots.
Threat tie-back — name which Module-8 threats (T3, T6 especially) each measure addresses.

Self-check:

Discovery is from a private, vetted registry, not the open public one, for production.
Servers are pinned to reviewed versions; a new version triggers re-review and consent re-prompt on tool changes.
Server access/discovery is scoped to IdP groups/namespaces (distribution as entitlement).
Sandboxing provides real OS/network containment that backs the declared roots boundary.
Each measure maps to a concrete supply-chain/poisoning threat.

With distribution governed, your platform is trustworthy end to end. Next: Module 15 — Observability, reliability & scale — running it in production.

Quick reference — Module 14 glossary

Registry — catalog of servers/tools for discovery; public ≠ trusted; enterprises run a private, vetted registry.
Provenance / versioning / pinning — known signed source; immutable versions; bind to reviewed versions, re-review on bump → defeats rug pulls.
Scoped discovery — registry access tied to IdP groups; namespaces/server groups per BU/environment; you can’t attack what you can’t see.
Vetting — entry gate (source, tool/description review, privileges, egress, approval recorded).
Sandboxing — least-privilege OS/network isolation that enforces what roots only declares.