Enterprise MCP Readiness: Why Tool Orchestration Needs a Governance Layer
The MCP spec's enterprise pivot exposes a critical gap: who governs what your AI agents can do with the tools they discover?
The November 25 MCP specification update is not just a technical release. It is a signal that the protocol's maintainers recognize what enterprise adopters have been discovering firsthand: connecting AI agents to tools is easy; governing those connections is the hard part.
The spec introduces OAuth 2.1 for enterprise identity, asynchronous task execution for long-running operations, and streamlined HTTP transport. Docker simultaneously announced its MCP Catalog, making over 100 MCP servers discoverable through Docker Hub. The ecosystem is maturing rapidly — MCP downloads have grown 80x in twelve months.
But maturation creates a governance challenge that the protocol itself does not solve. An MCP server registered in your environment exposes tools that AI agents can invoke. Those tools can read files, query databases, execute commands, send messages, and interact with external services. Each invocation represents a data flow that may contain sensitive information, a permission decision that should be auditable, and a cost that should be attributable.
Today, most MCP deployments have no centralized governance. Individual developers register servers, configure access, and manage credentials in ways that are invisible to security and compliance teams. There is no equivalent of an API gateway for MCP tool calls — no single point where access policies are enforced, usage is logged, and data flows are inspected.
The enterprise requirements are clear. First, access control: which users and applications can invoke which tools on which MCP servers, governed by Active Directory group membership rather than developer configuration. Second, approval workflows: sensitive tools should require explicit admin authorization before they can be used. Third, audit logging: every tool invocation logged with the user, the server, the parameters, the result, and the cost. Fourth, credential management: server-specific credentials that are not stored in application code or shared across environments.
These are not exotic requirements. They are the standard expectations for any enterprise technology integration. The gap is that MCP, as a protocol, provides the plumbing but not the governance layer.
Organizations deploying MCP at scale need to build or adopt that governance layer before their tool ecosystem grows beyond what they can track. The alternative is shadow MCP — the same problem as shadow AI, but with agents that can take actions, not just generate text.