MCP server governance is lagging behind developer adoption

At a glance

What this is: This is a governance guide arguing that MCP server adoption is outpacing control design, leaving teams without inventory, policy, auditability, or containment.

Why it matters: It matters because MCP servers behave like governed non-human identities in practice, so IAM, IGA, and platform teams need to define ownership and access boundaries before sprawl hardens into operational risk.

Context

MCP server sprawl is a governance problem, not just a tooling trend. When developers can stand up servers faster than security teams can inventory and approve them, the organisation loses control over what is running, who can reach it, and which credentials each server can touch.

For IAM and platform teams, the issue is that MCP servers create another class of non-human access that needs ownership, policy, logging, and lifecycle oversight. If those controls are absent at adoption time, they are usually introduced only after the footprint is too large to audit cleanly.

Stacklok frames the risk through a familiar pattern: the early container era showed that unmanaged deployment patterns become expensive to unwind once they are embedded in production. The same governance lag now applies to MCP servers.

Key questions

Q: What breaks when MCP servers run locally without governance?

A: Local MCP servers inherit workstation privileges, which means they can read plaintext secrets, access user-scoped tools, and operate without a central approval point. That breaks the assumption that credential use is limited to known services. The practical result is hidden NHI sprawl, with no reliable inventory or review path for the identities doing the work.

Q: Why do ungoverned MCP servers create compliance and security risk?

A: Because they introduce machine-level access paths without the controls normally used to approve, log, and limit that access. If a server can reach tools or credentials without central policy, the organisation cannot demonstrate least privilege or explain who used what. That is exactly where audit exposure and blast radius grow together.

Q: What are the signs that MCP governance is failing?

A: Common signs include agents reaching systems outside their intended workflow, incomplete audit trails for tool use, and data retrieval that cannot be tied back to a clear business purpose. If teams cannot reconstruct who invoked which tool, against which resource, and why, the MCP layer is already operating with insufficient control.

Q: How should teams govern MCP server installation in developer environments?

A: Treat MCP server installation as a controlled enrollment step, not a convenience action. If the installer can collect API keys, register tools, or establish persistent session authority, then approval, logging, and ownership need to happen at install time. The key control is deciding who can add trusted tools before they become part of daily developer workflow.

Technical breakdown

Why MCP server sprawl is a governance control problem

MCP servers are not inherently risky because they exist. The risk appears when they are deployed outside inventory, policy, and review workflows, which leaves security teams unable to answer basic questions about ownership, access scope, and runtime behaviour. In practice, that means the server estate becomes a shadow layer of machine-access pathways. The control failure is not just discovery; it is the absence of a governed lifecycle for deployment, authorisation, and audit across a distributed server footprint.

Practical implication: Treat MCP servers as governed non-human identities and put them under inventory, approval, and review processes before the footprint expands.

How registry, gateway, and logs change the control model

A registry gives teams an authoritative catalogue, a gateway centralises policy enforcement, and structured logs create an audit trail for tool calls. Those three functions matter because MCP activity is otherwise fragmented across developer teams and runtime environments. Without a registry, you cannot know what exists. Without a gateway, access decisions drift to local implementation. Without structured logs, you cannot reconstruct what was accessed, by whom, and for what purpose. That is an identity governance problem as much as a platform problem.

Practical implication: Anchor MCP governance on discovery, runtime policy, and audit evidence, not on ad hoc developer self-reporting.

Why isolation and Kubernetes primitives matter for MCP

Stacklok argues that governed MCP deployment should borrow from Kubernetes because the core primitives already exist: RBAC, network policy, secrets management, and observability. The technical point is that governance becomes enforceable when access, connectivity, and credentials are separated from the server itself. Isolated containers reduce blast radius, but only if the surrounding controls also prevent credential sprawl and uncontrolled east-west reach. This is why container-era lessons apply: orchestration without governance still leaves security teams with unmanaged reach.

Practical implication: Use container control patterns to constrain MCP servers, but only where RBAC, network boundaries, and secrets handling are actually enforced.

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 server sprawl is a non-human identity governance problem before it becomes an AI problem: the first failure is not model behaviour, it is uncontrolled service-level access. Once teams can deploy servers faster than governance can enumerate them, the organisation loses the ability to assign ownership, scope permissions, or prove auditability. The implication is that MCP governance belongs with NHI and platform controls, not only with AI enablement teams.

Visibility, policy, audit, and isolation are the four controls that separate manageable MCP growth from security debt: each one closes a different governance gap. Visibility answers what exists, policy answers who may use it, audit answers what happened, and isolation limits the damage if one server is misused or compromised. Practitioners should treat those four controls as a minimum operating model, not as optional enhancements.

The named concept here is governed MCP deployment: a deployment pattern in which every server is inventoried, access-scoped, logged, and isolated before it reaches broad use. That concept matters because unmanaged MCP looks less like an experimental feature and more like a persistent machine-access estate. The practical conclusion is that governance has to start at first deployment, not after scale creates a remediation project.

Container-era governance lessons now apply to MCP servers because the control failure is the same: deployment outpaces standardisation, and the remediation bill arrives later. Organisations that wait for a perfect policy model usually inherit a larger inventory, more exceptions, and weaker accountability. The field should read MCP as a signal that identity governance is moving closer to runtime control planes, where lifecycle discipline matters as much as technical capability.

MCP governance will increasingly be judged by whether teams can prove control over non-human access paths, not by whether they can describe the architecture: security and compliance leaders need evidence of inventory, approval, logging, and containment. The practical takeaway is that governance conversations must shift from enthusiasm about capability to proof of control. That is where enterprise confidence will be won or lost.

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.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
• Read next: MCP Security Guide

What this signals

Governed MCP deployment: the control target is not the server itself but the combination of inventory, policy, logging, and containment around it. Teams that wait for a complete architecture before acting usually end up standardising after sprawl has already created exceptions and audit gaps.

MCP adoption is pushing identity programmes closer to runtime control planes, where non-human access needs lifecycle management from day one. That means platform teams, IAM leads, and security architects need a shared model for ownership and approval before the server estate becomes too diffuse to govern cleanly.

For practitioners

• Define an MCP server inventory process Create a single authoritative catalog for every MCP server, including owner, environment, connected tools, and approved use cases.
• Centralise access decisions through a gateway Enforce scoped runtime access so teams do not implement server-by-server policy differently across products or departments.
• Require structured logging for tool calls Record who initiated each call, what was requested, and what was returned so audit teams can reconstruct activity later.
• Isolate MCP servers from production systems Use container boundaries and network policy to limit what each server can reach, especially where credentials are involved.
• Build an approval workflow for new deployments Gate new servers behind review of ownership, access scope, and business justification before they are promoted beyond pilot use.

Key takeaways

• Ungoverned MCP servers create a control gap because teams cannot reliably inventory them, scope access to them, or prove what they did.
• The governance problem is already visible in developer environments, which means auditability and containment need to be designed into deployment rather than added later.
• A registry, runtime policy, structured logs, and isolation together form the minimum control set for keeping MCP sprawl within manageable bounds.

Key terms

• MCP — Model Context Protocol: An open protocol enabling AI agents to connect to external tools, data sources, and services. MCP introduces new NHI considerations as agents must authenticate with credentials, ideally ephemeral, scoped tokens rather than persistent API keys.
• Governed MCP: Governed MCP is a Model Context Protocol deployment that is controlled by policy, identity, and audit requirements before tools or data are exposed to an AI agent. It adds authorization, logging, approval, and scope limits around MCP connections so agent actions remain traceable, least-privileged, and reviewable.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Runtime Policy Enforcement: Runtime policy enforcement evaluates a request at the moment it is executed instead of relying only on preconfigured permissions. For AI agents, this allows decisions to reflect current context, target sensitivity, and behavioural signals rather than static assumptions.

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.