MCP’s 2026 roadmap shows enterprise readiness gaps still block scale

At a glance

What this is: NHI Mgmt Group's analysis, drawing on WorkOS's blog post: MCP's 2026 roadmap is really an enterprise readiness roadmap, with auth, observability, gateway behavior, and configuration portability now the main blockers to production scale.

Why it matters: IAM, PAM, and NHI teams need to treat MCP as an identity and governance integration problem, because scaling agent-tool access without auditability, SSO-backed auth, and portable policy creates unmanaged access paths.

Context

Model Context Protocol has moved from novelty to enterprise infrastructure, but its current operating model still assumes more flexibility than most production environments can tolerate. The core problem is not whether MCP works in isolated developer setups, but whether identity, logging, and gateway controls can govern it consistently at scale.

WorkOS frames the issue as an enterprise readiness gap across four areas: audit trails, enterprise-managed auth, gateway and proxy patterns, and configuration portability. Each of those gaps maps directly to existing IAM and observability disciplines, which is why MCP adoption now depends as much on control integration as on protocol features.

Key questions

Q: What breaks when MCP sessions rely on persistent client secrets?

A: Persistent client secrets create a standing-access model that is hard to reconcile with MCP’s stateful sessions and multi-step workflows. The result is broader authority than the user may realise at approval time, especially when one client can reach several servers. Teams should prefer session-scoped authorization and explicit revocation paths instead of assuming long-lived tokens are harmless.

Q: Why do gateway and proxy patterns create risk for MCP access control?

A: Gateways can obscure who authorised a tool call, alter session handling, or change what the downstream server can inspect. If that context is not preserved, the server may execute actions without a reliable view of the original client’s scope. Teams need explicit rules for identity propagation and session ownership.

Q: What should IAM teams review before allowing MCP in production?

A: IAM teams should review how the protocol establishes identity, how tool permissions are assigned, and whether the same policy is enforced consistently across clients. If the answer differs by implementation, the organisation has a governance gap that can produce uneven access and weak audit trails.

Q: Should organisations treat MCP configuration portability as a governance issue?

A: Yes. If the same server is configured differently by each client, policy fragments and access reviews become unreliable. Portability determines whether permissions, connection settings, and tool definitions remain consistent enough to govern. For enterprise use, configuration standardisation is part of access control, not just deployment convenience.

Technical breakdown

Why static-secrets auth blocks enterprise MCP adoption

Current MCP deployments often rely on static client secrets, which are easy to copy into scripts and hard to govern across teams. That model clashes with enterprise identity because access is no longer brokering through the organisation’s IdP, approval flow, and audit layer. The roadmap’s call for SSO-integrated flows and scoped tokens points to an access model where MCP auth becomes part of normal enterprise identity policy rather than an exception path. The unresolved issue is not just credential format; it is whether MCP servers can inherit enterprise auth semantics without creating one-off trust zones.

Practical implication: design MCP authentication so it can be mediated by your existing SSO and token governance rather than static shared secrets.

How gateway patterns complicate MCP authorization and session state

Most enterprise MCP deployments will sit behind proxies, load balancers, or API gateways, which means the protocol has to survive intermediaries that can alter transport, identity context, and session handling. The hard problems are authorization propagation, session semantics, and gateway visibility boundaries. If the gateway cannot preserve the original client’s authority context, the server may execute tools without knowing the true scope of approval. If the gateway can inspect or rewrite tool arguments, the control boundary shifts again. Without standard behaviour, each enterprise invents its own interpretation, which is how interoperability breaks and security assumptions drift.

Practical implication: validate how your gateway preserves client identity, authorization context, and session continuity before MCP reaches production.

Why configuration portability becomes a deployment control, not a convenience

Configuration portability sounds like an implementation detail until MCP is rolled out across many clients and toolchains. If each client stores its own server configuration, permission set, and connection parameters, the enterprise ends up with duplicated policy, inconsistent tooling, and poor change control. Portable configuration is therefore an access-governance issue as much as a developer-experience issue, because it determines whether the same server definition behaves consistently across environments. The roadmap correctly treats this as a directional proposal problem rather than a simple file-format question, since portability only matters when different clients interpret configuration the same way.

Practical implication: standardise MCP server configuration patterns early so policy does not fragment across clients and teams.

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

Static secret authentication is the wrong control model for enterprise MCP. A credential that survives across clients, tools, and teams creates an access path that identity governance cannot easily scope, review, or revoke at the point of use. WorkOS is describing a familiar pattern in a new wrapper: when access is anchored to reusable secrets, enterprise IAM becomes a cleanup function instead of the enforcement layer. The practical conclusion is that MCP auth has to move into the same governance plane as the rest of the enterprise identity stack.

Auditability is now a protocol requirement, not a nice-to-have integration. MCP traffic that cannot be reconstructed after the fact leaves security teams blind during investigations, compliance review, and incident response. That is why end-to-end request, execution, and outcome tracing matters so much here. The broader NHI lesson is that tool-using infrastructure only becomes governable when the identity event trail is first-class, not when logs are stitched together later.

Gateway behavior is where enterprise trust assumptions get stress-tested. The protocol may work in direct client-server paths, but production deployments rarely look like that. Once proxies and load balancers sit in the middle, teams need clarity on authorization propagation, session ownership, and what the gateway is allowed to inspect or modify. That means the market is moving from protocol syntax to enforcement semantics, which is where many identity programmes discover their real control boundaries.

Configuration portability exposes whether MCP is becoming a managed platform surface or remaining a developer convenience layer. If one client can define policy that another client silently interprets differently, the control plane is fragmented before deployment even starts. That fragmentation matters for identity teams because it creates hidden exceptions that are difficult to govern, recertify, or retire. Practitioners should read portability as a signal that MCP governance will be won or lost in configuration consistency.

MCP is pushing identity teams toward a new named concept: enterprise-ready agent-tool governance. The roadmap shows that the real challenge is not agent reasoning or protocol syntax, but whether identity, logging, and gateway controls can make tool invocation governable in production. That shifts MCP from a developer integration topic into an access governance topic. Practitioners should treat every MCP deployment as a policy surface, not just a transport choice.

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

Enterprise-ready MCP will be judged by control integration, not protocol adoption alone. The roadmap shows that auth, audit, and gateway semantics are now the deciding factors for production use. Teams that cannot explain how MCP fits into their identity and logging stack should treat the deployment as still experimental, even if developers are already using it.

Configuration drift is becoming an identity risk in tool-connected systems. When MCP server settings do not travel cleanly across clients, the enterprise ends up with shadow policy variations that are hard to review or retire. That is the same governance failure pattern identity teams already know from inconsistent service-account handling, only now it sits in the agent-tool layer.

For practitioners

• Standardise MCP authentication on enterprise identity flows Replace static client secrets with SSO-backed flows, scoped tokens, and revocation paths that your IdP can manage centrally. Treat MCP access as part of normal access governance, not a separate auth island.
• Instrument MCP requests with structured audit data Emit request, tool-execution, and outcome records that can flow into your SIEM or logging pipeline. Make the data searchable enough to answer who did what, when, and under whose authority.
• Define gateway policy before production rollout Document how authorization context, session state, and content inspection behave when MCP passes through proxies or load balancers. Test those paths before you allow tool execution in a live environment.
• Adopt portable server configuration patterns Use a consistent MCP server configuration model across clients so permissions, tool definitions, and connection parameters do not diverge by toolchain. Reconcile client-specific differences before they become governance exceptions.

Key takeaways

• MCP’s enterprise problem is not protocol novelty but whether identity, audit, and gateway controls can govern it at production scale.
• Static secrets, unclear proxy behavior, and non-portable configuration all create exceptions that enterprise IAM teams cannot safely absorb.
• The practical response is to design MCP deployments around existing identity governance, structured logging, and consistent configuration from the start.

Key terms

• Enterprise-ready MCP: An MCP deployment that can be governed through normal enterprise controls for identity, logging, proxying, and configuration. In practice, this means access, audit, and routing behave predictably across clients and environments rather than relying on one-off exceptions.
• Authorization Propagation: Authorization propagation is the time it takes for a membership or role change to become effective across the systems that enforce access. In practice, it determines whether the policy state and the runtime state agree. Slow propagation creates stale access windows that identity teams must treat as a governance risk, not a convenience issue.
• Control Portability: Control portability is the ability of a governance control to keep working when the application architecture changes. In clean core programmes, portable controls survive release cycles, integrations, and cleanup of custom code, which makes them more reliable than controls that only exist inside legacy extensions.
• Partial Observability: Partial observability means the system cannot directly see the full state of the environment and must infer it from incomplete or noisy signals. In AI and security, this is what makes hidden hypotheses, uncertainty, and belief updates necessary rather than optional.

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.