Enterprise MCP adoption stalls on auth, scopes and visibility

At a glance

What this is: This analysis says enterprise MCP adoption is stalling because standard deployments lack the auth, permissioning and observability controls enterprises need for production use.

Why it matters: IAM, PAM and platform teams should treat MCP as an identity and governance problem, because connecting AI tools to enterprise systems without granular access, SSO and auditability creates operational blind spots.

Context

MCP, or Model Context Protocol, is the standard that lets AI systems connect to tools and data sources. In enterprise settings, the control problem is not the protocol itself but whether identity, transport and authorisation assumptions still hold when many users, tenants and tools must be governed together.

Descope's analysis argues that most MCP deployments reach proof of concept faster than they reach production because the default implementation pattern is built for local use, not enterprise control. That shifts the conversation from model capability to access governance, auditability, scope management and operational oversight.

Key questions

Q: What breaks when MCP servers rely on local stdio transport in production?

A: You lose the operational controls that enterprises depend on, including network segmentation, centralized logging, load balancing, and consistent policy enforcement. The server behaves like a local process rather than a governed service, which makes access oversight and incident response much harder.

Q: Why do OAuth 2.1, PKCE and DCR become hard for MCP deployments?

A: They are hard because many teams have not operationalised the identity plumbing required to make MCP work with existing identity providers and runtime client registration. The challenge is not the spec alone. It is the added burden of making token issuance, consent and client trust align without building one-off authorisation logic.

Q: Where does function-level authorisation fail in enterprise MCP use?

A: It fails when organisations keep using application-level RBAC for tool actions that need narrower control. A user may need read access to one function but no export capability, even if both functions touch the same API. Without function-level scopes, AI tool access becomes broader than the task requires.

Q: How should teams respond when an MCP deployment lacks audit logging and revocation?

A: They should treat the deployment as not yet production-ready for sensitive work. Without audit logging, user enumeration and selective revocation, teams cannot prove who used which tool or contain access cleanly during an incident. The result is governance debt that shows up first in audit, then in response.

Technical breakdown

Why stdio-based MCP servers do not fit enterprise deployment

Most reference MCP servers use stdio transport, which means the client and server run on the same machine and communicate through standard input and output rather than over a network. That is workable for local development, but it breaks enterprise assumptions about segmentation, scaling, central logging and policy enforcement. A local process model also makes it hard to apply network controls, separate security zones or collect reliable telemetry on tool execution. In practice, the transport choice shapes the identity control model as much as the auth spec does.

Practical implication: Treat stdio transport as a development pattern, not a production operating model, when you need centrally governed enterprise access.

Why OAuth 2.1, PKCE and dynamic client registration become deployment blockers

MCP's auth model depends on enterprise-grade OAuth behaviour, but many implementations still assume the MCP server can double as the authorisation server. That creates friction with existing identity providers and forces teams to handle PKCE, token issuance and dynamic client registration in ways they may not have operationalised before. The issue is not just protocol compliance. It is the extra identity plumbing required to make external tools, internal policies and runtime consent all line up without creating ad hoc trust shortcuts.

Practical implication: Map MCP auth flows to your existing identity architecture before rollout, rather than letting each server invent its own trust path.

How function-level permissions change the access model for AI tools

MCP pushes permissions down from application or API scope to individual functions, which is a much finer control plane than most RBAC programmes were designed for. A user may be allowed to read one customer record but not export a list, even though both actions touch the same underlying API. Progressive scoping adds another layer by expanding access only when an intent requires it. That means the governance unit is no longer the app or endpoint. It is the tool action and the permission state attached to that action.

Practical implication: Design scopes around specific tool actions and intent, not around broad application-level access groups.

Breaches seen in the wild

• Taiwan autonomous AI agent cyberattack 2026: Up to eight autonomous AI agents cracked 85 Taiwanese government accounts, pivoted through SSO and exfiltrated 2,564+ personnel records.
• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.

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 MCP adoption is now an identity governance problem disguised as an integration problem. The article shows that the blocker is not model connectivity but whether access can be authenticated, scoped and observed at enterprise scale. That shifts MCP from a developer convenience question into an IAM and NHI governance question. Practitioners should treat every MCP connection as a governed identity path, not a plug-in.

Function-level permissions create an identity control plane that most RBAC programmes do not natively support. MCP asks teams to authorise tool actions, not just systems or users, which means broad application entitlements are too coarse for production use. The governance gap is not simply missing granularity. It is that existing entitlement models were built for human workflow access, not for AI-driven tool execution. Practitioners need to re-evaluate whether their current access model can express intent-based access at runtime.

Visibility becomes the limiting control once AI tools start acting through enterprise systems. The article makes clear that auditability, user enumeration and selective revocation are not optional nice-to-haves. They are the only way to make MCP deployments defendable when something goes wrong or when compliance evidence is requested. For identity teams, this is a reminder that access without traceability is not enterprise governance. Practitioners should require event-level observability before broad rollout.

Progressive scoping is a useful concept, but it exposes how few enterprises have lifecycle control over machine access. Dynamic permission expansion only works when issuance, validation and revocation are tightly managed across users, tenants and tools. That makes MCP a test of whether identity governance can keep pace with runtime access decisions. Practitioners should assume that any environment unable to govern short-lived, context-sensitive permissions will also struggle with broader NHI maturity.

Model Context Protocol security will increasingly be judged by the quality of the surrounding identity fabric, not by the protocol alone. The article points to a market pattern in which enterprise-ready MCP depends on SSO integration, token handling, audit logging and multi-tenant control. That validates a wider trend in identity security: the differentiator is shifting from connection support to control depth. Practitioners should evaluate MCP programmes on their governance primitives, not on whether they simply connect successfully.

From our research library:

• 96% of security operations teams report critical blind spots, most commonly in cloud infrastructure (74%) and identity and access behaviour (67%).
• Read next: MCP Security Guide

What this signals

Identity visibility is the gating control for enterprise MCP. The article's operational message is that deployments fail when teams cannot see sessions, tool use and permission state across users and tenants. That is why the difference between an experiment and a governable programme is not model quality but whether access is observable and revocable.

Function-level permissions will pressure existing entitlement models. Broad RBAC works poorly when the control point becomes a specific tool action rather than an application or API. Teams should expect MCP to expose where their current lifecycle and authorisation processes were built for static access, not runtime intent.

Control depth now matters more than protocol adoption. If a team can connect MCP but cannot log it, scope it and shut it down selectively, it has only moved the risk, not reduced it. The next phase of enterprise readiness is not connectivity, but governable identity operations.

For practitioners

• Define production-ready MCP trust boundaries Separate local development servers from enterprise deployments, and require network segmentation, central logging and policy enforcement before any shared use.
• Align MCP auth flows with your identity provider Map OAuth 2.1, PKCE and dynamic client registration to existing identity provider capabilities before building custom auth logic into each server.
• Authorise tools at function level Create scopes for specific MCP tool actions, such as read, update and export, instead of granting broad application-level access.
• Implement progressive scoping for sensitive tasks Grant minimal initial access and expand permissions only when the tool intent and task context justify it.
• Require enterprise-grade observability and revocation Insist on user enumeration, session tracking, selective revocation and SIEM-ready audit events before approving production MCP access.

Key takeaways

• Enterprise MCP is constrained by access governance, not by model capability alone.
• The article ties production readiness to transport choice, OAuth implementation, function-level permissions and auditability.
• Teams that cannot observe and revoke MCP access selectively should not treat the deployment as enterprise-grade.

Key terms

• Model Context Protocol: Model Context Protocol is an open protocol that lets AI agents connect to tools and data sources. It expands what an agent can reach, so governance has to cover not only the model and its prompts, but also every system that can receive or return agent-driven data.
• Function-Level Permissions: Function-level permissions restrict access to individual tool actions rather than an entire application or dataset. For MCP, this is the difference between allowing a client to read a resource and allowing it to delete or modify that same resource, which is where most of the governance risk emerges.
• Progressive Scoping: A pattern where an agent starts with minimal permissions and requests more access only when a later task genuinely requires it. This reduces standing privilege, improves auditability, and makes it easier to see when an agent’s access is expanding beyond its original boundary.
• Dynamic Client Registration: Dynamic client registration is a protocol pattern that allows a software client to register itself with an authorization system automatically. For AI agents, it can reduce manual setup, but it also creates new identities at speed, which makes ownership, policy checks, and revocation essential.

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.