MCP Roadmap Goes Enterprise

The Model Context Protocol began as a simple idea. Let AI systems talk to the tools and data that companies already use, through one shared interface instead of a pile of custom connectors. Anthropic introduced MCP in November 2024 as an open standard for linking models to repositories, business apps, databases, and developer tools. The pitch was technical, but the appeal was obvious. If every tool speaks the same language, agents become much easier to build (anthropic.com). That simplicity is what made the shift at last week’s MCP Dev Summit in New York so important. The maintainers from Anthropic, AWS, Microsoft, and OpenAI were not talking like people polishing a developer toy. They were talking like custodians of infrastructure. In a roundtable covered by The New Stack, they said the next phase of MCP will focus on security, governance, and reliability for production use inside large organizations. The protocol, now housed under the Linux Foundation’s Agentic AI Foundation, is being treated less like a clever integration layer and more like plumbing that enterprises will depend on (thenewstack.io, github.com). That change did not come out of nowhere. In March, lead maintainer David Soria Parra published the 2026 roadmap and made enterprise readiness one of the project’s four top priorities, alongside transport scalability, agent communication, and governance maturation. The roadmap says outright that MCP has moved beyond local experiments and is now running in production, which changes what matters. A protocol that works in a demo can still fail badly behind load balancers, across multiple server instances, or under compliance rules. MCP’s maintainers are now organizing work around those production failures instead of around flashy new features (blog.modelcontextprotocol.io, modelcontextprotocol.io). The most revealing part of that roadmap is what it treats as unfinished. On the security side, the project is pushing for finer-grained least-privilege scopes, stronger guidance against OAuth mix-up attacks, safer credential handling on both clients and servers, and a formal vulnerability disclosure process through the Linux Foundation. On the operations side, it is trying to make Streamable HTTP work cleanly in stateless, horizontally scaled deployments, with standard session creation, resumption, and migration. Those are not cosmetic upgrades. They are the difference between a protocol that developers like and one that security teams will allow into a bank, hospital, or government agency (modelcontextprotocol.io, modelcontextprotocol.io). Authorization is where the enterprise turn becomes easiest to see. MCP’s base authorization model uses OAuth 2.1 patterns and is designed to protect sensitive resources and operations exposed by MCP servers. The docs now say authorization is strongly recommended when a server handles user data, needs auditability, or is being deployed in enterprise environments with strict access controls. That sounds mundane until you remember what MCP is for. It is the layer that lets an agent reach into email, documents, ticketing systems, internal APIs, and admin tools. Once that layer exists, permissioning stops being a feature and becomes the whole game (modelcontextprotocol.io, modelcontextprotocol.io). The project is already sketching how companies will want that control to work. An extension called Enterprise-Managed Authorization puts the organization’s identity provider, such as Okta or Azure AD, in charge of deciding which MCP servers an employee can access and under what conditions. The point is to replace dozens of per-user, per-service approvals with one policy layer run by IT and security. The extension explicitly calls out offboarding, centralized revocation, compliance, and auditable authorization trails. That is the language of enterprise software, not hacker culture. It is also a sign that MCP’s future will be shaped as much by identity systems and admin consoles as by model vendors (modelcontextprotocol.io). What makes this especially striking is who is now aligned around the standard. OpenAI, which did not create MCP, now describes it in its own developer docs as an open protocol that is becoming the industry standard for extending models with tools and knowledge. OpenAI supports MCP across ChatGPT apps, Codex, and API integrations, and even hosts its own public MCP server for developer documentation. Microsoft has collaborated on the C# SDK. AWS has a maintainer at the table. The summit’s message was not that one company won. It was that the connector layer has become too important to leave fragmented, and too risky to leave informal (developers.openai.com, developers.openai.com, developers.openai.com, github.com).