TL;DR: AI agents can shift from hardcoded tool lists to runtime discovery, allowing them to find, select, and execute approved MCP servers as environments change, according to Kong. That improves flexibility, but it also makes tool governance, access boundaries, and registry trust the real control points for agentic systems.
At a glance
What this is: This is an analysis of Kong's MCP Registry approach to dynamic tool discovery for AI agents, with the core finding that registry-driven discovery moves governance away from hardcoded integrations and toward the registry as the control point.
Why it matters: It matters because teams governing autonomous and semi-autonomous systems need to decide who can publish, discover, and execute tools at runtime, and that is an identity and authorization problem as much as an architecture problem.
Context
MCP registry-driven discovery changes the governance model for AI agents because the agent no longer depends on a fixed tool list. In this pattern, the registry becomes the place where discoverability, approval, and environment scoping are expressed.
The practical problem is simple: if tools change faster than agents can be redeployed, hardcoded integrations become brittle. For identity and access teams, that means the control surface shifts from code to registry metadata, access boundaries, and execution trust.
This is an agentic AI architecture issue, but it also has NHI implications because the tools being discovered are often service endpoints, APIs, and other non-human capabilities that need lifecycle control.
Key questions
Q: How should teams govern MCP tools discovered during AI access onboarding?
A: Treat every discovered MCP tool as an entitlement that needs classification, approval, and ownership before use. If a connected app exposes tools to agents, the governance model should say who can approve them, what data they can reach, and whether new tools default to restricted access until reviewed.
Q: Why does hardcoded tool configuration break down for agentic systems?
A: Because it assumes the tool set is stable long enough to be embedded in code. In enterprise environments, tools are added, renamed, retired, and segmented by environment, so static configuration forces redeployment and pushes teams toward unsafe shortcuts.
Q: What are the signs that MCP registry governance is too broad?
A: If development tools appear in production discovery results, if agents can enumerate servers they should not be able to use, or if metadata is too vague to explain why a tool was visible, the registry boundary is too loose.
Q: How do teams decide which MCP servers an agent should be allowed to discover?
A: Start from business role, environment, and ownership, then restrict discovery to the smallest approved capability set that supports the task. Discovery should be narrower than the full catalog, because visibility itself creates risk.
Technical breakdown
How MCP registry-driven discovery changes agent tool selection
In a static design, an agent is preloaded with fixed MCP server entries and connection details. That works until the environment changes, because the agent can only use what was embedded at build time. A registry changes the pattern by letting the agent query a current catalog of available tools, filter by metadata, and retrieve connection details at runtime. The result is not just flexibility. It creates a separation between tool publication, tool discovery, and tool execution, which is the architectural shift that makes governance possible at scale.
Practical implication: treat registry access and registry metadata as part of the agent's effective authorisation boundary.
Why the MCP registry becomes the trust anchor for runtime capability discovery
Once the agent can discover tools dynamically, the registry becomes the source of truth for what the agent is allowed to see. That means metadata such as environment, namespace, ownership, and access boundary are no longer descriptive fields. They become control fields. If the registry exposes a production server to the wrong scope, or if discovery is broader than execution permission, the agent can select capabilities that were never intended for that context. In other words, tool trust moves upstream into the registry and its governance model.
Practical implication: govern registry entries as approved capabilities, not as passive inventory records.
Why hardcoded MCP configurations fail in changing enterprise environments
Hardcoded tool lists assume the tool landscape is stable, the execution path is known, and redeployment is cheap. Enterprise agent deployments violate all three assumptions. New tools appear, capabilities evolve, and environments diverge across development and production. If the agent has to be rebuilt every time a tool changes, governance becomes operationally expensive and teams will bypass it. Dynamic discovery solves the scaling problem, but it also means the agent's runtime choices now depend on live registry data and on how precisely that registry is segmented.
Practical implication: separate development, staging, and production registries so discovery does not collapse environment boundaries.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
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
Registry-driven discovery turns tool publication into an access decision. Once an AI agent can ask what tools exist at runtime, the registry is no longer an index. It is the policy layer that determines which capabilities are visible, in which environment, and under which ownership model. That makes registry governance a first-class identity control for agentic systems, not a convenience feature.
Hardcoded integrations are the wrong control model for environments where capabilities change continuously. Static tool lists assume that discovery, selection, and execution can be frozen at build time. That assumption fails when the agent's operational reality includes new services, renamed endpoints, and separate development and production scopes. The implication is that governance has to move closer to runtime discovery rather than remain trapped in code review cycles.
Named concept, registry trust boundary: The registry becomes the trust boundary for what an agent may discover and therefore what it may attempt to use. If that boundary is too broad, the agent can discover more than the programme intended, even if individual tools are technically approved. Practitioners should read the registry as an identity control plane, not just a catalog.
For agentic AI, discoverability is a governance problem before it is a developer experience problem. The central question is not whether a tool can be found, but whether it should be visible to a given agent, team, or environment. That makes metadata quality, registry segmentation, and access scoping the real determinants of safe adoption.
This pattern also clarifies the boundary between NHI governance and agentic behaviour. The discovered endpoints may still be service accounts, APIs, or other non-human capabilities, but the agent's runtime decision to find and use them adds a governance layer that older machine-identity models did not have to manage. Teams need to govern both the capability and the chooser.
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.
- Read next: MCP Security Guide
What this signals
Registry trust boundary: In agentic systems, the registry is the control plane for what an agent can discover, not just a catalog of what exists. That means discovery scope, metadata quality, and environment segmentation now shape authorisation outcomes before any tool call is made.
The useful mental model is that runtime discovery shifts governance left in the execution path. Instead of reviewing every possible tool inside the agent, practitioners need to govern the approved set that the agent can enumerate in the first place.
For NHI and IAM teams, the practical consequence is that service endpoints, API-backed tools, and other non-human capabilities must be governed with the same discipline as credentials: visibility, scope, and offboarding all matter when discovery is dynamic.
For practitioners
- Define registry trust boundaries Separate discovery scope from execution scope so an agent can only see the MCP servers that are valid for its environment and role.
- Segment registries by environment Keep development, staging, and production registries distinct so experimental tools do not become discoverable in production workflows.
- Require metadata ownership fields Populate namespace, owner, environment, and access boundary metadata for every server so discovery decisions can be audited and explained.
- Treat discovered tools as governed capabilities Review which tools an agent can enumerate, then align registry visibility with the approval process that governs the underlying service.
- Test fail-closed behaviour for missing capabilities Verify that the agent stops cleanly when the registry has no approved match rather than falling back to an unapproved endpoint or static default.
Key takeaways
- MCP registry-driven discovery changes the governance problem by making runtime visibility the new control point for AI agents.
- The main risk is not just flexibility. It is that an overly broad registry can expose capabilities an agent should never see in a given environment.
- Teams should segment registries, enforce metadata discipline, and treat discoverable tools as approved capabilities rather than passive inventory.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Runtime tool discovery changes how agent identity and privileges must be governed. |
| ASI02 — Tool Misuse | The article centers on agents selecting and invoking tools dynamically through a registry. | |
| Recommendation — Constrain agent discovery and execution scopes so runtime-selected tools cannot exceed approved privilege boundaries. Review which tools an agent can discover and block any registry entries that would enable unsafe tool selection. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Registry-discovered servers are non-human capabilities that need governed ownership and trust boundaries. |
| Recommendation — Inventory discovered MCP servers and verify each one has an approved owner, scope, and lifecycle state. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and System Users) | Agents discovering remote tools interact with service endpoints that need service-to-service authentication controls. |
| Recommendation — Apply service authentication controls so only approved agents can discover and invoke registered endpoints. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The key governance issue is who may see and use registry-listed capabilities. |
| Recommendation — Limit registry visibility to the minimum entitlements needed for each agent, environment, and team. | ||
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.
- Tool discovery: The process by which an AI agent learns what functions or actions are available to it at runtime. It becomes a security issue when discovery is broader than entitlement, because the agent can map capabilities even when it should not be able to use them.
- Certificate Trust Boundary: The line where a verifier decides which certificates or keys are allowed to establish trust. When that boundary is ambiguous or implemented loosely, attackers can exploit role confusion to gain access that should have been rejected before signature verification completed.
- Agentic Tool Execution: Agentic tool execution is the pattern where an AI system does more than generate text and instead calls APIs, reads data, runs functions, or changes state. This creates security risk because legitimate operations can be manipulated into unintended actions, making intent harder to distinguish from normal behavior.
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.
Published by the NHIMG editorial team on June 23, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org