Notifications
Clear all
Topic starter
20/08/2026 5:35 pm
TL;DR: MCP adoption is forcing teams to decide between hosted, self-hosted, and local deployment models, with Obot arguing that the right choice depends on speed, control, and how much governance the environment requires. The core issue is not infrastructure preference but whether identity, data flow, and policy enforcement can be governed as MCP usage expands.
NHIMG editorial — based on content published by Obot: Model Context Protocol server hosting choices and tradeoffs
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Require explicit access scoping for tools Do not allow broad tool permissions by default.
- 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.
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.
👉 Read Obot's analysis of hosted, self-hosted, and local MCP server choices →
MCP server hosting: what is the governance gap teams are missing?
Explore further
20/08/2026 6:21 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP server hosting choices and the governance tradeoffs teams face
