MCP server hosting choices and the governance tradeoffs teams face

At a glance

What this is: This is an analysis of where to run Model Context Protocol servers and the governance tradeoffs across hosted, self-hosted, and local models.

Why it matters: It matters because MCP hosting decisions affect who controls credentials, data paths, auditability, and policy enforcement across NHI, AI agent, and human-driven workflows.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.

👉 Read Obot's analysis of hosted, self-hosted, and local MCP server choices

Context

Model Context Protocol servers are becoming part of the identity and access surface, not just an integration layer. Once MCP is used to connect tools, data sources, and AI workflows, the hosting decision becomes a question of control over credentials, auditability, and policy enforcement rather than pure developer convenience.

For NHI governance, the main issue is that MCP endpoints can concentrate access through service accounts, API keys, bearer tokens, and delegated client trust. The article frames the practical choice correctly: local, hosted, and self-hosted deployments each create different boundaries for identity control, operational ownership, and compliance. In a mature programme, the deployment model should follow the sensitivity of the systems being accessed, not the novelty of the protocol.

For teams introducing MCP into production, the governance gap is usually not the protocol itself but the lack of a clear registry, access scoping, and lifecycle control as more servers come online. That is typical for early adoption phases, which is why the architecture choice needs to be revisited as soon as MCP moves beyond experimentation.

Key questions

Q: What should security teams check before choosing a self-hosted MCP platform?

A: They should confirm that the runtime, registry, gateway, identity flow, and telemetry all stay inside the organisation’s boundary. They should also verify container isolation, enterprise identity integration, and supply-chain provenance. If any critical control-plane function remains vendor-hosted, the deployment is not truly self-hosted for regulated use.

Q: Why do MCP servers create new identity governance issues for NHI programmes?

A: Because they act as access surfaces for software identities, not just as application endpoints. Once an MCP server can invoke tools, read user context, or reach external systems, it needs the same scoping, ownership, and audit discipline used for other non-human identities. The control gap is usually entitlement drift, not authentication alone.

Q: What do security teams get wrong about discoverability for MCP deployments?

A: They often treat discoverability as a catalogue problem instead of an adoption problem. A registry only helps if it is easier to use than the shadow path. Security teams need frictionless onboarding, automatic configuration, and clear ownership so the sanctioned route becomes the default operating model.

Q: Who should own MCP access governance in an enterprise?

A: Ownership should sit with identity and security teams, not only application developers, because MCP connects user intent to privileged execution. The governing team needs authority over policy design, review cadence, and audit evidence. That keeps MCP aligned with enterprise authorization standards rather than ad hoc server behaviour.

Technical breakdown

Hosted MCP and delegated trust boundaries

Hosted MCP means a third party runs the server, manages uptime, and often handles parts of authentication and routing. The technical tradeoff is that credentials, request context, and data flow can pass through infrastructure outside the organisation’s direct control. That is acceptable for low-risk integrations, but it changes the trust boundary immediately. If the hosted service is a separate provider rather than the SaaS vendor itself, the organisation is no longer just consuming an integration, it is extending identity trust into another operational domain.

Practical implication: classify hosted MCP endpoints as third-party access paths and review them with the same scrutiny you apply to external service accounts and delegated integrations.

Self-hosted MCP, gateways, and policy enforcement

Self-hosted MCP keeps the server in your cloud or datacentre, which lets you control network placement, authentication, logging, and access policy. In practice, many teams place a gateway or reverse proxy in front of backend servers so policy can be enforced consistently across multiple MCP endpoints. That architecture makes sense when you need centralised identity control, audit trails, and tighter segmentation for sensitive systems. The technical cost is operational: you now own patching, availability, monitoring, and configuration correctness as part of the identity stack.

Practical implication: if MCP touches internal systems or regulated data, anchor it behind a governed gateway with unified authentication, audit logging, and explicit tool permission scoping.

Local MCP and developer-only identity scope

Local MCP runs on a developer workstation and avoids shared infrastructure entirely. That makes it ideal for experimentation, local filesystem access, and tool prototyping, but it also means identity scope is tied to one machine and one user context. The configuration that works on one workstation rarely translates cleanly to team-wide governance, especially when access must be consistent across multiple clients or environments. Local deployment is therefore a useful development pattern, not a durable organisational control model.

Practical implication: allow local MCP for experimentation, but do not treat it as a production identity boundary when shared access, auditability, or cross-team consistency are required.

NHI Mgmt Group analysis

MCP hosting is now an identity governance decision, not a deployment preference. Once model context servers mediate access to tools and data, the architecture determines who can authenticate, what can be delegated, and where policy is enforced. That means the hosting choice directly shapes NHI risk, auditability, and the blast radius of any compromised token or over-permissioned integration. Practitioners should treat MCP placement as part of the identity control plane, not a separate infrastructure discussion.

Hosted MCP introduces a delegated trust problem that many IAM programmes still under-model. If a third party sits between the client and the tool, credentials and context can cross an operational boundary the enterprise does not control end to end. That is workable when the integration is low risk and tightly scoped, but it becomes problematic when teams assume vendor authentication equals enterprise governance. The implication is simple: external hosting demands explicit trust classification, not informal approval.

Self-hosted MCP creates the right conditions for real governance, but only if the control plane is intentional. Running servers inside your own environment makes identity, logging, and network segmentation enforceable, yet those controls fail quickly when the deployment is treated as a convenience layer rather than a managed service. This is where policy enforcement, audit trails, and lifecycle ownership matter most. Practitioners should think in terms of governed endpoints, not just infrastructure they happen to own.

Local MCP should remain a developer pattern, not an organisational strategy. Local servers can be useful for prototyping and workstation-specific workflows, but they do not scale into repeatable governance because identity, access, and security posture vary from machine to machine. That creates inconsistent control outcomes and weakens any attempt at central review. The field needs to stop confusing useful experimentation with a production-ready access model.

MCP registries and access scoping are becoming the real scaling control for this category. As the number of servers grows, visibility matters more than raw deployment speed. A named concept here is the MCP governance gap: the space between easy connection and controlled access, where teams can adopt the protocol faster than they can inventory, scope, and review it. Practitioners should close that gap before MCP becomes a hidden access layer for AI-driven workflows.

From our research:

• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, which reinforces how quickly hidden access paths can accumulate.
• That governance gap is widening, so OWASP Agentic Applications Top 10 is a useful next lens for teams mapping tool access and identity risk.

What this signals

MCP governance gap: the industry is moving faster on protocol adoption than on identity controls, which means teams need to inventory servers before they can secure them. With 70% of organisations already granting AI systems more access than human employees, the pattern is clear: over-permissioning arrives before governance maturity.

MCP will increasingly sit inside the same governance conversation as secrets management, external collaboration, and delegated service access. Teams that already struggle with service account sprawl will see the same issue repeat in MCP form unless they force ownership, scope, and auditability into the deployment model.

The practical signal for practitioners is that protocol choice is now a control decision. If the organisation cannot explain where MCP credentials live, who can invoke tools, and how server trust is reviewed, the architecture is ahead of the governance programme.

For practitioners

• Map MCP endpoints to trust tiers Classify each server by where it runs, who operates it, what data it touches, and whether credentials cross organisational boundaries. Treat hosted third-party endpoints differently from first-party SaaS integrations and from self-hosted internal services.
• Require explicit access scoping for tools Do not allow broad tool permissions by default. Define which actions each MCP server can invoke, which accounts it can use, and which data sources it can reach, then review those scopes as part of access governance.
• Put self-hosted MCP behind a governed gateway Centralise authentication, logging, and policy enforcement at the gateway layer so backend servers are not individually exposed. This is especially important when multiple teams will consume the same internal tools or data.
• Keep local MCP out of production decision paths Permit workstation-based MCP for experiments and local workflows, but avoid using it as the approval path for shared business systems. Once access must be repeatable, auditable, and consistent, move it into a governed environment.
• Create an MCP registry before sprawl starts Maintain an inventory of every MCP server, its owner, its trust classification, and its connected tools. Without a registry, teams lose visibility into where identity and data access are actually being delegated.

Key takeaways

• MCP hosting choices are identity governance choices because they determine where trust, credentials, and policy enforcement actually sit.
• Hosted, self-hosted, and local MCP each create different control boundaries, and the right model depends on data sensitivity, audit needs, and operational maturity.
• The next scaling problem is not adoption speed but visibility, scoping, and lifecycle control across an expanding MCP server estate.

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.
• Tool Permission Scoping: The practice of limiting what a non-human identity can do with each tool, including which data sources it can reach and which actions it can trigger. Strong scoping is a core control for agent governance because it reduces overreach, improves auditability, and supports revocation.
• Delegated Trust Boundary: The line where an organisation relies on a third party or system to make decisions on its behalf. In agentic workflows, this boundary matters because a vendor-hosted agent may carry enough authority to expose data or trigger account actions without direct enterprise control.

What's in the full article

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

• A side-by-side walkthrough of hosted, self-hosted, and local MCP deployment patterns for different team stages.
• Practical examples of when first-party SaaS-hosted MCP is simpler than adding a separate third-party host.
• The article's own guidance on when an MCP gateway, proxy, or local runtime is the better architectural fit.
• The decision logic behind moving from experimentation to governed rollout as MCP usage expands.

👉 Obot's full post covers deployment tradeoffs, control boundaries, and the decision factors behind each MCP model.

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 building or maturing an identity security programme, it is worth exploring.