MCP tooling fragments identity governance across servers and agents

At a glance

What this is: This is a field guide to the MCP tooling landscape, showing that identity and governance concerns emerge across servers, clients, registries, gateways, and agent frameworks rather than in one product layer.

Why it matters: IAM, NHI, and platform teams need to treat MCP as a distributed control problem because trust, authorization, and auditability shift depending on where tool invocation is happening.

Context

MCP is not a single platform. It is a protocol ecosystem that lets language models and agents call real tools, which means the identity problem shows up across multiple components instead of one central control point.

That matters for governance because each layer changes the trust boundary: servers expose tools, clients initiate calls, registries shape discovery, gateways enforce policy, and agent frameworks can chain actions together. The practical question is not whether MCP exists, but where control, accountability, and authentication sit in the path.

Key questions

Q: What breaks when MCP servers are connected without a trusted control plane?

A: Discovery and execution become the same decision, which removes the ability to review who published a tool, who can call it, and what trail exists after use. That creates a governance gap between the registry and the real runtime path. Enterprises usually discover the problem only after tool sprawl makes audit and revocation inconsistent.

Q: Why do remote MCP servers create more identity governance risk than local ones?

A: Remote MCP servers expand the potential client population from a small local set to any client that can reach the network endpoint. That wider exposure increases the chance of malicious registration, impersonation, and scale abuse. The governance burden shifts from simple reachability control to continuous verification and lifecycle management.

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: Should organisations use gateways or registries to control MCP access?

A: Gateways should control access because they can enforce policy, proxy calls, and preserve audit evidence. Registries are still useful, but only for discovery and curation. The practical distinction is simple: if a component cannot stop a call, it should not be treated as the security boundary for MCP usage.

Technical breakdown

MCP servers and transport choices

An MCP server exposes tools and resources to clients over a transport such as stdio, Streamable HTTP, or SSE. The transport matters because it determines whether the server is local and transient or remotely reachable and policy-bound. Code-first SDKs such as FastMCP speed up schema generation and tool exposure, while request-oriented tooling supports testing and collaboration. In practice, the protocol surface is not just an API shape. It is the point where authentication, scope, and logging have to be decided before a tool becomes consumable by a model or agent.

Practical implication: decide transport and auth together, because local convenience and remote governance have different identity controls.

Clients, agents, and who can invoke tools

MCP clients are the front line where users, IDEs, chat applications, and agents initiate tool calls. Some clients assume local, unauthenticated servers; others support OAuth or token-based remote access. That difference matters because the client does not merely display tools, it becomes part of the authorization path. Once clients can call across remote servers, the question shifts from interface compatibility to trust boundaries, identity proof, and whether the calling context is attributable enough for audit and revocation.

Practical implication: inventory which clients support authenticated remote MCP and retire anything that cannot prove caller identity.

Gateways, registries, and policy enforcement points

Registries solve discovery, but gateways solve governance. A registry tells users what exists, while a gateway can proxy traffic, enforce access control, apply rate limits, and preserve auditability. That distinction is critical in enterprises because third-party servers and community catalogs are effectively untrusted until reviewed. Gateways also let teams virtualize legacy REST APIs as MCP tools, which expands exposure unless tool publishing and policy enforcement are separated. The architectural lesson is that discovery, execution, and approval must not be collapsed into the same layer.

Practical implication: put policy at the gateway, not in the registry, and treat discovery as a separate trust decision.

Threat narrative

Attacker objective: The objective is to gain tool invocation through a trusted-looking MCP path and use that access to reach systems, data, or workflows that were not meant to be exposed directly.

1. Entry begins when users or agents connect to MCP servers through clients that may support remote access, local unauthenticated use, or OAuth-based trust paths.
2. Credential and privilege exposure occurs when third-party servers, catalogs, or gateways are adopted without a clear review of the access model and audit boundary.
3. Impact follows when tool access is treated as interchangeable across environments, allowing agents to invoke sensitive actions without consistent governance or traceability.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Anthropic GTG-1002 AI espionage campaign: A state-sponsored group ran Claude Code agents to attack about 30 organisations, harvesting and reusing credentials at machine speed.

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 governance is now a distributed identity problem, not a server-selection problem. The article makes clear that servers, clients, registries, gateways, and agent frameworks each create a different control point. That means identity policy cannot live in one team’s tooling decision and still claim coverage. The practical conclusion is that MCP adoption should be governed as a chain of trust, not a catalog of products.

Discovery and trust are being incorrectly conflated in many MCP deployments. Registries help teams find servers, but they do not establish whether a server is safe to bind to a real data path. Gateways, private catalogs, and review processes exist because discovery alone is not governance. Practitioners should treat public MCP availability as a signal for assessment, not as a reason to connect.

Tool invocation is the new authorization boundary for MCP ecosystems. Once a client or agent can call tools across remote servers, the security question is no longer just access to a host. It is who can trigger which tool, from which context, under what policy, and with what audit evidence. That pushes MCP squarely into NHI governance, because tool identity and caller identity now both matter.

Private control planes are becoming the enterprise pattern for a reason. The article shows why organizations move toward gateways and managed registries when they need role-based publishing, proxying, and auditability. That is not an implementation preference, it is a governance response to a fragmented ecosystem. The implication is that enterprise MCP should be designed around controllable publication and traceable consumption from the start.

MCP tool sprawl creates an identity blast radius unless access paths are constrained. As agents, clients, and hosted servers multiply, the number of ways to invoke a tool expands faster than human review cycles can keep up. This is where NHI governance and agentic workflow control meet. Practitioners need to assume that every new MCP connector broadens the blast radius until proven otherwise.

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

MCP security is moving from protocol design to operating model. The organisations that will handle it best will separate discovery, runtime authorization, and audit into different layers instead of assuming one control point can do all three. That shift matters because the fastest way to create unmanaged exposure is to let every new connector become its own policy exception.

Identity teams should expect MCP to behave like a new class of workload governance, not a niche developer integration. As soon as clients, gateways, and agent frameworks all participate in tool invocation, the question becomes which actor is allowed to act, not just which tool exists. The programme implication is that MCP belongs in NHI governance, access policy, and runtime monitoring discussions at the same time.

Tool sprawl becomes an identity blast radius when publication and consumption are not separated. Every additional server, registry entry, or gateway route expands the number of paths that can invoke real systems, so control design has to focus on issuance and enforcement rather than catalog size.

For practitioners

• Define the MCP trust boundary before deployment Map which layer owns discovery, which layer enforces policy, and which layer records audit evidence for every tool call.
• Require authenticated remote access for any non-local server Do not allow clients to bind to remote MCP services unless OAuth or an equivalent identity mechanism is in place and reviewable.
• Separate registries from enforcement points Use registries for discovery only and place authorization, rate limits, and logging in the gateway or control plane.
• Vet third-party servers before tool binding Treat community directories and public catalogs as untrusted until code, transport, and access model have been reviewed.
• Standardise client support for secure transports Prefer clients that can handle Streamable HTTP or other remote transports with identity-aware controls, and retire ones that cannot.

Key takeaways

• MCP creates a distributed governance problem because tool access is now split across servers, clients, registries, gateways, and agent frameworks.
• The central risk is not the protocol itself but the loss of clear authority over who can invoke tools, under what policy, and with what evidence.
• Enterprises need separate discovery from enforcement and treat gateways as the real control point for audit, policy, and revocation.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• 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.
• 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 Invocation Boundary: The control point where a system decides whether an agent can take a real-world action through a connected tool. It is a key enforcement layer for least privilege because it separates reasoning from execution and should block unsafe or unauthorised actions.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.