Notifications
Clear all
Topic starter
07/06/2026 9:13 pm
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
08/06/2026 9:05 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP Registry architecture raises new identity and trust questions
