MCP tooling fragments identity governance across servers and agents

At a glance

What this is: This is a practical map of the MCP ecosystem, showing how servers, clients, registries, gateways, and orchestration layers fit together and where governance decisions surface.

Why it matters: It matters because IAM, PAM, and NHI teams now have to govern tool access, transport, and auditability across multiple MCP touchpoints instead of a single controlled application boundary.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read Obot's guide to MCP servers, clients, gateways, and orchestration

Context

MCP, or Model Context Protocol, is a set of conventions for letting LLMs call tools and data sources, not a single platform. That distinction matters because the identity boundary is now spread across server code, client applications, registries, gateways, and orchestration layers, which means governance has to follow the call path rather than the product label.

For identity teams, the real question is not whether MCP exists but which actor is being granted tool access and how that access is controlled over time. The article shows a market where local development, remote hosting, private registries, and control planes all coexist, so NHI governance, authentication, and auditability have to be designed for fragmentation from the outset.

This is especially relevant as organisations move MCP into production. The path from prototype to hosted service usually introduces OAuth, proxying, virtual tools, and delegated access, which turns a convenience layer into a governed identity surface.

Key questions

Q: How should security teams govern MCP tool access in enterprise environments?

A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

Q: Why do MCP registries and marketplaces create identity risk?

A: Registries improve discovery, but they do not validate trust. A server can be easy to find and still be unsafe to connect to if its code, credentials, or access model have not been reviewed. Security teams should use registries for intake and testing, then apply policy before any sensitive workflow is bound to the server.

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: How do teams decide whether to use self-hosted or remote MCP servers?

A: Choose based on the level of control you need over credentials, logging, and system reach. Self-hosted deployments give more direct governance, while remote servers usually require stronger authentication and proxy controls. The deciding factor is not convenience alone, but whether you can enforce the same policy standard end to end.

Technical breakdown

MCP servers, clients, and gateways create separate identity boundaries

An MCP server exposes tools and resources, while a client is the application that invokes them. A gateway or proxy sits in the middle to enforce policy, translate transport, and log activity. That separation is important because the identity that authenticates to the client is not always the identity that is allowed to invoke a tool, and the two can diverge further once OAuth, token exchange, or remote transport is introduced. In practice, the governance unit is the full request path, not the endpoint alone.

Practical implication: inventory MCP clients, servers, and gateways together so tool access can be authorised and audited as one chain.

OAuth and remote transport change the trust model for MCP

Local stdio-based MCP sessions often behave like developer tooling with implicit trust, but remote MCP introduces explicit authentication, transport security, and revocation requirements. Once a server is hosted remotely, the operator must manage who can connect, which tokens can be used, and how those tokens are scoped to tools or resources. That shifts MCP from a developer convenience into a governed access pattern, especially when tools can reach production systems or sensitive data.

Practical implication: treat remote MCP as an authenticated service integration and require scoped OAuth, revocation, and logging before production use.

Registries improve discovery but do not establish trust

Public and private registries solve a practical problem by making servers easier to find, test, and reuse. But discovery is not trust. A registry can tell you what exists, how it is tagged, and sometimes what transport it uses, but it cannot by itself validate code quality, credential handling, or whether a server should be allowed to touch sensitive data. For NHI governance, registries are an intake point, not a control point.

Practical implication: vet third-party MCP servers before binding them to any sensitive workflow or persistent credential.

Threat narrative

Attacker objective: The objective is to use trusted MCP tooling paths to reach systems and data that should never have been exposed to that server or agent.

1. Entry begins when a developer, analyst, or agent connects to an MCP server through a client, registry, or remote transport that has not been fully governed.
2. Escalation occurs when the server is allowed to invoke tools or resources beyond its intended scope, especially where OAuth scopes, proxy policy, or audit controls are weak.
3. Impact follows when the tool chain reaches production systems or sensitive data without adequate scoping, monitoring, or revocation.
4. Attacker objective is to turn tool integration into unauthorized data access, workflow abuse, or downstream system control.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP governance is an identity problem before it is an integration problem. The article’s tooling map makes that clear: once servers, clients, registries, and gateways are all part of the path, the control surface is no longer one product but a delegation chain. That means NHI governance has to follow invocation rights, token scope, and auditability across each hop. Practitioners should stop treating MCP as just a developer interface and start treating it as a multi-actor access fabric.

OWASP NHI Top 10 applies here because MCP expands the credential boundary. Servers, clients, and control planes all create places where secrets, tokens, and transport trust can leak into operational shortcuts. The post’s emphasis on OAuth, remote hosting, and proxying shows that production MCP should be governed like any other non-human identity surface. Practitioners should evaluate where tool invocation rights are created, not just where servers are deployed.

Registry convenience creates a false sense of trust. Public discovery layers make it easy to find MCP servers, but they do not prove code integrity, least privilege, or safe data handling. This is the same pattern seen in other reusable NHI ecosystems: the easier the distribution, the more important the intake controls become. Practitioners should assume every third-party server is untrusted until it passes review and policy enforcement.

Policy must sit above orchestration, not inside it. Agent frameworks such as LangChain, LangGraph, or n8n can compose MCP tools into workflows, but orchestration does not replace authorisation. If the framework can chain actions, then access policy has to constrain both the first call and the downstream tool sequence. Practitioners should align gateway policy, registry trust, and workflow governance before allowing MCP into production paths.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• 71% of IT teams have been advised on AI agent data access, while only 34% of executives have the same visibility, according to the same report.
• The governance gap widens as OWASP Agentic AI Top 10 becomes more relevant to production tool chains and delegated access paths.

What this signals

MCP adoption will force identity teams to govern delegation chains, not just credentials. The practical issue is not whether a server can speak MCP, but whether the organisations using it can prove who authorised the tool path, what data it can reach, and how access is revoked when the workflow changes. That is a classic NHI governance problem with agent-facing consequences.

Tool discovery is becoming a security decision point. As public registries and private catalogs grow, the intake process becomes the place where trust is either established or lost. Teams should expect MCP review to look more like third-party access governance than like ordinary developer tooling.

The control lesson is straightforward: if a gateway cannot enforce policy and log invocation at the boundary, the organisation has moved too much trust into the client and the agent layer. That is the point at which a convenience protocol becomes an enterprise access risk.

For practitioners

• Map the full MCP trust chain Document which clients, gateways, registries, and servers are in use, then assign ownership for each access boundary. Include transport type, auth method, and downstream systems reached by each tool.
• Require scoped OAuth before remote deployment Do not allow remote MCP servers into production until token scopes, revocation, and audit logging are defined for each tool and resource path.
• Treat registries as intake points Review third-party servers before they are trusted by agents or users, and block any server that cannot demonstrate safe credential handling and least privilege.
• Place a gateway in front of production tools Use a control plane or proxy to enforce access policy, log tool invocations, and centralise decision-making for MCP traffic that reaches sensitive environments.

Key takeaways

• MCP changes identity governance because it distributes tool access across clients, servers, registries, and gateways.
• Discovery does not equal trust, and remote MCP especially requires scoped authentication, policy enforcement, and auditability.
• Enterprises should treat MCP as a governed access fabric and place NHI controls around the full call chain, not just the server.

Key terms

• Model Context Protocol: A convention that lets LLM-based clients call tools and resources exposed by servers. In identity terms, MCP creates a delegated access path that must be governed like any other non-human integration, with scope, transport, and audit controls around each invocation.
• 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.
• 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.
• Tool Invocation: Tool invocation is an action where an AI agent calls an external system such as a database, API, or file service. Each invocation should be treated as an auditable identity action because it is the point where the agent can move data, trigger changes, or widen its reach across the environment.

What's in the full article

Obot's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step comparisons of FastMCP, Postman, Claude Code, and other MCP client and server patterns.
• Practical deployment notes for OAuth, remote transports, and hosted versus self-hosted MCP servers.
• Gateway and registry implementation details for audit logging, policy enforcement, and on-demand hosting.
• Framework-specific advice on when to use LangChain, Nanobot, or n8n for MCP orchestration.

👉 Obot's full article covers the tooling choices, deployment patterns, and governance layers in more detail.

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.