TL;DR: MCP's 2026 roadmap says enterprise deployments are being blocked by missing audit trails, static-secret auth, undefined gateway behavior, and poor configuration portability, according to WorkOS. The real issue is not protocol maturity alone but whether existing identity and observability controls can be made to work at MCP scale.
Editorial analysis by NHI Mgmt Group, based on content published by WorkOS: “MCP's 2026 roadmap makes enterprise readiness a top priority”.
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.
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.
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.
Practitioner guidance
- 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.
- Instrument MCP requests with structured audit data Emit request, tool-execution, and outcome records that can flow into your SIEM or logging pipeline.
- Define gateway policy before production rollout Document how authorization context, session state, and content inspection behave when MCP passes through proxies or load balancers.
Bottom line: MCP’s enterprise problem is not protocol novelty but whether identity, audit, and gateway controls can govern it at production scale.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full 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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: MCP's 2026 roadmap shows enterprise readiness gaps still block scale