TL;DR: Self-hosted MCP platforms shift tool invocations, credentials, and agent context back into customer infrastructure, but they also expose a sharper identity question: whether authentication, isolation, observability, and access control can operate without vendor-hosted dependencies, according to Stacklok. For IAM and NHI teams, the real issue is governance completeness, not deployment convenience.
NHIMG editorial — based on content published by Stacklok: Best MCP Platforms for Secure, Self-Hosted Deployments 2026
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes , and as quickly as 9 minutes in some cases.
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 self-hosted MCP platforms matter for identity governance?
A: Because MCP now governs tool access, agent context, and credential use in the same way other identity platforms govern application access.
Q: Where do MCP platforms usually fail in practice?
A: They fail when they expose shared runtime surfaces, weakly scoped tool permissions, or vendor dependencies in the critical path.
Practitioner guidance
- Verify the full trust boundary Map every MCP runtime dependency, including auth endpoints, telemetry sinks, and registry lookups, to confirm they remain inside your infrastructure boundary.
- Require per-server isolation Insist that each MCP server runs in its own container or equivalent isolated execution unit with minimal filesystem and network permissions.
- Align MCP with existing identity controls Tie MCP access to enterprise OIDC or OAuth, and reject designs that rely on stored developer credentials or vendor-hosted authorization flows.
What's in the full article
Stacklok's full comparison covers the operational detail this post intentionally leaves for the source:
- A deeper breakdown of how ToolHive components map to Kubernetes Operators, CRDs, and namespace-scoped deployments.
- Configuration-level detail on embedded authorization, per-server permissions, and policy enforcement in the private-cloud runtime.
- Platform-by-platform procurement notes on Docker MCP Gateway, IBM ContextForge, Obot, and MintMCP for teams at implementation stage.
- Operational guidance on when a self-hosted option is sufficient versus when a fully private deployment is required.
👉 Read Stacklok's comparison of self-hosted MCP platforms for secure deployment →
Self-hosted MCP platforms: what governance trade-offs matter most?
Explore further
Self-hosted MCP is an identity boundary decision, not a hosting preference. If tool invocations, credentials, and agent context leave the enterprise boundary, the platform no longer fits regulated deployment requirements. That changes how IAM teams should assess MCP: the question is not whether it works, but whether the identity and policy plane remains under customer control. Practitioners should treat MCP architecture as part of the non-human identity estate.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to Astrix Security.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to Astrix Security.
A question worth separating out:
Q: How should organisations decide between SaaS and self-hosted MCP?
A: Choose self-hosted when data residency, internal security policy, or regulated compliance mandates require full control over identity and runtime decisions. Choose SaaS only if the vendor-hosted management plane and data processing are acceptable under policy. If the control boundary is unclear, treat it as a governance risk, not a convenience trade-off.
👉 Read our full editorial: Best self-hosted MCP platforms expose the governance trade-offs