MCP registries are becoming the control point for AI agents

At a glance

What this is: This guide explains how MCP registries centralise AI agent tool discovery and why Kong says the real issue is governance, not just connectivity.

Why it matters: It matters because IAM, NHI, and AI security teams need to decide where discovery ends and enforcement begins when agents can find tools at runtime.

Context

MCP registries solve a basic operational problem in agentic systems: when an AI agent needs a tool, it must first discover that tool, then authenticate and invoke it at runtime. The governance gap appears when discovery is treated as harmless plumbing rather than a control point for AI agent access.

Without a central registry, organisations fall back to hardcoded point-to-point connections, duplicated configurations, and poor visibility into which agents can reach which tools. That leaves tool discovery, access approval, and auditability outside the identity programme, even though the access pattern is machine-driven and policy-sensitive.

Kong's article frames the registry as the catalog layer and the gateway as the enforcement layer. That split is useful because it makes the governance question explicit: who may publish tools, who may discover them, and what policy follows the agent once it connects?

Key questions

Q: How should security teams handle tool discovery for AI agents in MCP environments?

A: Security teams should treat tool discovery as a privilege boundary, not a convenience layer. Limit the tools an agent can see, defer loading until a task requires it, and log which capabilities were exposed before execution. That reduces context overload and makes misselection easier to detect and investigate.

Q: Why does an MCP registry create risk if it is not paired with runtime enforcement?

A: Because a registry only tells an agent what exists and where it is. Without enforcement in the traffic path, discovery can become unaudited access, which leaves organisations unable to limit misuse, revoke access consistently, or prove which agent used which tool.

Q: What signs show that MCP tool discovery is becoming ungoverned?

A: The warning signs are hardcoded point-to-point integrations, duplicated server configurations, mismatched environment settings, and no central record of which agents can reach which tools. Those symptoms indicate that discovery has escaped the identity and policy model and is drifting into shadow AI.

Q: How do enterprises decide between a public MCP registry and an internal registry?

A: Enterprises should use public registries for discovery and evaluation, then shift production governance to an internal registry. The deciding factors are control over access, version pinning, rollback, approval workflows, and visibility into public and private servers. If sensitive data, compliance obligations, or multiple teams are involved, internal control is the safer operating model.

Technical breakdown

How an MCP registry separates discovery from enforcement

An MCP registry is a metaregistry, meaning it stores metadata about MCP servers rather than hosting the servers themselves. Agents query the registry to discover what tools exist, where they are deployed, and what authentication they require. The registry supports publish, discover, and consume, but it does not sit in the traffic path. That architectural split matters because discovery can be dynamic while enforcement remains a separate decision point. In practice, the registry becomes a programmatic catalog for machine consumers, not a human-facing directory.

Practical implication: treat registry entries as governed identity metadata, not just catalog records.

Why registry-only designs create shadow AI by default

Registry-only designs solve discoverability but leave runtime access uncontrolled. Once an agent can discover a tool, nothing in the registry alone prevents unauthorized use, limits blast radius, or creates a consistent audit trail across environments. That means the same registry entry can be visible to too many agents, across dev and production, without a policy boundary. For IAM teams, the issue is not whether the agent can find the tool, but whether discovery is coupled to enforceable authorisation and observability.

Practical implication: do not let discovery scope exceed the policy boundary you can actually enforce.

Why remote MCP servers change the governance model

Remote MCP deployment moves tool execution into infrastructure the organisation controls, which makes governance more realistic than local package installs spread across developer machines. Local deployment is useful for experimentation, but it pushes control out to endpoints and individual clients. Remote deployment allows central logging, rate limiting, access policy, and environment separation. In identity terms, that shifts MCP from ad hoc integration toward a managed non-human access pattern with clearer control ownership and reviewability.

Practical implication: prioritise remote, centrally governed MCP servers for anything beyond experimental use.

Threat narrative

Attacker objective: The objective is to exploit uncontrolled agent discovery and access paths to reach tools and data outside approved governance.

1. Entry begins when an AI agent discovers MCP servers through an ungoverned registry or hardcoded point-to-point configuration.
2. Credential and access scope are then determined at runtime, often without a shared approval workflow or visibility into which agent may use which tool.
3. Escalation occurs when the same discovery path exposes too many tools across too many environments, creating uncontrolled access expansion.
4. Impact is shadow AI at runtime, where unauthorised or unreviewed agent-to-tool use becomes difficult to revoke or audit consistently.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP registries are becoming the policy boundary for agentic access. The article is really about a shift in control plane, not just a better directory. Once agents discover tools at runtime, the registry becomes the place where identity, visibility, and publish rights start to matter. Practitioners should treat registry governance as part of the access model, not as documentation.

Shadow AI in agentic systems starts at discovery, not only at execution. If an agent can find a tool but the organisation cannot explain who approved that discovery path, governance has already failed. The same pattern that created API sprawl now appears in machine-driven tool use, except the consumer is an AI agent and the audit gap is wider. The practical conclusion is that discovery and enforceable authorisation must be designed together.

Runtime enforcement remains non-negotiable even when discovery is centralised. A registry without a gateway only organises the problem; it does not constrain it. Kong's article usefully separates the catalog layer from the enforcement layer, which is the right mental model for NHI control. The practitioner takeaway is to preserve that separation while insisting on a shared identity and policy plane.

Managed agent access needs environment separation as a first-class control. The article repeatedly shows why dev, staging, and production cannot share the same discovery surface. When the same registry feeds every environment, one misconfiguration can expose tools far beyond their intended scope. That makes environment scoping a governance requirement, not an optional hardening step.

Tool discovery for AI agents is creating an identity governance gap that older integration models never faced. The phrase that best captures the article is discovery governance gap: the point where a machine can enumerate available tools faster than humans can approve or revoke them. That gap is where registry design, runtime policy, and observability must converge if the agentic stack is to remain governable.

From our research library:

• 88% of organisations have embedded AI agents in their workflows, according to KPMG's 2026 report.
• Read next: Zero Trust for AI Agents

What this signals

Discovery governance gap: MCP registries make tool discovery scalable, but they also create a new place where access can drift faster than review cycles. When the registry becomes the first stop for machine consumers, the question is no longer whether an agent can find a tool, but whether that discovery path is itself policy-bound.

Enterprises should map MCP registry controls to their existing identity and access model rather than treating them as a separate integration concern. That means distinguishing catalog visibility from runtime authorisation, keeping environment boundaries intact, and logging agent lookups so access decisions remain reviewable after the fact.

For practitioners

• Define registry publish rights Limit who can register MCP servers and require ownership, environment, and authentication metadata before discovery is exposed to agents.
• Separate discovery from runtime policy Keep the registry as the catalog layer, but enforce allowlisting, rate limits, and authorisation in a gateway before any tool invocation.
• Scope agent visibility by environment Ensure development agents do not discover production tools unless the registry explicitly separates environment-bound catalogs and approvals.
• Require auditability for agent lookups Log which agent queried which tool, what metadata it received, and whether the resulting connection was approved or denied.

Key takeaways

• MCP registries shift AI agent governance toward the discovery layer, where visibility, publish rights, and environment scoping become control points.
• A registry by itself does not stop unauthorised tool use, so runtime enforcement and auditability remain necessary.
• Teams should design MCP governance so that discovery does not outrun authorisation, logging, or revocation.

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.
• MCP Gateway: The control layer that relays assistant intent to tools and data sources through the Model Context Protocol. In practice, it becomes a policy boundary, not just a transport layer. If it trusts model output too early, it can turn unverified reasoning into real-world execution or disclosure.
• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Agentic discovery: Agentic discovery uses software agents to gather evidence from multiple operational sources, infer likely ownership or dependency relationships, and surface uncertain cases for human review. The value is not raw automation. It is the ability to reason across fragmented context with traceable evidence.

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.