Topic starter
08/06/2026 4:17 pm
TL;DR: The MCP Registry solves discovery for model context protocol servers, but authentication remains the real governance gap because API keys add friction, sprawl, and weak revocation patterns, according to WorkOS. OAuth aligns registry-based access with scoped, revocable, standardised identity controls instead of standing credentials.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “Why OAuth is the right fit for the MCP Registry”.
Key questions
Q: What breaks when API keys are used as the main MCP credential?
A: Persistent API keys create a standing secret that can outlive the task, the session, and sometimes the user who triggered it.
Q: Why is OAuth a better fit than static keys for MCP registry access?
A: OAuth fits better because it ties access to token scope, refresh, and revocation instead of a permanent shared secret.
Q: How can organisations tell whether MCP access is actually being governed?
A: A governed MCP deployment can answer who requested access, what scope was granted, when the token expires, and which tool calls were made under that token.
Practitioner guidance
- Define a registry access standard Require every MCP server onboarding flow to use a documented access pattern with ownership, scope, and revocation rules before it enters production use.
- Prioritise OAuth for server connections Make OAuth the default authentication method for registry-discovered MCP servers so access can be scoped and revoked through the identity layer.
- Inventory existing API keys List all MCP-related API keys, assign owners, and set a revocation date for any key that cannot be tied to a specific business purpose.
Bottom line: MCP registries improve discovery, but they do not by themselves make access governable or auditable.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 3 days ago by NHI Mgmt Group
08/06/2026 5:51 pm
Registry discovery without a common auth model creates governance debt: A central MCP catalogue solves findability, but it does not solve control. Once every server defines access through its own API key pattern, identity teams lose consistency in provisioning, revocation, and auditability. The practical conclusion is that discovery platforms need an access standard, not just a search index.
A few things that frame the scale:
- 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.
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: When should organisations keep API key support for MCP servers?
A: Only when a narrow use case cannot support OAuth, such as a controlled automation path with an explicit owner and review cadence. Even then, the exception should stay limited and documented, because static keys create lifecycle risk that grows as the server estate expands. OAuth should remain the default for human and interactive connections.
👉 Read our full editorial: MCP registry discovery needs OAuth to make access governable
This post was modified 3 days ago by NHI Mgmt Group