Centralized MCP hosting is now an identity governance problem

At a glance

What this is: This is an analysis of MCP server hosting models and the key finding that unmanaged developer adoption is creating shadow IT, fragmented credentials, and zero visibility.

Why it matters: It matters because IAM, PAM, and NHI teams need a control plane for tool access before AI-connected integrations outgrow manual governance and audit processes.

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 centralized MCP hosting and gateway control

Context

Model Context Protocol gives AI clients a standard way to connect to tools and data sources, but that convenience also creates a new identity governance surface. When developers can spin up MCP servers locally or route them through third-party services without central oversight, the organisation inherits NHI sprawl, unmanaged secrets, and unclear accountability.

The core governance gap is not the protocol itself. It is the lack of centralised lifecycle control over the credentials, policies, and audit trails that sit behind MCP endpoints. For IAM and NHI teams, MCP hosting decisions now determine whether tool access is governed like any other non-human identity estate or left as shadow IT.

This problem is already operational in many environments, and the article’s starting position is typical rather than exceptional: unmanaged MCP use appears first, and governance catches up later if it catches up at all.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

Q: Why do MCP servers create new identity governance requirements?

A: MCP servers expose non-human access to tools and data through agent-driven workflows, so basic login is not enough. Governance has to cover who can register, what resources a token can reach, which tools the identity may invoke, and how access is revoked. That is why MCP behaves like NHI governance, not just application authentication.

Q: What breaks when MCP usage is left unmanaged?

A: Visibility breaks first, then accountability, then revocation. Teams lose track of which servers exist, which tools they can reach, and whether credentials still belong to active users. Once that happens, MCP becomes a parallel access layer that bypasses normal lifecycle controls and leaves compliance teams without evidence.

Q: Should organisations self-host or proxy MCP servers?

A: Use self-hosting for sensitive, regulated, or latency-critical integrations where you need control over data and credentials. Use proxying for lower-risk SaaS connections and early experimentation. Most enterprises will need a hybrid model, but only if a gateway preserves one policy and logging standard across both paths.

Technical breakdown

Why MCP hosting changes the identity control surface

MCP hosting turns AI-to-tool access into a persistent integration layer rather than a one-off connection. Each server typically fronts databases, APIs, file systems, or SaaS systems, which means the server’s credential set becomes part of the trust boundary. If those credentials sit in config files, environment variables, or developer laptops, identity governance shifts from central policy to local practice. That is why MCP is best treated as an NHI problem first and an infrastructure problem second.

Practical implication: inventory every MCP endpoint as an identity-bearing integration, not just a technical service.

Self-hosted, remote, and hybrid MCP hosting models

Self-hosted MCP keeps the server and its credentials inside the organisation’s infrastructure, which improves control, latency, and data residency. Remote hosting pushes the endpoint to a third party, while the gateway brokers authentication and logs traffic. Hybrid architecture combines both, usually because different integrations have different sensitivity levels. The key technical point is that hosting model determines where policy enforcement, token exchange, and audit logging actually occur, not just where the code runs.

Practical implication: classify integrations by sensitivity and decide where credential control must live before choosing hosting mode.

Why a gateway becomes the control plane for MCP

A gateway centralises authentication, authorisation, policy enforcement, and logging across all MCP connections. That matters because MCP servers can otherwise proliferate across local setups with no shared inventory or revocation mechanism. A central gateway also makes it possible to proxy third-party servers without exposing raw credentials to end users. In identity terms, the gateway is doing the work that ad hoc local deployments never do: translating tool access into governable access decisions.

Practical implication: place policy, logging, and revocation at the gateway layer if you want repeatable governance.

Threat narrative

Attacker objective: The objective is to gain or preserve access to connected systems through unmanaged MCP credentials and tool pathways without triggering central oversight.

1. Entry occurs when developers connect AI clients to MCP servers on laptops or through unsanctioned hosted endpoints, creating unmanaged access paths into internal systems and external services.
2. Credential access and abuse follow when API keys, OAuth tokens, and service account secrets are stored in config files, environment variables, or hardcoded scripts with no central revocation process.
3. Impact is visible in shadow IT, no audit trail, and lingering access after employee departure, which leaves tool-mediated data and systems exposed outside governance.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Centralised MCP management is now a non-human identity governance requirement. Once developers begin using MCP servers at scale, every endpoint becomes a governed access path into internal or third-party systems. The governance question is no longer whether AI clients can reach tools, but whether those tool connections are provisioned, scoped, logged, and revoked like any other NHI. Organisations that treat MCP as an experiment rather than an identity layer will miss the control point that matters most.

Shadow MCP use creates trust debt that IAM teams cannot clear after the fact. The article describes developers operating MCP servers on laptops with scattered credentials and no audit trails. That pattern creates a backlog of unreviewed access decisions, and the longer it runs, the harder it becomes to reconstruct who connected what to which system. Practitioners should read this as a lifecycle failure, not a configuration nuisance.

MCP hosting decisions are really decisions about where identity authority lives. Self-hosted, remote, and hybrid models each place different weight on local infrastructure, gateway policy, and third-party trust. The named concept here is the identity control plane split: when authentication, authorisation, and logging are distributed across too many layers, no single team can prove effective governance. The practical conclusion is that hosting architecture must follow accountability boundaries, not developer convenience.

Credential sprawl is the MCP equivalent of unmanaged service-account drift. API keys, OAuth tokens, and service accounts multiply as teams add integrations, but revocation and audit discipline rarely keep pace. That is the same failure mode seen in broader NHI programmes, except MCP accelerates it by attaching tool access directly to AI workflows. Identity leaders should expect this to show up first as exceptions, then as scale.

Hybrid MCP environments will become the norm, so governance has to be portable. Most organisations will not move every integration to a single hosting model. That means policy, logging, and access review processes must work across self-hosted and proxied endpoints without creating two separate control standards. The field should expect NHI governance programmes to converge on gateway-centric oversight, because that is where tool identity becomes measurable and enforceable.

From our research:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to OWASP Agentic AI Top 10.
• A second signal comes from the same research set: 53% of MCP servers expose credentials through hard-coded values in configuration files.
• For the governance response, see NHI Lifecycle Management Guide for lifecycle patterns that apply directly to MCP credentials and endpoints.

What this signals

Identity control plane split: MCP is pushing organisations toward a split between where tools run and where identity authority is enforced. If developers can create endpoints faster than IAM can inventory them, the programme will keep discovering access after the fact rather than governing it at creation time. For readers building IAM or NHI roadmaps, the next step is to make gateway-centric control the default for any AI-to-tool integration, supported by NIST Cybersecurity Framework 2.0.

The operational signal is that centralised review must move upstream. As MCP usage scales, access review cannot be limited to human accounts and classical SaaS provisioning; it has to include tool endpoints, service accounts, and proxy policies that define who or what can call them. That is where Top 10 NHI Issues becomes useful as a prioritisation lens.

The broader market signal is that MCP governance is converging with NHI lifecycle management, not sitting beside it. Teams that already manage secrets, workload identity, and offboarding should expect MCP to land in the same programme backlog because the underlying problem is the same: credentials outlive oversight. The control philosophy is consistent with NIST SP 800-53 Rev 5 Security and Privacy Controls around access control, audit, and authenticator management.

For practitioners

• Inventory every MCP endpoint as an identity-bearing asset Build a register of MCP hosts, clients, credentials, and upstream systems. Include developer-managed servers on laptops, sanctioned internal deployments, and any third-party hosted endpoints that proxy access into your environment.
• Centralise authentication and token exchange at a gateway Route MCP access through a single control point so raw credentials never reach end users. Use the gateway to enforce OAuth flows, revoke access quickly, and maintain one audit trail for all tool calls.
• Classify integrations by data sensitivity before choosing hosting Keep regulated or high-impact systems under self-hosted control where data residency, segmentation, and latency matter. Use remote hosting only where the business value outweighs the governance and dependency trade-offs.
• Remove developer-owned secrets from MCP configurations Prohibit API keys, OAuth tokens, and service account credentials from config files, environment variables, and scripts. Move those secrets into managed storage with lifecycle ownership and revocation authority.
• Align access review with the MCP lifecycle Review which MCP connections still exist, which ones are business critical, and which ones should be revoked or migrated. Treat stale tool access as an NHI offboarding issue, not a minor housekeeping task.

Key takeaways

• MCP adoption is turning developer-managed tool access into an NHI governance problem because credentials, auditability, and revocation are already lagging usage.
• The strongest practical signal is not where the server runs, but where policy, logging, and token control are enforced across self-hosted and remote endpoints.
• Enterprises should treat MCP like any other identity-bearing integration and move toward gateway-based control before shadow IT becomes permanent access debt.

Key terms

• Model Context Protocol: A standard way for AI clients to connect to external tools and data sources through a server endpoint. In practice, it creates a governed access path that can carry credentials, policy checks, and audit logging, which makes it an identity problem as much as an integration protocol.
• 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.
• Identity Control Plane: An identity control plane is the governance layer that decides who or what can access systems and under what conditions. In practice, it coordinates authentication, authorization, privilege review, and lifecycle management across human and machine identities so access policy is enforced consistently across environments.

What's in the full article

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

• Step-by-step deployment guidance for self-hosted MCP servers in Docker and Kubernetes
• Specific trade-offs between self-hosted, remote, and serverless hosting models
• Operational examples of gateway-based proxying, audit logging, and token handling
• Practical guidance on when to migrate from remote hosting to self-hosting as usage matures

👉 Obot's full article covers hosting models, gateway mechanics, and deployment choices in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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.