Enterprise MCP adoption stalls on auth, scopes and visibility

At a glance

What this is: This is an enterprise guide to the five adoption blockers for Model Context Protocol deployments, centred on auth, permissioning, SSO, and visibility.

Why it matters: It matters because MCP turns AI systems into tool-using identity subjects, so IAM, PAM, and NHI teams have to govern transport, scopes, revocation, and auditability together.

By the numbers:

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

👉 Read Descope's enterprise guide to the five challenges blocking MCP deployment

Context

Model Context Protocol, or MCP, standardises how AI systems connect to tools and data sources, but the enterprise problem is not the protocol itself. The real issue is that identity and access controls were designed for bounded applications and users, not for tool-calling systems that need granular authorization, revocation, and audit trails across distributed environments.

Descope’s guide frames adoption as a production-readiness problem: most MCP deployments still rely on local transport, ad hoc auth patterns, and weak permission models. For IAM and NHI programmes, that makes MCP an access-governance question as much as an integration question.

The article is typical of the current market: it starts from implementation friction and quickly exposes the identity model underneath it. What looks like an integration stack challenge is really a control-surface gap across authentication, authorization, and visibility.

Key questions

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

A: Security teams should bind MCP tool access to enterprise identities, entitlements, and lifecycle state before a request reaches production tools. A gateway can enforce policy at the edge, but governance only exists when the identity system knows who is calling, what they are allowed to do, and whether approval or offboarding has already occurred.

Q: Why do MCP deployments complicate NHI governance?

A: MCP connects agents to tools in a way that can blur the line between a legitimate workload request and an uncontrolled execution path. For NHI governance, that matters because tokens, service accounts, and tool permissions are often managed separately, yet they now combine at runtime. If the request is not bound to identity and context, least privilege is only nominal.

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: Who is accountable when an AI system using MCP accesses the wrong tool or data set?

A: Accountability sits with the organisation that defined the scopes, approvals, and monitoring around the MCP server, not with the protocol itself. Security, platform, and identity teams need explicit ownership for authorization design, logging, and revocation so the delegation chain is clear when misuse occurs.

Technical breakdown

Why stdio transport breaks enterprise deployment assumptions

Most reference MCP servers use stdio transport, which means the server runs as a local process and communicates through standard input and output rather than as a network service. That model is convenient for development, but it prevents horizontal scaling, central logging, network segmentation, and consistent policy enforcement across users or tenants. It also blurs the boundary between the client and the server, making operational control much harder than in a normal enterprise service model.

Practical implication: treat stdio-based MCP only as a development pattern, not as an enterprise control plane.

How OAuth 2.1, PKCE, and DCR change MCP identity design

MCP authorization relies on OAuth 2.1 patterns, including PKCE and Dynamic Client Registration, but many enterprises do not have these flows fully operational. PKCE protects authorization code flows from interception, while DCR allows clients to obtain credentials dynamically at runtime. The operational challenge is that many identity providers do not support the full pattern cleanly, so teams fall back to pre-registration and custom auth logic. That creates brittle trust relationships and weak portability across environments.

Practical implication: validate whether your IdP, token issuance, and registration flows can support runtime client onboarding before scaling MCP.

Why function-level permissions are the real control problem

MCP shifts access control from endpoint-level authorization to function-level permissions, meaning individual tools can require different scopes even when they share the same backend API. That is a material change for RBAC, because a role that grants database access does not automatically justify export, update, or write actions inside an AI tool. Progressive scoping extends this by asking the system to request minimal access first and expand only when a task demands it. The result is a tighter authorization model, but one that needs precise scope design and contextual policy logic.

Practical implication: model scopes around tool actions and intent, not around the underlying application alone.

NHI Mgmt Group analysis

MCP is becoming an identity governance problem before it becomes a platform problem. The article shows that enterprises stall not because AI cannot call tools, but because current auth and authorization models do not cleanly map to tool-calling systems. That is a familiar NHI pattern: access grows faster than the governance layer that should define who or what can use it. Practitioners should treat MCP as part of the identity stack, not as a separate integration concern.

Function-level permissioning is the right unit of control for MCP, but most IAM programmes still think in application-level grants. The article’s core point is that tool actions need narrower scopes than the APIs behind them. That means RBAC alone is usually too coarse, and policy teams need to think in task boundaries, scope translation, and context-aware authorization. Practitioners should rework entitlement design around tool function rather than backend resource.

Progressive scoping creates a governance model that resembles JIT access, but the control objective is different. Here the goal is not just to limit standing privilege, but to let an AI system request only the permissions required for the current intent. That makes auditability and scope expansion policy critical, especially where the same agent may touch multiple tools in one workflow. Practitioners should design for scope escalation with clear approval, logging, and revocation rules.

Visibility is the missing layer in most MCP deployments, and that gap is more dangerous than the lack of a feature checkbox. The article points out that standard MCP implementations often lack centralized audit logging, user enumeration, bulk permission changes, and emergency revocation. Without those controls, organisations can enable access but not govern it. Practitioners should assume MCP will enter the SIEM and IAM stack only after explicit integration work, not by default.

Named concept: tool-function identity sprawl. MCP expands the number of access decisions by multiplying discrete tool actions, scopes, and runtime contexts. That creates a new form of identity sprawl where the challenge is not just how many identities exist, but how many permission edges each one can traverse. The implication is that governance teams will need a dedicated model for tool-level entitlements, not just account-level inventory.

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.
• A separate finding shows that only 18% of MCP server deployments implement any form of access scoping for tool permissions, which leaves most tool access broadly governed at best.
• For a broader identity baseline, see Ultimate Guide to NHIs for lifecycle, visibility, and offboarding patterns that apply when MCP becomes part of production identity architecture.

What this signals

Tool-function identity sprawl: MCP makes authorization decisions multiply faster than many identity programmes can model, because each tool action becomes its own policy boundary. That shifts the work from application access governance to function-level entitlement design, and teams should expect recertification and revocation processes to become more granular as a result.

The practical signal is that identity teams will need to stitch MCP telemetry into SIEM, access reviews, and incident response workflows before production adoption scales. Without that, the organisation can grant access but cannot explain or constrain how tool use unfolds across users, tenants, and tasks.

For a governance baseline, the Ultimate Guide to NHIs remains the better reference point for lifecycle control, while the OWASP Agentic AI Top 10 helps frame tool misuse and identity abuse in AI-connected systems.

For practitioners

• Classify MCP servers as governed identity surfaces Map each server to an owner, access model, transport type, and audit destination before allowing production use. If the server cannot be centrally logged or revoked, keep it out of sensitive workflows.
• Design scopes around tool functions Inventory each MCP tool action and define the minimum permission needed for read, write, export, and administrative operations. Do not let backend API permissions become the default authorization model for AI tool use.
• Test IdP support for OAuth 2.1 and DCR early Validate whether your identity provider can handle PKCE, dynamic registration, and runtime token lifecycle management without custom exceptions. Where it cannot, document the compensating controls and the operational cost.
• Build emergency revocation into MCP operations Ensure you can enumerate connected users, remove tool access selectively, and terminate sessions for compromised identities without disabling unrelated services. That capability should be exercised in incident drills, not only documented.
• Route MCP events into SIEM and access reviews Create a parsing layer for MCP tool calls so security teams can correlate user intent, tool invocation, and data movement in existing monitoring and review processes. Use those records to support recertification and anomaly detection.

Key takeaways

• MCP adoption is stalling because identity controls do not yet match tool-level access behaviour.
• Function-level scoping, OAuth 2.1 support, and centralized revocation are the controls that determine whether MCP can move into production.
• Security teams should treat MCP as an identity governance layer, not just an integration protocol.

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.
• 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.
• 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.
• 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.

What's in the full article

Descope's full enterprise guide covers the operational detail this post intentionally leaves for the source:

• Transport trade-offs between stdio, HTTP, and SSE for remote MCP deployment
• OAuth 2.1, PKCE, and Dynamic Client Registration implementation considerations for enterprise teams
• Function-level permission design and progressive scoping patterns for specific tool actions
• Visibility, audit logging, and emergency revocation features needed for production MCP

👉 Descope's full post covers transport trade-offs, auth implementation, and permission design for enterprise MCP

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.