TL;DR: MCP server registries can improve discovery and approval, but they do not enforce policy on their own, according to NeuralTrust. GitHub's registry-only mode still relies on client-side matching that can be bypassed by editing configuration, so enterprises need a gateway and runtime enforcement, not a catalogue alone.
At a glance
What this is: This analysis argues that an MCP server registry is only an approval catalogue unless it is paired with runtime enforcement that agents cannot edit around.
Why it matters: For IAM, NHI, and agentic AI teams, the practical question is whether discovery, approval, and enforcement sit in separate controls or collapse into a client-side setting that users or agents can bypass.
Context
MCP server registries sit in the governance layer, not the runtime layer. They tell you which servers are approved for discovery, but they do not by themselves stop an agent from reaching beyond that list if the enforcement point lives on an editable client.
That gap matters because registry design and tool execution solve different problems. Discovery answers what is visible and approved, while enforcement answers what can actually run, which is why a registry without a separate control point is only a record of intent.
In practice, this is the difference between policy and control for MCP security. If the agent can edit the configuration that defines its own toolset, the approval model becomes advisory instead of enforced.
Key questions
Q: What breaks when MCP servers are added without a gateway?
A: Authentication, authorization, and audit responsibilities fragment across servers, which makes policy inconsistent and revocation slow. The hidden failure is that each new server expands the trust boundary and the blast radius. Without a gateway, teams usually discover the problem only after a server has already been wired to credentials and internal tools.
Q: Why do client-side allowlists fail for MCP servers?
A: Client-side allowlists fail because they trust the device that is also running the agent. If the server list, registry URL, or matching logic is editable locally, the control can be changed without central approval. A secure model keeps the decision in a managed gateway or policy plane outside the agent's write path.
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.
Q: What should security teams do when agents can change tool configuration?
A: Assume the approval model has already failed and move policy out of the mutable client context. Then restrict write access, log every configuration change, and verify that unapproved servers are blocked even if a local file is altered. The control must survive endpoint tampering, not just normal operation.
Technical breakdown
How MCP registries differ from runtime enforcement
An MCP registry is a catalogue of approved servers. It can store names, IDs, owners, and review status, but it does not itself block tool invocation. A gateway, by contrast, sits on the execution path and decides whether a call is permitted at runtime. That architectural split matters because discovery is a governance function and enforcement is a control function. When policy lives only in a registry, the trusted list can still be bypassed if the client can alter what it reads or sends. The control boundary must therefore sit away from the editable agent environment.
Practical implication: Put the allow decision behind a control point the agent cannot modify locally.
Why client-side registry checks are not enough
Client-side enforcement depends on the integrity of the local configuration file and the matching logic used to compare servers against the registry. If the agent or user can edit that file, the policy can be changed without changing the central approval record. That is a classic trust-boundary failure: the control assumes the endpoint is honest, but the endpoint is where the policy is stored. For NHI governance, that means the registry must be treated as source data, not as the enforcement mechanism. The higher the privilege of the client, the more fragile the registry-only model becomes. See the NHI Authentication Guide.
Practical implication: Move trust decisions off the workstation and into a managed enforcement layer.
How MCP configuration becomes an attack surface
When an agent can write to its own MCP configuration, the registry is no longer a guardrail. The configuration file becomes a control plane artifact that determines which servers are reachable and which tools can be called. That turns a routine settings file into a high-value target for prompt injection, local privilege abuse, or configuration tampering. In governance terms, the issue is not just secret exposure but mutable policy. Once tool selection is editable at the edge, the distinction between approved and unapproved servers can collapse during execution, not after review.
Practical implication: Protect MCP configuration as privileged policy data and keep agents out of its write path.
Threat narrative
Attacker objective: The attacker wants to steer agent tool use through unapproved infrastructure so they can execute commands, exfiltrate data, or persist control through the MCP path.
- Entry occurs when an attacker reaches the agent or IDE context and can influence how the tool environment is configured.
- Credential or policy abuse follows when the attacker tampers with the MCP configuration or a bearer token that the client trusts.
- Impact occurs when the agent routes requests through an unapproved server or executes commands that the registry was supposed to block.
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.
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-only governance is not enforcement. A private MCP registry helps with approval records, ownership, and discovery, but it does not itself stop tool execution. The moment enforcement depends on editable client settings, the registry becomes advisory rather than authoritative. Practitioners should treat the registry as a control input and the gateway as the control decision point.
Editable MCP policy collapses the trust model. The assumption that an approved server list is stable enough to be enforced on the endpoint breaks as soon as the endpoint can rewrite its own tool configuration. That is a governance failure, not merely a product limitation. The implication is that approval state must live outside the agent's writable context, or the catalogue cannot be trusted as policy.
Tool governance for agents now needs separation of approval, execution, and logging. Discovery, permissioning, and runtime inspection are not interchangeable functions. When they are merged into one local setting, the organisation loses auditability and loses containment. That is why agent identity buying decisions should be anchored in runtime enforcement rather than catalogue management alone.
Registry sprawl is a governance smell, not just an operational inconvenience. The more teams that can publish or edit servers without a central approval path, the more likely policy drift becomes. The result is a soft control surface where naming conventions stand in for access decisions. Practitioners should recognise that tool registries need lifecycle governance just like any other privileged identity asset.
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
Approval state needs to become a runtime property. Teams should stop treating MCP registries as static inventories and start treating them as inputs to an enforcement pipeline. Once agents can add tools, the decisive question is whether policy survives after the client is modified, not whether the registry was reviewed.
Registry governance will converge with privileged configuration control. The same programme that governs NHI secrets and service account scope now has to govern which tools an agent is allowed to discover, call, and persist. That pushes MCP policy into the same operational discipline as other high-risk identity assets.
If the organisation cannot prevent local edits to tool configuration, it cannot claim that registry-only controls are sufficient. The next phase of governance is to separate discovery from decision, then monitor both for drift.
For practitioners
- Separate approval from enforcement Keep the MCP registry as the source of approved servers, but enforce allow and deny decisions in a gateway or runtime policy layer that the agent cannot edit.
- Block agent writes to MCP configuration Protect registry URLs, server lists, and tool policy files as privileged configuration so developers and agents cannot change them from the workstation.
- Review every server on a fixed lifecycle Revalidate ownership, scope, and version on each release or exception, then remove stale entries from both the registry and the enforcement policy.
- Test for bypass paths before rollout Have red teams attempt registry bypass through edited configuration files, local tool definitions, and any path that can still reach unapproved servers.
Key takeaways
- MCP registries are useful for approval and discovery, but they do not provide enforcement unless a separate runtime control blocks unapproved servers.
- The core failure mode is editable client policy, which turns the registry into a record of intent rather than a dependable access control.
- Practitioners should govern MCP servers like privileged identity assets, with ownership, version review, and enforcement outside the agent's write path.
Related NHI Mgmt Group resources: MCP Security Guide · NHI Authentication Guide · AI Agent Identity Security Buyer's Guide · Smithery.ai MCP hosting breach 2025
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article shows how editable MCP policy and static tokens let unapproved servers be reached despite apparent approval. |
| NHI-05 — Overprivileged NHI | The source warns that agents and servers can run with broader access than the registry was meant to permit. | |
| NHI-01 — Improper Offboarding | The article stresses removing stale servers and revoking unneeded access when approval or scope changes. | |
| Recommendation — Move MCP authentication and server trust decisions out of editable client settings and into centrally enforced policy. Constrain MCP server scope and tool permissions to the minimum access needed for each approved use case. Remove retired MCP servers from both approval records and runtime policy as soon as their use ends. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article describes how token theft and unapproved tool use can move from initial access into broader execution paths. |
| Recommendation — Map MCP abuse to credential access and lateral movement to detect when tool trust turns into expanded access. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about whether approved MCP tools are actually authorised at runtime. |
| Recommendation — Apply PR.AA-05 to separate approved discovery lists from runtime authorisation decisions. | ||
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.
- Client-side enforcement: Security logic that runs in the browser or other user-facing environment to control access, collect signals, or enforce challenge behaviour. It is convenient but exposed, so attackers can inspect, test, and adapt against it unless the design shifts critical trust elsewhere.
- Tool Governance: Tool governance is the control of the APIs, service accounts, connectors, and permissions an agent uses to reach other systems. It focuses on the delegated paths that convert agent intent into action, because those paths often hold the real security risk and the broadest privilege exposure.
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 October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org