MCP server governance is lagging behind developer adoption

At a glance

What this is: This is a how-to analysis of governing MCP servers, with the central finding that most enterprises are already behind on visibility, access control, and auditability.

Why it matters: It matters because MCP servers behave like non-human identities with runtime access to tools and data, so IAM, PAM, and lifecycle teams need governance patterns before sprawl becomes irreversible.

By the numbers:

• 53% of MCP servers expose credentials through hard-coded values in configuration files.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.

👉 Read Stacklok's analysis of how to govern MCP servers before sprawl grows

Context

Model Context Protocol, or MCP, creates a governed way for AI systems and tools to exchange context and execute actions, but the identity problem appears immediately when teams stand up servers without inventory, access boundaries, or logs. In practice, that turns each MCP server into an unmanaged non-human identity with reachable tools and credentials.

The article argues that MCP adoption is following the same pattern container teams went through before Kubernetes patterns hardened. That comparison is useful because the real issue is not protocol novelty, but whether security and IAM teams can impose registry, policy, secrets, and observability controls before server sprawl outpaces governance.

Key questions

Q: How should security teams govern MCP servers in production?

A: Treat each MCP server as a governed access boundary, not just a utility. Require publisher verification, tool-level approval, least-privilege scopes, and audit logging before production use. The goal is to control what the agent can reach, how long it can reach it, and how every action is traced for response and compliance.

Q: Why do MCP servers create a bigger governance problem than ordinary third-party packages?

A: Because they sit inside an active decision layer. The server is not just code on disk, it is a tool path that an agent can invoke with real permissions and live data. That makes install-time trust, runtime intent, and revocation all part of the same governance decision.

Q: What breaks when MCP servers are not registered centrally?

A: Unregistered servers create shadow deployment. That means the organisation cannot tell which tools are connected, which identities can invoke them, or whether a connection is governed at all. The result is hidden access paths that weaken both policy enforcement and assurance reporting.

Q: What should teams do when an MCP server needs access to production tools or data?

A: Apply the same discipline you would use for privileged non-human access: scope the permissions, isolate the runtime, and require an audit trail for every action. If the server needs broad access, that access should be explicit, time-bound, and reviewable rather than ambient.

Technical breakdown

Registry control for MCP server discovery

An MCP registry is the starting point for governance because you cannot secure what you cannot enumerate. In this model, the registry becomes the authoritative catalog of approved servers, their purpose, and the trust boundary they operate within. That is an IAM problem as much as a platform problem, because discovery determines whether access reviews, approvals, and ownership can happen at all. Without inventory, every other control becomes partial and reactive.

Practical implication: tie MCP onboarding to a registry workflow so every server has an owner, purpose, and approval path before it is reachable.

Runtime access control and scoped tool permissions

MCP governance depends on central policy enforcement because tool access is the real privilege boundary. If a server can call multiple tools or reach multiple data sources without runtime scoping, then the server behaves like a standing-privilege identity with an oversized blast radius. Central policy enforcement also makes access revocation meaningful, because the decision point sits outside the application team. That is the difference between nominal governance and actual control.

Practical implication: enforce runtime scoping at a gateway or proxy layer so tool permissions are explicit, reviewable, and revocable.

Auditability, containment, and secrets handling

The article’s strongest architectural point is that audit and containment have to be structural, not optional. Structured logs for every tool call create the evidence trail security, compliance, and incident response teams need, while container isolation limits how far a compromised server can move. Secrets handling matters because MCP servers often need credentials to reach downstream tools, and embedded secrets collapse governance into obscurity. The point is not just logging more, but making the identity boundary visible and defensible.

Practical implication: pair structured tool-call logging with isolated runtimes and managed secrets so every server leaves an audit trail and a smaller blast radius.

Threat narrative

Attacker objective: The objective is to use an ungoverned MCP server as a path to hidden tool access, unlogged actions, and downstream data or credential exposure.

1. Entry begins when developers deploy MCP servers outside the approved inventory, often with embedded credentials and no central registration.
2. Escalation occurs when those servers gain unchecked tool permissions or access to production resources that were never scoped at runtime.
3. Impact follows when auditors, responders, or IAM teams cannot reconstruct what the server did, expanding compliance risk and blast radius.

Breaches seen in the wild

• New York Times breach — New York Times source code and credentials exposed via GitHub.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

MCP server sprawl is really NHI sprawl with a newer interface: Each unmanaged server is an identity-bearing runtime that can act, call tools, and access data. The governance failure is not protocol adoption itself, but the absence of ownership, inventory, and enforceable access boundaries. Security teams should treat each server as a governed non-human identity rather than as a benign infrastructure component.

Registry-first governance is the decisive control pattern: The article correctly treats discovery as the prerequisite for control because access reviews, approvals, and audit trails are impossible without a complete inventory. That is why registry, approval, and ownership mapping belong ahead of scale. The practitioner conclusion is simple: if a server cannot be named, it cannot be governed.

Blast radius control is the correct framing for MCP security: MCP servers do not need broad network reach to be useful, but they do need constrained tool access and visible execution paths. Isolated runtimes, scoped permissions, and structured logging are the control trio that turns an opaque server fleet into something a security organisation can defend. The practitioner conclusion is to design for containment before convenience.

The named concept here is MCP identity debt: every server created without registry, ownership, and revocation paths becomes accumulated governance debt. That debt compounds when credentials, approval flows, and audit evidence are scattered across teams. The practitioner conclusion is to measure unmanaged server growth as a governance liability, not just an engineering backlog.

Container governance history is informative, but not identical: Kubernetes gave security teams patterns for orchestration, policy, and observability, yet MCP raises the stakes because the server itself carries tool authority. That means IAM, PAM, and platform teams have to collaborate earlier than they did in the container era. The practitioner conclusion is to extend identity governance into the runtime layer, not bolt it on later.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• For a deeper lifecycle view, NHI Lifecycle Management Guide shows how provisioning, rotation, and offboarding need to be tied to runtime ownership.

What this signals

MCP identity debt: the next governance problem is not whether teams will adopt MCP, but whether they will adopt it with ownership, revocation, and evidence trails in place. Once servers multiply across product teams, IAM and platform teams inherit a governance surface that looks more like unmanaged NHI sprawl than like ordinary infrastructure.

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, the weak point is already visible. Security teams should assume that any current inventory of server access is incomplete until registration, secrets handling, and logging are enforced together.

The forward-looking move is to align MCP governance with the NHI Lifecycle Management Guide and the NIST Cybersecurity Framework 2.0 so onboarding, runtime control, monitoring, and response are not separate projects. That is how teams avoid a repeat of the container-era cleanup cycle.

For practitioners

• Inventory every MCP server before expansion Create a mandatory registry process for all MCP servers, including owner, business purpose, environment, and approved tool set. Block production connectivity until the server is registered and reviewed.
• Enforce runtime-scoped tool permissions Place MCP access behind a central policy point so every tool call is checked at runtime against explicit permissions. Remove ambient access and require separate approval for production resources.
• Treat secrets in MCP servers as revocable identity material Move credentials out of configuration files, track where they are used, and tie revocation to offboarding and ownership changes. Any server with hard-coded secrets should be prioritised for immediate remediation.
• Require structured logging for every tool call Ensure each server emits who called what, what was returned, and which identity executed the request. Route those logs into your SIEM so investigators can reconstruct actions without asking developers to reconstruct them manually.
• Apply container isolation principles to MCP runtimes Run servers in isolated containers with restricted east-west connectivity and explicit network policy. If a server is compromised, its ability to traverse to production data should be structurally limited.

Key takeaways

• Ungoverned MCP servers should be treated as non-human identities with delegated tool authority, not as harmless engineering experiments.
• The strongest evidence of risk is already in the environment: hard-coded credentials, incomplete inventories, and weak access scoping are common.
• Registry, runtime policy, structured logging, and isolation are the controls that turn MCP growth into governable identity infrastructure.

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.
• Remote MCP Server: A Remote MCP server exposes tools over a network so an AI client can discover and invoke them through a standard protocol. In security terms, it becomes part of the identity chain, because it brokers requests, handles authorization, and can expand the blast radius when its OAuth implementation is weak.
• 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.
• Mcp Server Identity: The identity assigned to the gateway that mediates agent requests to tools and data sources. It matters because the gateway can become a privilege concentration point if it shares credentials with the agent or inherits broader permissions than the task requires.

What's in the full article

Stacklok's full blog post covers the operational detail this post intentionally leaves for the source:

• The concrete registry and gateway workflow used to govern MCP server discovery and runtime access.
• The Kubernetes Operator deployment pattern for teams that want to operationalise MCP governance at scale.
• The make vs buy comparison showing the practical trade-offs between building, adopting, or waiting.
• The approval workflow and deployment sequence used when an MCP server is brought under control.

👉 Stacklok's full post covers the registry, gateway, and deployment workflow in practice.

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.