What is the difference between self-hosted and managed MCP governance?

Self-hosted governance makes your team responsible for the platform stack and the controls around it. Managed governance shifts infrastructure responsibility to the vendor, but your team still owns entitlement decisions, audit needs, and policy boundaries.

Why This Matters for Security Teams

Model Context Protocol governance is not just about where the server runs. The real issue is who controls tool access, data exposure, policy enforcement, and auditability when an AI agent can invoke MCP tools at runtime. Self-hosted setups give security teams more direct control, but they also expand operational burden. Managed MCP shifts infrastructure responsibility, yet it does not remove the need to govern secrets, entitlements, logging, and change control. NHIMG research on AI Agents: The New Attack Surface report shows why this matters: 80% of organisations report AI agents have already acted beyond intended scope.

That pattern maps directly to MCP, where the weakest point is often not the runtime itself but the boundary between agent intent and tool permission. The right governance model depends on whether the organisation needs deeper platform control, stricter isolation, or faster operational maturity. Guidance from NIST Cybersecurity Framework 2.0 reinforces that governance must cover asset ownership, access control, monitoring, and response, regardless of hosting model. In practice, many security teams discover the governance gap only after an agent has already connected to a tool it should never have been allowed to touch.

How It Works in Practice

Self-hosted MCP governance means the organisation owns the full control plane: server deployment, network segmentation, authentication, logging, patching, policy enforcement, and incident response. This model is usually preferred when the MCP environment handles sensitive systems, regulated data, or high-risk agent actions. It also allows tighter integration with internal control frameworks, such as centralised secrets management, private network access, and custom approval workflows. The tradeoff is operational complexity. Teams must maintain secure defaults, monitor configuration drift, and keep up with patching and hardening across the stack.

Managed MCP governance shifts those infrastructure responsibilities to a vendor, but the security model is not “outsourced.” The organisation still owns the most important decisions: which agents may use which tools, what data may be exchanged, how exceptions are approved, and what must be logged for investigation. That means identity boundaries, role design, and policy boundaries remain internal control points. For agentic systems, this becomes especially important because tool use is dynamic and context-sensitive, which is why OWASP Agentic AI Top 10 treats tool misuse and excessive authority as core risk categories.

NHIMG’s NHI Lifecycle Management Guide is useful here because both self-hosted and managed MCP need lifecycle discipline around issuance, rotation, revocation, and audit evidence. Current best practice is to separate platform ownership from policy ownership. If the vendor runs the service, the customer still needs tenant-level controls, strong authentication, scoped tokens, and a clear record of every tool invocation. These controls tend to break down when managed MCP is adopted in fast-moving development environments because teams assume the vendor’s operational responsibility also covers authorisation governance.

Common Variations and Edge Cases

Tighter control often increases administrative overhead, requiring organisations to balance security assurance against delivery speed. That tradeoff becomes sharper when MCP is used by multiple teams, multiple agents, or external contractors, because governance can fragment across projects.

One common edge case is hybrid governance. An organisation may self-host MCP for regulated workloads while using a managed service for lower-risk internal use cases. Another is a vendor that offers strong infrastructure guarantees but limited visibility into tool-level events. In that case, the customer still needs compensating controls such as external logging, token scoping, and explicit approval gates. There is no universal standard for this yet, so current guidance suggests treating MCP like any other high-trust integration point: minimise standing access, review tool permissions regularly, and require evidence of policy enforcement.

For organisations building agentic workflows, NHIMG’s OWASP Agentic Applications Top 10 and the NIST Cybersecurity Framework 2.0 both point to the same practical conclusion: hosting choice matters, but governance maturity matters more. The model breaks down most often in developer-led environments where MCP is connected to production systems before permissions, logging, and revocation paths are fully defined.

Related resources from NHI Mgmt Group

• What is the difference between managed and self-hosted AI agent governance?
• What is the difference between attack surface management and NHI governance?
• What is the difference between role-based access and API key governance for NHI security?
• What is the difference between human IAM controls and NHI governance?