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

At a glance

What this is: The MCP 2026 roadmap prioritises enterprise readiness because current deployments still lack standard audit trails, identity-native auth, gateway rules, and portable configuration.

Why it matters: IAM, PAM, and NHI teams need to treat MCP as an enterprise identity surface now because its gaps affect logging, access control, and delegated tool execution across human and machine workflows.

By the numbers:

• Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
• 53% of MCP servers expose credentials through hard-coded values in configuration files.

👉 Read WorkOS' analysis of MCP enterprise readiness gaps and auth patterns

Context

MCP enterprise readiness is the current governance problem, not the protocol mechanics alone. Enterprises are already running MCP at scale, but they are doing so without standard audit trails, identity-native authentication, or predictable gateway behaviour, which leaves tool access difficult to govern across the existing IAM and NHI stack.

The roadmap's enterprise section is effectively a signal that MCP is becoming part of production identity infrastructure. For security leaders, that means the question is no longer whether MCP will need enterprise controls, but whether those controls will be layered on consistently enough to satisfy audit, access review, and delegated-authorisation requirements.

Key questions

Q: How should security teams govern MCP access in enterprise environments?

A: Treat MCP access like any other identity-controlled production surface. Use federated authentication, scoped tokens, logging that can be audited end to end, and revocation paths that sit inside the enterprise identity stack. If access cannot be issued and removed through normal governance, it will drift into shadow identity management.

Q: Why do static secrets create problems for MCP deployments?

A: Static secrets break lifecycle governance because they are hard to review, rotate, and revoke at the same cadence as enterprise access. They also make it difficult to prove who authorised a tool call after the fact. For MCP, that means security teams lose both control and evidence.

Q: What breaks when MCP runs behind gateways without defined auth propagation?

A: The downstream service can no longer reliably tell what the original client was allowed to do, which makes authorisation decisions inconsistent. Session state may also become ambiguous when proxies sit in the path. That creates policy drift across infrastructure that looks identical from the user side.

Q: Who is accountable when MCP access cannot be audited across clients and proxies?

A: Accountability sits with the organisation operating the MCP environment, because the protocol gap does not remove governance responsibility. Teams need a defined control owner for auth, logging, and gateway behaviour. Without that, incidents become reconstruction problems instead of response problems.

Technical breakdown

Audit trails and observability for MCP requests

MCP needs end-to-end visibility from client request to server execution because enterprises must reconstruct who asked for what, what tool ran, and what data moved. Today, many deployments rely on custom logs and ad hoc trace IDs, which makes incident review and compliance evidence brittle. Standardised observability would let MCP events flow into SIEM, APM, and compliance pipelines without a parallel stack. The technical gap is not logging volume, but event consistency and correlation across clients, servers, and intermediaries.

Practical implication: define a logging schema for MCP tool calls before production rollout, including request identity, tool name, authorisation context, and outcome.

Enterprise-managed auth and static secret removal

Current MCP deployments often rely on static client secrets, which creates a brittle trust model that identity teams already know how to avoid. The roadmap points toward SSO-integrated flows and scoped tokens so MCP access can be controlled through existing identity providers rather than isolated credentials. That matters because auth becomes governable when it inherits the same lifecycle, approval, and revocation machinery as the rest of enterprise access. Without that integration, MCP access becomes a shadow identity plane.

Practical implication: replace static MCP credentials with federated flows that can be issued, scoped, and revoked through the enterprise identity stack.

Gateway and proxy patterns behind enterprise controls

Most enterprise MCP traffic will pass through gateways, proxies, or load balancers, but the protocol does not yet define how authorisation propagates through those layers. That creates uncertainty about whether downstream servers can trust forwarded claims, whether session state survives intermediary hops, and what gateways are allowed to inspect or modify. In practice, this is an identity-boundary problem as much as a network problem. If the gateway semantics stay vague, every organisation will invent different control assumptions for the same protocol.

Practical implication: require explicit gateway policy for claim propagation, session handling, and inspection boundaries before allowing MCP traffic across shared infrastructure.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Enterprise readiness is now an identity governance problem, not just a protocol roadmap item. The roadmap shows that MCP deployments are hitting the same failures enterprises see whenever a new control plane arrives before governance catches up. Auditability, access scoping, and credential lifecycle are not optional extras once tools can be invoked in production. The implication is that MCP must be treated like any other identity-bearing execution surface, not a developer convenience layer.

Static-secret MCP access is a shadow NHI pattern in plain sight. The roadmap's move toward SSO-integrated flows confirms that credential sprawl is already the default failure mode. Static secrets break lifecycle control because they sit outside the normal issue, review, and revocation path. Practitioners should recognise this as an NHI governance problem, not just an authentication implementation gap.

Configuration portability is a governance control, not a usability feature. If MCP configuration only works inside one client, policy drift becomes unavoidable and deployment evidence fragments across tools. Enterprises need portable configuration because access scope, permissions, and connection parameters must travel with the workload, not with the app choice. The practitioner conclusion is that portability is part of enforceable governance, not just rollout convenience.

Authorization propagation through gateways is the named concept that now needs attention. Enterprise MCP will almost always sit behind intermediaries, so the real issue is whether the original client's authority survives the hop without being rewritten, widened, or lost. That assumption fails whenever the gateway becomes the de facto authoriser instead of a transport layer. The implication is that identity teams must stop assuming direct client-to-server trust in protocol design.

Cross-App Access and DPoP point to where enterprise NHI governance is heading. The roadmap's directional signals align with a wider shift toward brokered, scoped, and proof-bound access rather than durable shared secrets. That direction validates existing NHI governance models while complicating any programme still built around static credentials and isolated tool trust. Practitioners should expect MCP security to converge on identity-native patterns rather than bespoke protocol exceptions.

From our research:

• 53% of MCP servers expose credentials through hard-coded values in configuration files, according to The State of MCP Server Security 2025.
• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to Astrix Security.
• For the broader credential-exposure pattern, see Ultimate Guide to NHIs , Why NHI Security Matters Now for how secret sprawl turns into governance debt.

What this signals

Static-secret governance is the wrong baseline for MCP. The roadmap confirms that enterprises are already outgrowing ad hoc credential handling, and the security signal is clear: if MCP access is not issued through the identity stack, it will be difficult to audit, revoke, or prove after the fact. That makes MCP a lifecycle problem as much as a protocol one, especially for teams aligning access controls with the Ultimate Guide to NHIs.

Authorization propagation through intermediaries will become a policy test for enterprise architectures. As MCP moves behind gateways and proxies, security teams need to decide whether the network layer is merely transporting requests or quietly redefining trust. That decision belongs in the same control discussion as Zero Trust Architecture, and the relevant baseline is the OWASP Agentic AI Top 10 where tool-use and delegated authority are treated as first-class risks.

Configuration portability is the named concept to watch. If permissions and connection settings do not travel cleanly between MCP clients, governance will fragment along tool boundaries instead of identity boundaries. That is how enterprise deployments accumulate hidden exceptions, and it is why structured access evidence should be treated as part of rollout design rather than post-incident cleanup.

For practitioners

• Replace static MCP credentials with federated access flows Move MCP authentication into the same identity provider and approval path used for enterprise applications. Require scoped tokens, revocation, and session traceability so access is managed through normal lifecycle controls instead of long-lived secrets.
• Define an MCP logging schema before production rollout Capture request identity, tool invoked, authorisation context, and execution outcome in a consistent format that can feed SIEM and compliance workflows. Use structured events rather than free-form logs so auditors can reconstruct each tool action.
• Set gateway policy for claim propagation and inspection Document how authorisation claims move across proxies, what session state survives intermediary hops, and whether gateways may inspect or alter tool arguments. Treat those decisions as policy inputs, not ad hoc network implementation choices.
• Design configuration templates that survive client changes Standardise how server permissions, tool mappings, and connection parameters are expressed so the same MCP setup can move between clients without rebuilding access controls from scratch. Configuration portability should be tested as part of deployment readiness.

Key takeaways

• MCP's enterprise problem is governance, not novelty. The roadmap highlights missing auditability, static-secret auth, undefined gateway behaviour, and non-portable configuration as the blockers that matter most to practitioners.
• The evidence points to a real credential-control gap across MCP deployments. Hard-coded secrets and weak tool scoping show that many current implementations do not yet meet the standards expected of enterprise identity systems.
• Teams should design for federated access, structured logging, and explicit gateway policy now. Waiting for the protocol to catch up will leave production deployments operating with controls that cannot be reviewed, revoked, or defended cleanly.

Key terms

• Mcp enterprise readiness: The set of controls needed to run Model Context Protocol safely in production, including authentication, logging, gateway policy, and configuration consistency. In practice, it is the difference between a developer integration and an identity-governed enterprise surface that can be audited, revoked, and defended.
• Authorization propagation: The way a requester's original permissions are preserved, transformed, or lost as traffic passes through gateways and proxies. For MCP, this determines whether downstream servers can trust the identity context they receive or whether intermediary layers become silent policy rewriters.
• Configuration portability: The ability to move MCP server settings, tool permissions, and connection parameters across clients without rebuilding the access model. In enterprise use, portability is a governance property because inconsistent configuration creates hidden exceptions and fragmented control evidence.

Deepen your knowledge

MCP enterprise auth, gateway trust, and structured observability are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building identity governance for agent-facing infrastructure, it is worth exploring.

This post draws on content published by WorkOS: MCP's 2026 roadmap makes enterprise readiness a top priority. Read the original.