XMCP makes MCP server creation easier, but governance risk remains

At a glance

What this is: XMCP is a framework for creating and deploying MCP servers with declarative routing, built-in middleware, and simplified production rollout.

Why it matters: It matters because easier server creation can outpace governance controls, leaving teams to secure a growing MCP estate before ownership, authentication, and deployment boundaries are defined.

Context

MCP server creation is becoming easier to standardise, which changes the governance problem as much as the developer experience. When a framework turns tools into files, adds middleware by default, and pushes production deployment down to a few commands, the identity question shifts from build speed to control over who can create, publish, and authenticate those servers.

For identity teams, the issue is not whether MCP should exist, but whether the organisation can keep pace with how quickly MCP endpoints are proliferating. The risk sits in inventory, ownership, authentication, and lifecycle control for a new class of tool-facing infrastructure that can appear faster than traditional review cycles.

This article is about developer enablement, but the security implication is governance lag. The article’s examples are typical of early adoption patterns: convenience first, control second, which is where identity debt starts to accumulate.

Key questions

Q: Where does MCP server governance fail when tool creation becomes file based?

A: It fails when creation is treated as a coding convenience instead of a controlled identity event. File-based registration can add live capability without a corresponding ownership, approval, or review step, so the organisation loses sight of what is exposed and who is accountable for it.

Q: Why do MCP deployments increase identity risk so quickly?

A: MCP lowers the friction for connecting agents to tools and data, which means identities, permissions, and trust relationships can appear faster than governance processes can review them. That creates sprawl, hidden ownership, and weak auditability. The risk rises when teams allow broad permissions and long-lived credentials without a clear lifecycle.

Q: How should teams evaluate an MCP server before production use?

A: Check maintainer identity, documentation quality, update recency, and dependency posture, then validate that the client can be limited to specific tools and actions. A directory score or popularity rank is not enough for production decisions. The real test is whether the server can be governed as a bounded identity relationship.

Q: What is the difference between MCP tool routing and access control?

A: Tool routing determines which code path handles a request, while access control determines whether the request should be allowed at all. A file-based route can exist before identity checks are complete, so routing convenience must never be mistaken for authorisation.

Technical breakdown

File-system routing turns MCP tools into deployable identity surface

XMCP maps tools to files in a tools directory, then injects those files into the server automatically. That reduces boilerplate, but it also means a server’s effective capability set becomes a function of what exists in the filesystem at runtime, not just what was formally designed. In MCP terms, every new tool file changes the operational surface that can accept requests, handle context, and expose data or actions to clients. For identity governance, that creates a moving target: the server can gain new behaviour without a parallel governance event if file creation is treated as ordinary development work rather than controlled capability change.

Practical implication: treat tool-file creation as a governed change event, not a purely local code convenience.

Middleware chaining shifts trust from the server to the request path

XMCP supports authentication middleware and chaining, which means access control can be composed across multiple processing layers. That is useful, but it also makes trust dependent on the order and completeness of middleware execution. In identity terms, authentication is only as strong as the full request path that enforces it. If a tool can be reached through a bypassed or misordered chain, the server may look protected while still accepting untrusted calls. For practitioners, the main architectural question is whether middleware is consistently applied to every exposed tool and transport, including future additions.

Practical implication: verify that every MCP route inherits the same authentication and authorisation path.

One-command deployment accelerates production exposure of MCP servers

The demo’s production rollout pattern matters because it compresses the time between local build and external reachability. When a server can be deployed with a small number of commands, production exposure becomes a workflow property rather than a release-management event. That is operationally efficient, but it weakens the natural pause points where ownership, logging, and access scope are usually checked. In identity governance, this is the classic problem of deployment velocity outrunning approval velocity. The server is not just built faster; it becomes reachable faster, which shortens the time available to classify it and attach governance controls.

Practical implication: require pre-production identity checks before an MCP server is allowed to become reachable.

Threat narrative

Attacker objective: The objective is to reach newly exposed MCP capabilities before identity, access, and deployment controls have been fully established around them.

1. Entry occurs when a new MCP server or tool is created through simplified file-based routing and rapid deployment workflows, expanding the reachable surface without a separate governance gate.
2. Credential and request-path trust are then concentrated in middleware, where authentication must be enforced consistently across every tool, transport, and added route.
3. Impact emerges when production exposure happens before ownership, classification, and access policy are fully attached, leaving the server accessible faster than it is governed.

Breaches seen in the wild

• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

XMCP turns MCP growth into a governance scaling problem. The framework removes the friction that often slows early adoption, but that same convenience means servers can proliferate before teams have a stable inventory or ownership model. In practice, the control gap is not just technical configuration; it is the absence of an identity governance process for rapidly created MCP endpoints. Practitioners should assume the surface will expand faster than their review cadence unless creation is treated as a managed lifecycle event.

MCP server sprawl creates an identity classification problem, not only an engineering one. Once tools are mapped to files and deployment is streamlined, the question becomes which servers are approved, which are experimental, and which have production reach. That classification problem sits squarely inside NHI governance because these servers are machine-facing access points that can expose credentials, APIs, or downstream systems. Teams that cannot classify them quickly will struggle to apply least privilege, logging, or offboarding consistently.

The real risk is governance lag between server birth and server control. XMCP compresses the time needed to stand up an MCP server, but lifecycle controls still expect a slower pace of change. That mismatch creates a narrow window where a server can be live, reachable, and partially trusted before its authentication, monitoring, and ownership are fully attached. The practitioner takeaway is to redesign control points around provisioning speed, not around legacy release cycles.

File-system-based capability registration is an identity blast radius amplifier. When capabilities are added by dropping files into a directory, the operational blast radius grows with every new tool unless the directory itself is governed. This is the sort of named concept teams can use internally to describe a familiar failure mode: capability drift hidden inside development convenience. The implication is simple. If the registration mechanism is uncontrolled, the server lifecycle is uncontrolled.

WorkOS’s demo reflects a broader market shift toward low-friction MCP creation, which will reward governance maturity. As more teams move from experimentation to deployment, the differentiator will not be whether an MCP server can be built quickly. It will be whether the organisation can attach ownership, authentication, and review to that server before it becomes business critical. Identity programmes that cannot absorb that pace will accumulate unmanaged machine-facing access paths.

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.
• Read next: MCP Security Guide

What this signals

File-system-based capability registration: When tools become files, the server’s functional surface can expand without a separate governance review. That pattern is attractive for developers, but it means identity teams need a control point around tool registration itself, not just around deployment.

MCP adoption will increasingly test whether organisations can govern machine-facing endpoints at the same pace they can create them. The practical issue is not only authentication, but inventory, ownership, and offboarding for servers that can be added with very little ceremony.

The 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption. That figure underscores why rapid server creation cannot be separated from secrets handling and configuration discipline.

For practitioners

• Govern MCP tool creation as a lifecycle event Require ownership, approval, and classification before a new tool file can be promoted into a reachable MCP server. Treat the tools directory as a governed registry, not an informal development folder.
• Enforce uniform middleware coverage Validate that authentication and authorisation middleware apply to every route, transport, and newly added tool path, including any server extended from an existing Express.js or Next.js application.
• Gate production exposure before deployment Insert a pre-production check for logging, ownership, and access policy before any MCP server can move from local development to externally reachable production status.
• Track MCP servers as machine-facing identities Create an inventory of every production MCP server, its owner, its transport, and its access model so offboarding and review can be handled as part of identity governance.

Key takeaways

• XMCP shows how fast MCP servers can be created, but that same speed makes governance and ownership harder to establish before exposure.
• File-based routing and rapid deployment can hide identity risk inside ordinary development workflows, especially when authentication and review are added later.
• Teams need to govern MCP servers as machine-facing identities, with inventory, access control, and lifecycle management attached before production reachability.

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.
• MCP Server: An MCP server is a tool endpoint that connects an AI agent to external systems and data sources through Model Context Protocol. Because it extends what the agent can reach, it becomes part of the identity and access surface and must be reviewed like any other privileged connector.
• 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 Chaining: A request-processing pattern where multiple middleware functions are applied in sequence before a tool executes. For MCP servers, the security value depends on every step being consistently enforced across all routes and transports.

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.