XMCP makes MCP server creation easier, but governance risk remains

At a glance

What this is: XMCP is a framework for building MCP servers quickly, and the key finding is that simplified server creation can accelerate MCP adoption faster than governance patterns mature.

Why it matters: It matters because faster MCP server sprawl changes how IAM, NHI, and emerging agentic controls must account for tool access, middleware, and deployment paths.

👉 Read WorkOS's recap of XMCP and the MCP Night 2.0 demo

Context

MCP server security is not only a developer-experience problem. When server creation becomes as simple as dropping files into a tools directory and deploying in a few commands, the identity question shifts from build speed to who can scope, review, and govern the tools that the server exposes.

For IAM and NHI teams, the issue is not the framework itself but the operational pattern it encourages: more servers, more tools, more middleware, and more credentials connected to LLM-driven workflows. That combination widens the governance surface long before most organisations have consistent controls for MCP server identity, access scoping, or secret handling.

This is a typical adoption pattern for emerging protocol ecosystems: usability improves first, then control frameworks try to catch up. The result is usually a gap between how quickly teams can publish capability and how quickly security can prove that the capability is safe.

Key questions

Q: How should teams govern MCP servers that can be deployed with minimal setup?

A: Teams should govern MCP servers as exposed access surfaces, not just as developer tooling. Every routed tool, middleware layer, and deployment endpoint should be inventoried, approved, and tied to an owner before production exposure. The control focus is on tool scope, credential attachment, and rollback, because easy deployment shortens the review window that security programmes usually depend on.

Q: Why do file-based MCP routing patterns increase identity governance risk?

A: File-based routing increases risk because a new file can create a new callable capability without a separate authorisation workflow. That makes it easier for tool sprawl to outrun access review, particularly when the server connects to secrets, internal services, or LLM-driven actions. Governance teams need a live inventory of exposed tools, not only source code review.

Q: What breaks when authentication middleware is inconsistent across MCP tool paths?

A: When middleware is inconsistent, some tool paths may inherit weaker checks, different header handling, or missing policy enforcement. The result is uneven authorisation inside the same server, which is difficult to detect if teams assume one control applies everywhere. Security teams should test each route individually and validate the full middleware chain.

Q: What is the difference between local MCP development and production trust?

A: Local development is about speed and iteration, while production trust requires identity, access, and logging controls that survive external exposure. A server that works on a laptop may still be unsafe to connect to real credentials or data sources. The difference is not technical complexity but governance scope: production adds accountability, inventory, and approval requirements.

Technical breakdown

File-system routing in MCP servers

XMCP turns tools into files that are discovered automatically and injected into the server at runtime. That model reduces scaffolding, but it also changes the security boundary: a new file can become a new callable capability without the kind of explicit registration workflow many teams use for review and approval. In MCP terms, routing is no longer just an application concern. It becomes an identity and authorisation concern because every exposed tool is a potential access path into data, systems, or downstream actions.

Practical implication: treat tool registration as an access-control event, not just a code-change event.

Middleware chaining and authentication boundaries

XMCP’s middleware chaining lets teams stack authentication and request-processing logic around tools. Technically, that makes the control plane flexible, but it also means security depends on middleware order, completeness, and consistent enforcement across every route. A weak chain can let unauthenticated or over-scoped requests reach tools that were assumed to be protected. In MCP deployments, authentication middleware is only part of the story. The real control question is whether every tool path inherits the same identity checks and policy decisions.

Practical implication: validate middleware inheritance for every tool path, especially where headers, tokens, or API keys are injected.

One-command deployment and production exposure

One-command deployment compresses the time between local development and production exposure. In practice, that means an MCP server can move from a developer laptop to an externally reachable endpoint before security has mapped its tool set, reviewed its credentials, or confirmed its blast radius. The architectural risk is not speed alone. It is the loss of a predictable review window between code completion and live access. In identity terms, deployment becomes an entitlement event with almost no friction or checkpointing.

Practical implication: require an explicit production approval gate for MCP servers before they are connected to real credentials or data sources.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

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

NHI Mgmt Group analysis

XMCP exposes the governance gap between tool creation and tool authorisation. The framework makes MCP server development feel lightweight by collapsing routing, scaffolding, and deployment into a simple workflow. That ease is the problem for identity teams, because every new tool is also a new permissioned action surface. The implication is that MCP governance cannot be bolted on after developers have already published capabilities.

File-system-based routing creates a new form of identity sprawl. When tools are discovered from files, the number of callable endpoints can grow faster than review, inventory, and approval processes. This is not just application sprawl. It is NHI sprawl in protocol form, because each tool may touch secrets, services, or downstream systems. Practitioners need to think in terms of exposed action inventory, not just code inventory.

Middleware convenience does not equal trustworthy authorisation. Chained middleware can make authentication look standardised while leaving policy gaps between tools, transports, and environments. If one route inherits weaker checks or inconsistent header handling, the whole MCP server becomes unevenly protected. The field should read this as a reminder that access control is only as strong as the least governed tool path.

One-command production rollout shortens the control window that identity programmes assume exists. Traditional governance assumes there is time to review what is being exposed before it is reachable. XMCP compresses that window, which means teams must re-evaluate approval, inventory, and credential attachment as pre-production gates rather than post-deployment tasks. Security policy needs to move as close as possible to tool publication.

Tooling that accelerates MCP adoption will also accelerate category formation around MCP security. That makes standards, reference patterns, and audit expectations more important, not less, because teams will not accept manual governance at the same speed they accept automated deployment. The practical conclusion is that IAM and NHI teams should treat MCP servers as first-class governed identities, not developer conveniences.

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.
• Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
• For a broader governance lens, Top 10 NHI Issues explains why exposed secrets and over-scoped access remain recurring identity failures.

What this signals

Identity teams will need to treat MCP server publication as a governed entitlement lifecycle, not a developer convenience. With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, per The State of MCP Server Security 2025, the operational problem is already larger than most review processes can absorb. The practical response is to bring tool registration, credential binding, and deployment approval into one control path.

Tool exposure will increasingly drive the audit conversation around protocol-based access. If only 18% of deployments scope tool permissions, teams should expect auditors to ask who approved each callable action and how that approval is enforced over time. This is where Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs becomes relevant, because the issue is lifecycle control, not just configuration hygiene.

For practitioners

• Inventory every exposed MCP tool as a governed access path Create a register of all tools surfaced by each MCP server, including file-based routes, middleware dependencies, and downstream resources touched by the tool. Review that inventory on the same cadence as other privileged integrations.
• Gate production deployment before credentials are attached Block MCP servers from reaching production endpoints until the tool list, transport, authentication chain, and secret sources have been approved. Treat deployment as an access event, not a packaging step.
• Verify middleware consistency across every route Test whether all tool paths inherit the same authentication checks, header handling, and policy enforcement. Pay particular attention to mixed transport setups such as HTTP and stdio, where protections can diverge.
• Separate developer convenience from production trust Allow rapid local experimentation, but require a distinct control path for anything that can touch real secrets or services. That separation should include approval, logging, and rollback expectations before the server is made reachable.

Key takeaways

• XMCP shows how quickly MCP server creation can outpace the governance patterns needed to control exposed tools and credentials.
• The security concern is not deployment speed itself but the shrinking window between tool publication, credential attachment, and production reachability.
• Teams should manage MCP servers as governed access surfaces, with inventory, approval, and route-level authentication checks before production exposure.

Key terms

• MCP Server: An MCP server is a service that exposes tools, resources, or prompts to an AI client through the Model Context Protocol. In practice, it becomes a governed access surface because each exposed tool can reach data, systems, or actions that need identity, scope, and audit controls.
• File-System-Based Routing: File-system-based routing maps executable tool endpoints directly from files in a directory structure. It speeds development, but it also creates a governance challenge because the act of adding a file can effectively add a new permissioned capability without a separate review step.
• Middleware Chain: A middleware chain is the sequence of security and request-processing functions that handle a call before it reaches a tool handler. For MCP servers, the chain determines whether authentication, header parsing, and policy checks are enforced consistently across every route and transport.

Deepen your knowledge

MCP server governance and exposed tool pathways are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is starting to see protocol-based access grow faster than review processes, it is worth exploring.

This post draws on content published by WorkOS: MCP Night 2.0 demo recap on XMCP. Read the original.