MCP registry discovery needs OAuth to make access governable

At a glance

What this is: The article argues that MCP Registry discovery is useful, but OAuth is the access model that makes registry-based MCP connections governable.

Why it matters: IAM and NHI teams need to treat registry discovery and authentication as separate controls, because searchability alone does not solve revocation, scope, or credential sprawl.

Context

MCP Registry discovery solves the question of what servers exist, but it does not solve who can connect to them or how that access is governed. In an MCP environment, the access model matters as much as the catalog because discovery without authentication leaves teams with visible services and unmanaged credentials.

The article's core argument is that API keys fit neither the user experience nor the lifecycle governance needs of a registry-based model. OAuth aligns better with scoped access, revocation, and standard identity infrastructure, which makes the registry usable without turning every server connection into a one-off credential management exercise.

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. If that key is copied, logged, or reused, the server has no built-in way to distinguish legitimate use from abuse. Short-lived credentials reduce that exposure window.

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. That lets IAM teams control access through the identity layer rather than through individually managed credentials. It also reduces the chance that a single leaked key gives broad, lingering access to a server connection.

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. If logs only show a shared credential or generic server activity, the organisation does not have effective identity governance for the protocol.

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.

Technical breakdown

Why registry discovery does not equal governable access

A central registry reduces discovery friction by cataloguing available MCP servers, but discovery only answers where a service is. Access governance still requires authentication, authorisation, and revocation that can be applied consistently across providers. When each server issues its own API keys, the registry becomes a directory of endpoints with no common identity plane behind it. That creates operational drift: users can find services quickly, but the organisation cannot reliably standardise how those services are accessed, scoped, or disabled.

Practical implication: Treat the registry as a discovery layer and define a separate access standard before onboarding servers.

Why API keys break lifecycle control in MCP ecosystems

API keys are easy to issue, but they are poor at lifecycle governance because they usually persist until someone remembers to rotate or revoke them. In a registry-based workflow, every new connection can add another long-lived secret that must be stored, tracked, and manually cleaned up later. That spreads credential risk across clients and providers. The governance problem is not just leakage, but accumulation: the more servers developers try, the more unmanaged credentials accumulate outside a central control model.

Practical implication: Minimise API key use for registry-discovered servers and map every credential to an owner, purpose, and revocation path.

How OAuth maps better to scoped MCP access

OAuth is a better fit because it moves MCP access from static shared secrets to token-based authorisation with scope, refresh, and revocation semantics. Instead of distributing a reusable key, the user grants access through an identity provider, and the resulting token can be limited to the permissions the server actually needs. That reduces blast radius and makes access decisions more legible to IAM and security teams. It also reuses existing identity infrastructure, which helps standardise connection patterns across many MCP servers.

Practical implication: Use OAuth as the default pattern for MCP server access and reserve API keys for narrow exceptions only.

NHI Mgmt Group analysis

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.

OAuth is the governable access pattern because it externalises trust to the identity layer: The article is really about shifting authority from per-server secrets to reusable identity infrastructure. That matters because token scope, refresh, and revocation are the controls IAM teams already know how to operate at scale. Practitioners should read this as an argument for standardised access delegation, not as a protocol preference.

Long-lived API keys are a poor fit for registry-driven adoption: The registry encourages experimentation, but experimentation multiplies credentials if each connection relies on a separate static secret. That is a lifecycle problem, not a convenience problem, and it grows as server counts rise. Teams need to recognise the accumulation pattern early or they will create a discoverable estate of ungoverned access paths.

MCP access is now an identity architecture decision, not a developer ergonomics detail: The article shows that connection design affects security posture, user adoption, and operational overhead at the same time. Choosing OAuth changes how access is issued, how it is revoked, and how much manual work sits outside the central IAM programme. The conclusion for practitioners is to treat registry onboarding as an identity governance control point.

Scoped tokens change the blast radius of MCP integration: OAuth does not eliminate risk, but it changes the failure mode from permanent credential exposure to bounded, revocable access. That is a materially better fit for an ecosystem built around rapid server discovery and incremental adoption. Practitioners should interpret this as a move from credential sprawl to controlled delegation.

From our research library:

• 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.

What this signals

Registry discovery needs a separate access governance layer: A catalogue can improve adoption without improving control, so IAM teams should not confuse visibility with authority. The operational question is who can connect, on what terms, and how quickly that access can be withdrawn when a server or use case changes.

Static credentials are the wrong default for registry-era MCP access: API keys create credential accumulation because each server relationship tends to add another long-lived secret. OAuth replaces that pattern with delegated access that is easier to bound, review, and remove, which is the governance property teams should optimise for.

Access review alone is not enough for MCP servers: If the access model depends on manually managed keys, review cycles arrive after the most important decision has already been made. Teams should move the control point upstream to issuance and scope, where the blast radius can still be limited.

For practitioners

• 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.
• Separate discovery from authorisation Document that the registry is only a catalogue and does not grant access, then enforce a second control for authentication and permission approval.
• Keep legacy key support narrow Allow API keys only for constrained exceptions such as pipeline automation, and review those exceptions on a defined schedule.

Key takeaways

• MCP registries improve discovery, but they do not by themselves make access governable or auditable.
• API keys remain simple to deploy, yet they create sprawl and revocation friction as server counts rise.
• OAuth better matches registry-based access because it brings scoped, revocable, identity-led control to MCP connections.

Key terms

• Mcp Registry: An MCP Registry is a catalog that lists available Model Context Protocol servers, tools, and resources for AI agents to discover and use. It typically stores metadata such as endpoints, capabilities, ownership, and trust information, helping organizations govern which tools agents can access and how those connections are managed.
• OAuth: OAuth is a delegated authorisation protocol that lets one application grant another limited access without sharing the owner’s primary credentials. In practice, its security depends on how tightly scopes are defined and whether the resulting tokens are monitored and revoked when access changes.
• API Key: A unique identifier used to authenticate a software application or service when calling an API. API keys are static, long-lived credentials and a major source of secrets sprawl. In 2024, over 50 million leaked API keys were found on the dark web.
• Credential Sprawl: Credential sprawl is the uncontrolled accumulation of machine secrets, keys, and tokens across systems, teams, and environments. It usually starts with a single use case and ends with overlapping permissions, unclear ownership, and a larger attack surface than the organisation expected.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.