MCP server hosting choices and the governance tradeoffs teams face

At a glance

What this is: This is a governance analysis of hosted, self-hosted, and local MCP server models, with the key finding that hosting choice changes identity control, data flow, and operational accountability.

Why it matters: IAM, IGA, PAM, and NHI teams need to treat MCP placement as an access and governance design decision because the model changes where credentials travel, who can enforce policy, and how quickly controls can be standardised.

Context

Model Context Protocol server hosting is an identity and governance problem as much as an infrastructure choice. Once MCP usage expands beyond experiments, teams have to decide where authentication, policy enforcement, logging, and access boundaries should live.

The article frames three deployment patterns, hosted, self-hosted, and local, and argues that the right choice depends on the stage of adoption, the sensitivity of the systems involved, and the level of control the organisation needs. That makes MCP hosting a programme design question, not a simple preference for convenience.

For identity teams, the deeper issue is whether MCP access is being created ad hoc or governed as the number of servers grows. The governance gap appears when teams treat each server as a point decision instead of a controllable part of a broader access architecture.

Key questions

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.

Q: Why does hosted MCP create more governance risk for sensitive systems?

A: Because the organisation gives up direct control over part of the request path. If credentials, tokens, or data flow through a third party, the security team has to trust external handling of authentication, logging, and uptime instead of enforcing those controls internally.

Q: What breaks when teams try to use local MCP as an organisational standard?

A: Consistency breaks first, then visibility. Local deployments vary by machine, so access rules, security posture, and configuration drift across users become hard to govern. That makes local MCP suitable for experimentation, but weak for shared, approved, or regulated access.

Q: When should organisations move from ad hoc MCP connections to a governed registry?

A: When multiple teams start depending on the same servers or when approval, logging, and access control need to be standardised. A registry becomes the practical next step once the environment is too large for one-off integrations and informal ownership.

Technical breakdown

Hosted MCP and the trust boundary problem

Hosted MCP means a third party runs the server and handles the underlying infrastructure, scaling, and often part of the authentication setup. That reduces operational load, but it also moves sensitive control points outside the organisation’s direct boundary. Credentials, bearer tokens, and request data may pass through infrastructure the customer does not administer. The technical distinction is not simply who owns the server. It is who can observe, enforce, log, and revoke access across the request path. For identity governance, that changes where assurance has to be established and how much of the access lifecycle can be controlled internally.

Practical implication: classify hosted MCP endpoints as third-party access paths and decide whether your governance model tolerates external handling of tokens and data flow.

Self-hosted MCP and centralised policy enforcement

Self-hosted MCP places the server inside your own cloud or datacenter, usually behind a proxy or zero-trust boundary. That gives teams more control over network exposure, identity provider integration, logging, and audit trails. It also allows the MCP layer to act as a central gateway rather than a collection of direct integrations. Technically, this matters because policy can be applied once at the gateway instead of being repeated across clients and downstream tools. The tradeoff is that the organisation now owns patching, monitoring, scaling, and correct configuration of the supporting controls.

Practical implication: use self-hosting when you need a controlled enforcement point for authentication, authorization, and auditability across multiple MCP servers.

Local MCP and why it does not scale as an organisational model

Local MCP runs on a developer’s machine and avoids shared infrastructure altogether. That is useful for experimentation and for cases where the tool must reach local files or workstation-specific resources. The technical limit is consistency: the configuration, access model, and security posture vary from one machine to another, so there is no stable central governance layer. Local deployment can support individual workflows, but it does not provide a repeatable organisational control plane. Once access has to be shared, reviewed, or standardised, the local model stops being sufficient on its own.

Practical implication: keep local MCP for prototyping and workstation-bound use cases, but do not treat it as the default model for shared or regulated access.

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

MCP hosting has become an access governance decision, not just an infrastructure decision. Once multiple servers are in play, the question shifts to where authentication, logging, and policy enforcement are easiest to govern. That is why the deployment model affects identity architecture as much as it affects operations. Teams should evaluate MCP placement as part of the broader access control design, not as a standalone hosting preference.

Hosted MCP creates a governance gap whenever credentials and data leave the organisation’s direct control. The trust boundary widens when a third party manages the runtime and related access flows, even if the integration is officially supported. That does not make hosted MCP invalid, but it does mean the organisation has less direct control over auditability and enforcement. Practitioners should treat that as a deliberate governance tradeoff, not an implementation detail.

Self-hosted MCP is where central policy becomes technically enforceable across a growing server estate. Central gateways, consistent authentication, immutable logging, and stricter network boundaries all become easier when the server runs inside the organisation’s own environment. The challenge is operational discipline, because control without reliable configuration and monitoring quickly turns into false assurance. The practical conclusion is that self-hosting makes sense when governance requirements are now stronger than speed.

Local MCP is an acceptable development pattern, but it is structurally weak as an enterprise standard. It works when the use case is personal, temporary, or tied to local resources. It fails as soon as the organisation needs shared visibility, repeatable access controls, or comparable security across teams. The named concept here is the MCP governance gap: the gap between convenient local experimentation and enforceable organisation-wide control.

The real maturity signal is whether teams can move from ad hoc connections to an MCP registry and controlled rollout model. That shift shows the organisation is treating MCP as a governed integration layer rather than a collection of isolated shortcuts. For identity leaders, the next question is how to standardise visibility, approval workflows, and access boundaries as adoption expands. The practitioner conclusion is to design for governability before scale makes the gaps expensive.

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

The hosting decision becomes a governance control once MCP moves beyond experimentation. Hosted models are easier to start, but they widen the trust boundary; self-hosted models tighten that boundary, but only if the organisation can operationalise policy, logging, and patching consistently.

MCP governance gap: many teams will outgrow ad hoc server choices before they outgrow MCP itself. The next maturity step is not simply more infrastructure, but a registry, consistent approval paths, and clearer ownership of where identity and data controls live.

For identity programmes, the practical signal is whether MCP access can be reviewed and enforced in the same way across teams. If the answer depends on which machine, vendor, or deployment model is in use, governance is already fragmented.

For practitioners

• Define the MCP trust boundary first Map where tokens, bearer credentials, and data requests travel in each hosting model before standardising any rollout decision.
• Classify MCP use cases by control need Separate prototyping, local-resource access, and sensitive internal integrations so each use case lands in the least complex model that still meets governance requirements.
• Centralise policy for shared MCP estates Use a gateway or proxy layer when multiple servers need the same authentication, logging, and authorization rules across teams.
• Keep local MCP out of the enterprise default Allow local servers for experimentation and workstation-bound tasks, but require a governable deployment path for shared or regulated access.
• Revisit hosting as adoption matures Move from ad hoc choices to a registry-based model when server count, sensitivity, or approval workflows make point decisions unmanageable.

Key takeaways

• MCP hosting is an access governance choice because it changes where authentication, data flow, and enforcement sit.
• Hosted, self-hosted, and local MCP each optimise a different constraint, but only one of them gives the organisation direct control over the full trust boundary.
• As adoption grows, teams need registry-based governance and consistent policy enforcement instead of isolated deployment decisions.

Key terms

• Hosted MCP: Hosted MCP is a deployment model where a Model Context Protocol server runs in a managed or remote environment rather than on the local machine. It exposes tools, data, or actions to AI agents through MCP interfaces, while the host controls availability, authentication, logging, and operational boundaries.
• Self-hosted MCP platform: A self-hosted MCP platform runs the runtime, registry, gateway, and identity functions inside the customer’s own infrastructure. In practice, that means the organisation controls data residency, policy enforcement, and audit boundaries instead of relying on vendor-hosted management planes.
• Local MCP: Local MCP is a Model Context Protocol deployment that runs on a device or within a local environment instead of a remote service. It lets an AI agent connect to tools, files, or data sources through a standardized interface, while keeping control, trust boundaries, and data handling closer to the host system.
• MCP governance: MCP governance is the set of policies, controls, and oversight used to manage how AI agents use the Model Context Protocol to reach tools and data. It defines approved connections, authentication, authorization, logging, data handling, and change control so agent actions remain traceable, bounded, and aligned with security and compliance requirements.

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.