Notifications
Clear all
Topic starter
16/08/2026 1:11 pm
TL;DR: Enterprise MCP adoption is blocked less by model capability than by identity, transport, and governance gaps, according to Descope. The article argues that stdio-based servers, weak OAuth implementation, function-level permissions, and missing audit controls make production deployment harder than many teams expect.
NHIMG editorial — based on content published by Descope: 5 enterprise challenges in deploying remote MCP servers
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Classify MCP servers as governed identity surfaces Map each server to an owner, access model, transport type, and audit destination before allowing production use.
- Design scopes around tool functions Inventory each MCP tool action and define the minimum permission needed for read, write, export, and administrative operations.
- 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.
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
👉 Read Descope's enterprise guide to the five challenges blocking MCP deployment →
Enterprise MCP deployments: what security teams are missing?
Explore further
16/08/2026 1:13 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Enterprise MCP adoption stalls on auth, scopes and visibility
