MCP registry discovery needs OAuth to make access governable

At a glance

What this is: This is a governance analysis of why OAuth fits MCP Registry access better than API keys, with the key finding that discovery without standardised authentication creates friction and credential sprawl.

Why it matters: It matters because IAM, NHI, and autonomous-system teams need a consistent way to control tool access, scope permissions, and reduce standing secret exposure as MCP adoption grows.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read WorkOS's analysis of why OAuth fits MCP registry authentication

Context

MCP registry discovery makes model context protocol servers easier to find, but the primary identity problem remains access control. If discovery is centralised while authentication stays fragmented, teams end up with a broader catalogue of tools and no consistent way to govern who or what can connect to them.

For identity programmes, the issue is not whether OAuth is convenient. The issue is whether registry-discovered tools can be brought under the same lifecycle, scope, and revocation discipline that IAM and NHI teams already apply to other non-human connections. API keys fail that test because they preserve static credentials where the operating model needs revocable, scoped access.

Key questions

Q: How should security teams govern access to MCP registry-discovered servers?

A: Security teams should treat registry-discovered servers as governed non-human access, not as simple developer convenience. Use OAuth as the default access model, require narrow scopes, and keep revocation under central identity control. That gives teams a consistent way to audit consent, reduce standing secrets, and tie server access to lifecycle processes.

Q: Why do API keys create problems in MCP environments?

A: API keys create problems because they are static bearer secrets that do not align with registry-based discovery or delegated consent. Every new server adds another secret to store, rotate, and revoke, which increases operational overhead and weakens auditability. In practice, the result is credential sprawl and inconsistent lifecycle control.

Q: How can organisations tell whether MCP access is actually governed?

A: Governed MCP access shows up as standardised scope definitions, centralised token revocation, and consistent logging across providers. If teams cannot quickly answer who granted access, what scope was approved, and how the token is revoked, then the access model is still operating like a collection of unmanaged secrets.

Q: What should IAM teams do when a tool ecosystem still relies on API keys?

A: IAM teams should classify API key use as standing privilege and decide whether it is a transitional exception or a permanent exception. If it is unavoidable, they need rotation, storage controls, and offboarding checks. If OAuth is available, it should become the preferred path because it better matches lifecycle governance.

Technical breakdown

Why API keys break down in registry-based MCP access

API keys are static bearer credentials. In a registry workflow, that means the user discovers a server in one place but still has to leave the flow, create a key, store it, and manually manage it over time. That breaks the registry promise because the access path is no longer unified. It also creates credential accumulation, where each new server adds another long-lived secret that must be tracked, rotated, and revoked separately. For identity teams, this is not just a usability issue. It is a lifecycle problem caused by credentials that do not naturally align with discovery, consent, or revocation.

Practical implication: treat API keys as an exception path, not the default authentication model for registry-discovered MCP servers.

How OAuth changes MCP server identity and scope

OAuth replaces a static secret with a token-based authorisation flow. The user authenticates once with the provider, grants explicit scopes, and receives a token that can be refreshed or revoked without reissuing the entire access pattern. For MCP, that matters because the registry acts as the discovery layer while OAuth supplies the access layer. The result is a cleaner division of duties: discovery identifies the server, OAuth governs the session, and scope limits what the server can do. That is a better fit for non-human access than permanent keys because the credential is tied to purpose and duration rather than standing entitlement.

Practical implication: define narrow scopes for each MCP server and require revocation paths that match the token lifecycle.

Why standardisation matters more than individual server design

The real value of OAuth here is not just that it works, but that it standardises authentication across many servers. In fragmented ecosystems, every provider inventing its own key model creates different storage, rotation, and audit patterns. OAuth reduces that variance by allowing the same identity provider and consent flow to be reused across servers. That improves auditability and gives security teams a common control surface. For IAM and NHI governance, standardisation is what makes scale possible: without it, each new server is a new exception, and exceptions become the programme.

Practical implication: require common OAuth patterns for all registry-connected servers so audit, revocation, and policy enforcement stay consistent.

Breaches seen in the wild

• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.
• IOS app secrets leakage report — iOS apps leaking hardcoded secrets and credentials endangering user privacy.

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

NHI Mgmt Group analysis

OAuth is the right control plane for registry-discovered MCP access because it converts discovery into governed consent. The registry solves findability, but findability alone does not establish accountable access. OAuth adds a standard authorisation layer that lets teams scope, revoke, and audit access without turning every server into a bespoke credential island. The practitioner conclusion is that registry ecosystems should be designed around consent-driven access, not static secrets.

API keys create identity sprawl the moment registry adoption scales. Each new server introduces another bearer secret, another storage location, and another revocation workflow. That is not a tooling inconvenience, it is a lifecycle burden that multiplies across every developer, environment, and server connection. The practitioner conclusion is that unmanaged API keys become the hidden tax on registry growth.

Third-party registry access needs the same revocation discipline as any other non-human identity. Once a server connection is granted through an external provider, the operational question is whether that access can be removed cleanly when trust changes. OAuth supports that discipline more naturally than permanent keys because tokens can be scoped and expired, while API keys tend to outlive the context that justified them. The practitioner conclusion is to align server access with lifecycle controls, not one-time setup.

Model context protocol adoption is pushing identity governance into tool-selection workflows, not just login workflows. That broadens the control problem from authentication to authorisation of machine-initiated actions. IAM teams that only think in terms of sign-in will miss the fact that server choice, permission scope, and token lifecycle now sit inside the same operational path. The practitioner conclusion is to govern MCP access as part of NHI and delegated authorisation strategy, not as a developer convenience feature.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• OAuth governance becomes the control point to study next in the NHI Lifecycle Management Guide, especially where registry access must be provisioned, reviewed, and revoked cleanly.

What this signals

Registry ecosystems will push IAM teams toward consent-led non-human identity governance. The practical shift is from managing isolated credentials to managing a repeatable authorisation pattern that can be audited and revoked across many servers. That matters because registry growth increases the number of external trust edges, and each edge needs a lifecycle, not just a login.

API key sprawl is a lifecycle signal, not just a technical smell. When teams keep adding static keys for tool access, the underlying issue is that discovery, authorisation, and revocation are not aligned. The governance response is to put registry-connected access into the same review rhythm as other NHI assets, using the NHI Lifecycle Management Guide as the operational baseline.

For practitioners

• Default registry-connected servers to OAuth Make OAuth the standard authentication path for MCP servers discovered through a registry, and reserve API keys for narrow legacy cases where no delegated flow exists.
• Define per-server scope boundaries Map each MCP server to the minimum permissions it needs, then document those scopes in access reviews so teams can verify the purpose of each token.
• Centralise token revocation and audit Route MCP access through identity providers and logging systems that can revoke tokens centrally and preserve traceable consent history across providers.
• Treat API keys as standing secrets Inventory any API key still used for MCP access as a standing credential with elevated governance requirements, including rotation, storage controls, and offboarding checks.
• Embed MCP access in NHI governance reviews Include registry-discovered servers in NHI lifecycle reviews so access assignment, scope changes, and offboarding follow the same control discipline as other non-human identities.

Key takeaways

• MCP registries solve discovery, but discovery alone does not create governed access.
• API keys scale poorly in registry-based ecosystems because they multiply standing secrets and revocation overhead.
• OAuth is the better fit when teams need scoped, revocable, auditable access for non-human identities.

Key terms

• Mcp Registry: A central catalogue of available MCP servers that helps users discover tools and capabilities before they connect. In governance terms, it solves findability, but it does not by itself establish identity, consent, or revocation controls for the server connection.
• OAuth Token: A scoped credential issued after a user or system completes an OAuth authorisation flow. Unlike a static API key, a token can be limited by permissions, refreshed over time, and revoked centrally, which makes it better suited to managed non-human access.
• Api Key: A static bearer secret used to authenticate a client to a service. It is easy to deploy but hard to govern at scale because it often lives outside central identity controls, accumulates across systems, and persists until someone manually rotates or revokes it.
• Non-Human Identity: Any machine or software identity that needs access to systems, data, or tools, including service accounts, tokens, certificates, and AI agents. Governance focuses on ownership, scope, lifecycle, and revocation because these identities often outlive the task they were created for.

Deepen your knowledge

MCP registry authentication and non-human identity lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are standardising access for tool ecosystems that behave like service identities, it is worth exploring.

This post draws on content published by WorkOS: Why OAuth is the right fit for the MCP Registry. Read the original.