MCP Registry metadata and trust boundaries: what IAM teams should watch

TL;DR: The MCP Registry creates a shared metadata catalog for AI applications to discover MCP servers, but its preview design also exposes trust, namespace, and federation gaps that remain unresolved, according to WorkOS. The issue is not discovery alone, but who can publish, validate, and govern server identity across upstream and downstream registries.

NHIMG editorial — based on content published by WorkOS: MCP Registry Architecture, a technical overview of discovery and federation design

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.

Questions worth separating out

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.

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.

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.

Practitioner guidance

• Classify MCP registries as identity-adjacent systems Assign explicit owners for catalog governance, metadata approval, namespace control, and revocation.
• 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.

What's in the full article

WorkOS' full technical overview covers the operational detail this post intentionally leaves for the source:

• OpenAPI schema structure for registry entries and the minimal validation rules used by the catalog.
• Planned namespace verification patterns, including domain proof and GitHub-based publishing models.
• How sub-registries can extend metadata while staying compatible with upstream contracts.
• Caching, pagination, and schema-versioning considerations for scaling discovery across private and public registries.

👉 Read WorkOS' MCP Registry architecture overview →

MCP Registry metadata and trust boundaries: what IAM teams should watch?

Explore further

View Full Forum →  |  NHI Foundation Course →