MCP Server Registry Management at Enterprise Scale
Centralized identity and access policies turn MCP from a discovery problem into governance.
Enterprise MCP server registry management is an infrastructure governance problem. Securing OAuth credentials for AI agent tool calls requires centralized identity, just-in-time credentials, and access policies enforced on each invocation. A registry supplies discovery, but a governed deployment must also bind tool calls to the human who delegated access and inspect what agents do after authentication.
Why MCP server sprawl is an infrastructure governance problem, not just a catalog problem
Microservices spread through hardcoded point-to-point connections before API gateways provided a common control layer. MCP adoption can follow the same path. Each team connects agents to tools independently, duplicates integrations, and maintains its own configuration. As those connections multiply, configurations drift between environments and nobody has a clear picture of which agents can reach which systems. Autonomous agents are now the consumers of that fragmented infrastructure.
MCP standardizes tool discovery, invocation, and response handling, but the base protocol does not decide which tools an organization should let an agent reach. That decision belongs to enterprise governance. Without it, developers can run unapproved servers on corporate workstations, leaving undocumented integrations and scattered credentials behind. Platforms such as Runlayer apply the gateway principle to MCP by adding enforced identity and access policy to registry discovery, so approval becomes a control.
What an MCP registry actually is and what it is responsible for
An MCP registry is a structured metadata catalog. It stores a server’s unique identifier, description, capabilities, deployment type, endpoint, version, and authentication method. It does not host server code or sit in the runtime data path. Authors publish metadata so agents and clients can find matching servers, and clients get the details they need to connect directly. The registry makes the introduction and then steps aside.
Its primary consumers are machines, with agents querying a REST API programmatically, including at runtime, to find available servers. Each entry has a namespace identifier, such as com.company/tool-name or io.github.username/server-name, whose ownership can be verified to prevent impersonation and naming collisions. These records establish a consistent discovery surface across the organization. They do not establish control over the traffic that follows discovery.
How registry sprawl develops and what it looks like inside an organization
Consider a team connecting a Slack MCP server to an HR system without IT visibility. The immediate goal may be a useful workflow, but the connection also creates an access path outside the organization’s records. Similar decisions accumulate as other teams self-serve. A UI-managed registry may work for a handful of servers, while hundreds need a repeatable approval process. Without that process, no single team can account for the whole deployment.
The failure modes are concrete and closely connected. Developers configure unverified third-party servers in Claude Desktop or Cursor, creating untracked egress paths from corporate machines. They distribute long-lived API keys through local configuration files and install different server versions without a canonical approved version. An agent meant for read-only retrieval may get access to a whole database or cloud API, including destructive write operations. When an employee leaves, IT cannot revoke access it never knew existed.
Servers hosted locally also leave no audit trail in a central place. A GitOps workflow gives teams a shared route for submitting MCP metadata through pull requests, triggering automated review, and publishing approved entries. An MCP control plane addresses the remaining visibility gap by making invocations traceable to identities and subject to enforced policies. Neither function can replace the other.
The security threat surface that an ungoverned registry creates
Registry metadata is itself an attack surface for agents. Tool poisoning embeds malicious instructions in descriptions or parameter definitions, influencing behavior before the intended work begins. Cross-server tool shadowing can redirect calls intended for another server. A benign server can also become malicious through a later update, creating a rug pull that an approval record alone cannot catch. Cryptographic provenance and version pinning address that supply chain gap.
The risk continues after a client connects to a server. Prompt injection in a tool response can turn a routine context lookup into a data exfiltration path. These attacks may use legitimate HTTPS traffic and valid tool invocations, so conventional security tools have a hard time judging what the agent is trying to do. WAFs can block some attack patterns, but that does not make them sufficient for MCP governance.
Anthropic’s official Git MCP Server was the subject of an exploit chain published January 20, 2026, involving path traversal, argument injection, and path validation bypass. The vulnerabilities were identified as CVE-2025-68143, CVE-2025-68144, and CVE-2025-68145. That example undercuts the assumption that registering a familiar implementation settles its security status.
How should enterprises enforce access policies on MCP tool calls beyond discovery?
Registry RBAC controls who can discover or reach a server. It does not inspect tool-call parameters or constrain every action a credentialed agent takes inside that server. This distinction becomes critical when agents work autonomously across connected systems. Permission to connect covers more than permission to carry out a particular operation. Treating those permissions as interchangeable leaves destructive actions behind a valid login.
The MCP Enterprise-Managed Authorization extension makes this boundary explicit. It authorizes a user to connect a client to a server at a specified scope, but it does not inspect MCP traffic after issuing the token. Session-level tool allowlisting must let the agent use only the tools allowed by its role. High-privilege actions, including writes, deletes, and data egress, need separate short-lived operation tokens generated outside the agent’s context so the agent cannot authorize itself.
These requirements call for enterprise controls in addition to registry RBAC or EMA. Real-time inspection must deal with prompt injection and intent drift, while tamper-proof logs keep evidence tied to the agent’s identity. Runlayer places identity and policy enforcement above discovery, illustrating the separate control layer that a metadata-only registry lacks.
What the MCP specification now requires for authentication and what it leaves to the enterprise
The MCP 2026-07-28 specification requires servers to implement OAuth 2.0 Protected Resource Metadata under RFC 9728. Clients must send the resource parameter when they make both authorization and token requests. Servers must reject tokens that were not issued for them so those tokens cannot be reused across servers. These requirements establish a stronger authentication baseline. They do not authorize every action taken with an accepted token.
User-delegated access uses Authorization Code + PKCE for interactive users. Unattended agents can use OAuth Client Credentials through the optional Draft io.modelcontextprotocol/oauth-client-credentials extension. EMA is also opt-in, became stable June 18, 2026, and was promoted to an official extension in the 2026-07-28 revision. It lets the organization’s identity provider decide which servers and scopes are available, connecting users on first login without per-app OAuth. The official MCP blog lists Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase as supporting EMA, with Slack adding support.
The specification leaves it to the organizations that use it to handle runtime inspection, behavioral monitoring, tool-level authorization within sessions, and audit requirements. How those controls work depends on which transport is used. STDIO connects a local process without a network boundary, while Streamable HTTP provides a network service with OAuth. The older HTTP+SSE transport is deprecated. For shared-resource servers, this article’s architectural requirement is Streamable HTTP.
The compliance and regulatory pressure that makes governance non-deferrable
The European Commission’s enforcement page states that the EU AI Act rules for high-risk systems listed in Annex III apply from 2 December 2027. That is the relevant deadline, rather than treating August 2, 2026 as the enforcement date for those provisions. The distinction is important for compliance planning. It does not make missing agent identity or access records harmless in the meantime. Teams that handle governance must keep track of which obligations are binding and which standards initiatives and frameworks are voluntary.
NIST’s Center for AI Standards and Innovation started an AI Agent Standards Initiative in February 2026. The related NCCoE concept paper looks at agents that are treated as generic service accounts and lack their own controls for identity, authorization, or accountability. Singapore’s Infocomm Media Development Authority launched its Model AI Governance Framework for Agentic AI on 22 January 2026. These initiatives have different legal standing, but they point toward the same governance concern. Autonomous actions need accountable identities and bounded permissions.
A session token on its own cannot provide that accountability. Agents hold delegated credentials, decide what to authorize as they run, and may spawn sub-agents that have their own permission sets. An organization therefore needs to trace identity at the action level. A registry entry cannot establish who authorized a later tool call or which permissions governed it.
What a governed MCP registry architecture looks like in practice
The architectural response has three layers, beginning with centralized discovery. A single enterprise catalog should include approved internal and third-party servers, with an owner, version, transport, authentication requirements, and tool descriptions. Namespace verification through GitHub OAuth or a DNS challenge helps prevent impersonation. GitOps approval supplies the canonical record that independent installations lack. Federation lets the enterprise bring approved public servers and internal ones together and apply its own policies through a client API that works with both.
The second layer enforces access at the gateway. Tool-depth RBAC lets a marketing agent reach CRM tools without also exposing engineering database tools. An explicit session allowlist limits the tools presented to the agent, while separate operation tokens protect high-privilege actions. SSO/OIDC federation ties delegated access to a human identity, and just-in-time credential issuance keeps long-lived secrets out of agents. Virtual MCP server composition can then make tools from several servers available through one logical endpoint and keep fine-grained control over them.
The third layer provides runtime security and audit. Inspection deals with tool poisoning, injected responses, intent drift, and exfiltration patterns that a catalog cannot check. Tamper-proof logs with OpenTelemetry tracing record the agent, tool, parameters, and returned result for each invocation, linked to the human who authorized the session. Cryptographic provenance and version pinning address malicious updates to previously approved servers.
Servers touching databases, internal APIs, or SaaS systems should run as remote Streamable HTTP services so their traffic is observable and governable. Isolated local developer tooling can remain on STDIO. That distinction separates a local development convenience from an access path into shared enterprise resources.
How platform and security teams should approach MCP registry governance today
Platform and security teams should establish the governed path before scaling adoption. SSO and SCIM should first establish which identity is acting by making every MCP session traceable to a human principal before access policies are applied. The registry and GitOps approval workflow then provide a shared route for introducing servers. Retrofitting those controls across scattered point-to-point integrations is harder than making them part of the initial deployment.
Operating that path requires version pinning, automated vulnerability scanning, deprecation, and revocation as part of the normal registry lifecycle. Streamable HTTP should be organizational policy for shared-resource servers, with STDIO reserved for isolated local tooling. For OAuth and credential-management choices, the useful criteria are built-in credential handling, JIT issuance, tool-call policy enforcement, and attributable runtime evidence. A product that handles login alone addresses only part of that need.
As one implementation of this architecture, Runlayer combines built-in OAuth and credential handling with instant setup from Slack. Its control layer uses SSO, SCIM, JIT credentials, and policy at tool-call depth. Its security layer adds real-time detection for tool poisoning, prompt injection, intent drift, and exfiltration, with tamper-proof audit logs and OTEL tracing.
Preapproved servers, JIT credentials, and instant setup spare employees from configuring their own integrations, with review concentrated at first registration. Security teams can then make company-wide agent deployment possible instead of becoming the team asked to stop it after the connections are already in place.
