MCP Registry architecture raises new identity and trust questions

At a glance

What this is: The MCP Registry standardises MCP server discovery through a shared metadata catalog, but its current preview leaves trust enforcement, namespace verification, and runtime integrity outside the core control plane.

Why it matters: IAM, NHI, and AI governance teams need to treat registry metadata as an identity-adjacent trust boundary, because discovery without lifecycle, validation, and ownership controls can expand tool exposure faster than programme oversight.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read WorkOS' MCP Registry architecture overview

Context

The MCP Registry is a discovery layer for Model Context Protocol servers, but discovery is only one part of identity governance. In practice, any shared catalog becomes a trust boundary: if metadata can be published, inherited, mirrored, or extended without strong ownership checks, the registry may improve findability while leaving authorization and accountability fragmented.

For AI and NHI teams, the important question is not whether a server is listed, but whether the listed identity is authentic, the metadata is current, and the downstream client can rely on it. The registry’s federation model makes that problem broader, because enterprises will need to govern upstream entries, private sub-registries, and runtime credentials as one connected control surface.

Key questions

Q: How should security teams govern MCP server discovery in enterprise environments?

A: Treat discovery as the start of governance, not the end of it. Teams should require ownership proof, approved metadata, and explicit runtime validation before an MCP server is trusted. Discovery catalogs help users find tools, but they do not prove the server is legitimate, current, or allowed for the requesting context.

Q: Why do MCP registries create new trust assumptions for IAM and NHI teams?

A: Because a registry can publish a server’s metadata without proving who controls the server or whether the declared access model is still accurate. That means identity, authorization, and provenance are no longer tied to a single system. IAM and NHI teams must govern the catalog path and the runtime path together.

Q: What breaks when namespace ownership is not verified in an MCP registry?

A: Without verified ownership, malicious or misleading entries can look authoritative enough to be consumed by clients and sub-registries. That creates impersonation risk, metadata drift, and weak accountability for server publishing. The practical failure is not just bad data, but bad trust decisions built on that data.

Q: Who should be accountable when a federated MCP registry exposes the wrong server or auth metadata?

A: Accountability should sit with the team that approves registry publication, the team that operates the downstream sub-registry, and the team that consumes the metadata in clients. Federation does not remove ownership. It multiplies it, so each layer needs explicit responsibility for provenance, review, and revocation.

Technical breakdown

Registry API and metadata model

The MCP Registry works as an open catalog backed by an API and schema contract. Server publishers submit metadata such as endpoint, supported transport, authentication requirements, and versioning details. The design deliberately keeps validation minimal so the catalog stays flexible and extensible, but that choice also means the registry is describing trust rather than enforcing it. In identity terms, it behaves more like a directory than a policy engine. That distinction matters because a directory can tell a client where to go, but it cannot prove the endpoint is legitimate or safe to use.

Practical implication: treat registry metadata as advisory until ownership, authorization, and server integrity are validated elsewhere.

Federation and sub-registries

Federation is the registry’s central architectural choice. The upstream catalog is intended to be a shared source of truth, while public or private sub-registries can enrich, filter, or mirror entries. That model reduces duplication, but it also creates multiple places where metadata can drift, be curated differently, or inherit inconsistent trust assumptions. In governance terms, federation expands the number of administrators who can influence discovery without necessarily owning the underlying MCP server. For identity teams, that creates a control inheritance problem: the listing path and the runtime trust path are no longer the same thing.

Practical implication: define which registry layers are authoritative for ownership, approval, and deprecation before allowing downstream inheritance.

Namespace verification and trust boundaries

The article describes namespace ownership verification as a proposed future capability, not a fully documented preview feature. That gap is important because namespace controls are the closest thing to identity proof in the registry model. Without verified ownership, a catalog can become a staging area for impersonation, squatting, or misleading server entries. The registry can validate schema conformance, but schema validity is not identity validity. For practitioners, the real issue is whether catalog identity, server identity, and credential identity are being governed as one chain or as separate, weakly linked records.

Practical implication: require namespace ownership checks and out-of-band approval for any MCP server before it is treated as trusted.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Discovery catalogs create identity debt when they are treated as trust controls. The MCP Registry reduces discovery friction, but discovery is not authorization, and metadata is not proof of ownership. That leaves a familiar NHI problem in a new form: the organisation can see the server, but not yet prove who controls it or whether its declared access model is current. The implication is that registry adoption without governance creates identity debt at the point of discovery, not just at runtime.

Namespace verification is the missing control that turns listing into accountability. The article’s proposed ownership checks point to the real failure mode: a registry entry can look authoritative even when no one has verified who is behind it. That is a governance gap, not a feature gap. In NHI terms, this is a named concept worth tracking: registry identity ambiguity. When a catalog can be updated faster than ownership can be proven, practitioners should assume the discovery layer can be manipulated.

Federation broadens the blast radius of inconsistent metadata governance. Upstream and downstream registries make sense for scale, but they also multiply the number of places where policy, curation, and trust can diverge. That means the organisation is no longer managing one catalog, but an ecosystem of inherited metadata decisions. The implication is that registry federation should be governed like any other identity distribution problem: with explicit authority, revocation, and provenance rules.

Tool discovery for AI applications is becoming an NHI governance problem, not just an integration problem. The moment a registry stores authentication requirements, endpoint metadata, and server capabilities, it is participating in access decisions whether it intends to or not. That places it squarely inside the broader NHI control plane. Practitioners should therefore evaluate MCP registries with the same seriousness they apply to service account inventories, secret catalogs, and workload identity directories.

MCP registry maturity will be measured by verification depth, not catalog size. A large, searchable registry is operationally useful, but the decisive question is whether the ecosystem can prove namespace ownership, constrain metadata drift, and reject stale or malicious entries. That is the difference between discoverability and governance. The practitioner conclusion is straightforward: if the registry cannot support provenance, it remains an index, not a trust layer.

From our research:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to Ultimate Guide to NHIs.
• Only 5.7% of organisations have full visibility into their service accounts, which shows how often discovery exists without real governance.
• For a broader control baseline, see NHI Lifecycle Management Guide for how ownership, rotation, and offboarding should align.

What this signals

Registry identity ambiguity: as MCP ecosystems expand, the harder problem will be deciding which catalog entries are authoritative enough to act on. Discovery layers that do not bind metadata to verified ownership will force security teams to create compensating controls in clients, gateways, and approval workflows.

With 97% of NHIs carrying excessive privileges in our research, the registry question is not whether tool discovery is convenient, but whether access decisions can be governed before a server becomes a standing dependency. That makes registry governance part of privilege management, not a separate platform concern.

Enterprises should expect MCP registry management to converge with workload identity and secret governance. The practical model is simple: use discovery for reach, but apply provenance checks, offboarding rules, and policy enforcement through NHI Lifecycle Management Guide principles and external guidance such as the OWASP Top 10 for Agentic Applications 2026 when agentic clients are involved.

For practitioners

• Classify MCP registries as identity-adjacent systems Assign explicit owners for catalog governance, metadata approval, namespace control, and revocation. Treat the registry as part of the access path, not as documentation only.
• Require ownership proof before internal onboarding Do not allow a server to move from discovered to trusted until namespace ownership, publisher identity, and credential requirements have been reviewed and recorded.
• Separate discovery from runtime trust Use the registry for findability, but enforce runtime validation in the client, gateway, or policy layer before any tool invocation or data exchange is permitted.
• Track metadata drift across federation layers Compare upstream entries, private sub-registries, and approved internal catalogs on a schedule so changes to endpoints, auth schemes, and server claims do not bypass review.

Key takeaways

• The MCP Registry solves discovery friction, but it does not by itself solve trust, ownership, or runtime authorization.
• Federated registries increase scale, but they also increase the risk of metadata drift and weak accountability across layers.
• Practitioners should govern registry entries like identity records, with ownership proof, provenance checks, and revocation paths.

Key terms

• Mcp Registry: A shared catalog that lists MCP servers and the metadata clients use to discover them. It standardises how servers are found, but it does not automatically prove ownership, authorization, or runtime safety, so it should be treated as a governance input rather than a trust decision on its own.
• Namespace Verification: A control that proves a publisher controls the identifier under which a server is registered. In MCP environments, namespace verification reduces impersonation risk by binding catalog entries to an accountable owner, but it still needs downstream policy and runtime validation to be operationally meaningful.
• Federated Registry: A registry model where an upstream catalog and downstream sub-registries share a common schema while maintaining local curation or policy. This improves scale and flexibility, but it also introduces drift risk because different layers may apply different trust rules, review processes, or approval standards.
• Registry Identity Ambiguity: A failure mode in which a catalog entry appears authoritative even though the publisher, owner, or trust boundary has not been verified. The result is a mismatch between discoverability and accountability, which can lead clients to make unsafe access decisions based on incomplete metadata.

Deepen your knowledge

MCP registry governance, namespace verification, and runtime trust are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for AI tool discovery and federated metadata, it is worth exploring.

This post draws on content published by WorkOS: MCP Registry Architecture, a technical overview of discovery and federation design. Read the original.