The Official MCP 2026 Roadmap Names the Enterprise Gaps. The Spec Team Is Routing Them Through Extensions.

The Model Context Protocol blog published the official 2026 MCP roadmap. It is a short post by spec-team standards — four priority areas, a few specific work items under each — but it does something the project has not done explicitly before. It names, in plain language, the four problems that enterprises have been hitting when they try to deploy MCP in production. And it announces a new structural mechanism for resolving them: a dedicated Enterprise Working Group, with the work expected to land as extensions rather than as changes to the core protocol.

For anyone tracking how the MCP ecosystem is evolving from a developer-tools protocol toward enterprise infrastructure, this roadmap is the most important spec-team artifact of the year so far. The named gaps were known to the community — every gateway vendor, every security researcher, every enterprise pilot team has been pointing at them for months — but they had not been acknowledged in roadmap language from Anthropic. They are now. The acknowledgment is the part that matters; the routing through extensions is the part that defines how the next twelve months of MCP development will work.

This piece reads the roadmap closely. What the spec team named. What the spec team did not name. What the extension routing implies for the gateway and tooling layers. And what an enterprise pilot team should be doing now, given the new structure.

What the Roadmap Says

The 2026 MCP roadmap organizes its work into four priority areas. The first three are protocol-internal: transport evolution, agent communication primitives, and governance maturation. The fourth — labeled Enterprise Readiness — is where the named gaps live.

The roadmap’s text is direct: “Enterprises are deploying MCP and running into problems including audit trails, SSO-integrated auth, gateway behavior, and configuration portability.” Each of these four items is then expanded with a brief explanation of the problem.

Audit trails. The roadmap acknowledges that enterprises require a record of agent activity that is durable, queryable, and complete. The current spec defines tool invocation and response semantics, but it does not require any particular logging behavior at the client or server level. The audit trail problem, as the spec team frames it, is that enterprises need a uniform way to record what agents did across a heterogeneous deployment without each MCP server implementing logging independently.

SSO-integrated authentication. The roadmap names the integration with enterprise single sign-on systems — Okta, Azure AD, Google Workspace, the major federated identity providers — as an enterprise pain point. The current spec defines authentication at the transport layer but does not standardize the integration patterns for federated identity. Enterprises that have invested in centralized identity management have been writing per-MCP-server adapters, which does not scale across deployments with hundreds of servers.

Gateway behavior. The roadmap names the gateway layer explicitly. Many enterprise MCP deployments now use a gateway component between agents and MCP servers, but the spec does not define how a gateway should interact with the protocol. Which tool definitions are returned to which clients? How are tool calls authorized at the gateway level? How is the gateway’s identity exposed to the server? These are operational questions that the spec has so far treated as out-of-band.

Configuration portability. The roadmap names the problem of moving MCP deployments between environments — dev to staging to production, on-premise to cloud, between cloud vendors. The configuration formats for MCP servers, clients, and the supporting infrastructure are not standardized, which means migration requires per-environment tooling.

Each of these four problems is followed in the roadmap by a routing decision: “Most work expected as extensions rather than core spec changes.”

The Extension Routing Decision

The phrase “as extensions rather than core spec changes” is the load-bearing sentence of the roadmap. It defines how the named problems will be solved, and the choice has implications that go beyond the four enterprise gaps themselves.

An extension, in the MCP architecture, is a protocol feature that lives outside the core specification. Extensions can be implemented by clients and servers that opt into them, but they are not required for protocol conformance. A client that does not implement a given extension can still interoperate with servers that do; the extension is simply not used in that interaction. This is the architectural pattern that web protocols have used for decades, and it is the pattern that allows a core protocol to remain small and stable while adjacent capabilities evolve independently.

Routing the enterprise gaps through extensions has four consequences worth naming.

The first consequence is that solutions will compete. There will not be one canonical audit trail extension; there will be several proposals, and the deployments that implement them will accumulate experience over time, with the strongest converging into broader adoption. The same is true for SSO integration patterns, for gateway behavior conventions, and for configuration portability schemas. The competition is healthy and is part of how protocol extensions mature, but it does mean that enterprises adopting MCP in 2026 will be making bets on which extension proposals will win.

The second consequence is that the core spec will remain small. By explicitly directing the enterprise work to extensions, the spec team is signaling that core protocol stability is more important than enterprise feature completeness. This is the right call for a protocol that is still maturing — every feature added to the core surface increases the conformance burden for every implementation — but it does mean that the core protocol on its own will not be sufficient for enterprise deployment. The enterprise deployment shape will be core spec plus a particular set of extensions.

The third consequence is that the gateway layer becomes more important, not less. The roadmap acknowledges gateway behavior as a named problem, and the solutions will be extensions. The natural place for those extensions to be implemented is in the gateway component itself, which is the piece of the stack that an enterprise controls and can update without modifying every MCP server or every agent. The gateway becomes the integration point for the extension ecosystem. This is the architectural reality the roadmap is pointing at without saying it in those exact words.

The fourth consequence is that the security framing changes. The roadmap labels security and authorization explicitly as “secondary priority” within the priority areas. This is not a statement that security does not matter; it is a statement that the security work is being routed through the same extension mechanism, with the implementation responsibility falling on the implementations rather than the core spec. The reading the wider MCP security community has been giving this is consistent: the structural security improvements will happen at the gateway and the extension layer, not in the core spec.

The Enterprise Working Group

The second roadmap announcement that deserves named attention is the formation of an MCP Enterprise Working Group. The roadmap text describes it as “dedicated” — a separate group within the MCP project’s governance structure with a specific mandate for the enterprise concerns. The contributor ladder language elsewhere in the roadmap, under the Governance Maturation priority area, indicates that the Working Group will have authority to advance proposals through to extension status.

For organizations that want to influence how the named gaps get resolved, the Working Group is the venue. Participation in MCP Working Groups has historically been open — proposals are filed as Specification Enhancement Proposals (SEPs), discussion is public, decisions are documented. The Enterprise Working Group will inherit this structure. Enterprises with strong views on how audit trails should work, how SSO integration should be standardized, how gateway behavior should be specified, or how configuration portability should be schematized have an explicit invitation to bring those views into the standards process.

The timing matters. Extensions tend to consolidate quickly once a Working Group forms — the first credible proposal often becomes the reference, and later proposals have to argue against an established direction. The window in which competing approaches can be advanced is the first six to twelve months after the Working Group convenes. After that, the conversation tends to be about refinement rather than direction-setting.

What the Roadmap Did Not Name

The roadmap is short, and the section of named gaps is shorter. Several enterprise concerns that the community has been raising do not appear directly in the named four. Their absence is informative, in different ways for each.

Supply chain attestation does not appear in the named gaps. The MCP ecosystem has been hit by a series of supply-chain incidents over the past year — the postmark-mcp backdoor in September 2025, the OX Security STDIO findings, the recurring CVE wave in package-distributed servers — and the standard response in mature ecosystems is package signing, reproducible builds, and registry-layer attestation. The roadmap does not name this category. The implication, charitably, is that supply chain is being treated as a problem for the package registries (npm, PyPI, the MCP marketplaces) rather than for the protocol. The less charitable reading is that it is a gap in the gap-naming, and the community will need to surface it through SEPs.

Manifest signing and verification does not appear. A signed manifest — a cryptographic attestation that the tools a server declares are the tools the publisher intended to declare — would close several of the prompt-injection-via-tool-description attack patterns. The roadmap does not name this work. The Enterprise Working Group is the natural venue for someone to file the SEP.

Quarantine and admission semantics do not appear. The protocol does not currently define what happens when a server is present in an environment but has not been approved for use by the agent. The architectural pattern of “default-deny admission with explicit approval” is the de facto standard in the gateway tooling, but the spec is silent on the semantics. The roadmap’s enterprise readiness section is the place where this could be standardized; the silence is a directional signal.

Multi-tenant gateway semantics do not appear. As MCP gateways are increasingly deployed in environments where multiple agents — and multiple users represented by those agents — share a single gateway, the question of how tool visibility, tool authorization, and audit attribution work across tenants becomes important. The roadmap names gateway behavior as a category but does not specify the multi-tenant dimension.

The pattern across these absences is that the security-adjacent and governance-adjacent enterprise work has been folded into the “gateway behavior” category and routed through extensions. The Working Group will likely surface several of these as named SEPs over the next year, but the initial roadmap framing places them inside the gateway concern rather than as separate roadmap items.

What a 2026 Enterprise Pilot Should Do Now

For an enterprise team that is piloting MCP — or that has shipped a small MCP deployment and is thinking about scaling it — the roadmap creates a few specific action items.

The first is to read the named gaps as a permission slip to plan for them. An enterprise that has been waiting for the core spec to define audit trails, SSO integration, gateway behavior, and configuration portability now has the spec team’s explicit acknowledgment that those four categories are real problems being routed through extensions. The action plan that addresses them through the gateway and tooling layer is not a workaround; it is the path the roadmap describes. Investing in a gateway with strong audit logging, federated identity integration, and configuration management is investing in the layer where the next twelve months of extension work will be implemented.

The second is to participate in the Working Group, or at least to follow it. The technical decisions about how the extensions are specified will affect every deployment that adopts them. Organizations with strong opinions about, for example, the structure of the audit log record, the integration pattern for OAuth-based SSO, or the gateway’s role in tool authorization will have more influence by participating early than by reviewing the published extension after it stabilizes.

The third is to plan for extension adoption rather than core spec change. The compliance and security frameworks that enterprises are already operating under — DORA, NIS2, the AI Act eventually, the various sectoral regulations — require capabilities that are now explicitly extension-territory. The implementation plan should be calibrated to “deploy a gateway that supports the right extensions” rather than “wait for the spec to require these capabilities natively.” The spec will not require them natively. The roadmap just said so.

The fourth is to treat the gateway as a strategic component, not a passthrough. The roadmap’s positioning of the gateway as the named integration point for the enterprise extensions means that the gateway is the place where extension support has to be evaluated. A gateway that implements three of the four extension categories has different operational properties than a gateway that implements two of them. The selection criteria for an MCP gateway in 2026 should include extension coverage, not just throughput, transport support, and basic feature parity.

The Roadmap as a Coordination Signal

The MCP 2026 roadmap is, more than anything, a coordination signal. The spec team is telling the ecosystem what to build, what not to expect from the core spec, and where to bring proposals. The named gaps are the work the wider ecosystem is invited to do; the extension routing is the architectural shape of the invitation; the Enterprise Working Group is the venue.

For an enterprise pilot, the roadmap simplifies the planning conversation. The questions of “should we wait for the spec?” or “will Anthropic build this into the protocol?” have been answered: no, and no. The work is going to happen at the gateway and tooling layer, by the broader contributor community, through the extension mechanism. Enterprises that want to be part of how this lands have a clear venue. Enterprises that want to consume the result need to be picking the layer where the result will arrive — the gateway — and the implementations of that layer that are positioning to support the extensions as they mature.

The named gaps describe an ecosystem moving from a developer-tools protocol toward enterprise infrastructure. The extension routing describes how the spec team intends that move to happen: through the community, through the gateway layer, through SEPs that will compete and converge. The Enterprise Working Group is the venue where the convergence will play out.

For 2026, the operative sentence of the roadmap is the one about audit trails, SSO, gateway behavior, and configuration portability. The spec team named the problems. The community will solve them. The gateway is where the solutions will live.