Notifications
Clear all
Topic starter
20/08/2026 5:45 pm
TL;DR: Enterprise adoption is moving from shadow experimentation to governed, scaled deployment, with Stage 1 and Stage 2 already common and Stage 2 to Stage 3 the hardest transition, according to Obot. The core issue is not tool adoption alone, but whether identity integration, access scoping, and auditability keep pace as MCP usage spreads across business users and assistants.
NHIMG editorial — based on content published by Obot: The MCP Maturity Model: Full Framework Now Available
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.
Questions worth separating out
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first.
Q: What breaks when MCP servers do not enforce tool scoping?
A: When MCP servers do not enforce tool scoping, models can reach tools and data across users, tenants, or environments that were never meant to be shared.
Q: How do organisations know whether an MCP pilot is actually governed?
A: A real pilot has a curated catalog, audit logs, role-based access control, and a named platform owner who can approve or revoke access.
Practitioner guidance
- Map the current MCP estate before formalising governance Inventory local MCP servers, assistants, and tool endpoints across developer machines and business-user workflows.
- Build the managed pilot around identity controls first Require RBAC, audit logging, and explicit access scoping before approving a broader catalog.
- Review assistant workflows as action chains Test how multi-MCP assistants combine individually approved actions across systems, especially when sales, operations, or support users can share them widely.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- Stage-by-stage maturity characteristics with progression criteria for moving from shadow adoption to managed pilot.
- Readiness checklists covering gateway deployment, identity provider integration, audit logging, and platform team ownership.
- Implementation guidance for scaling from developer-led usage to business-user assistants with multi-MCP workflows.
- Timeline expectations for moving between stages, including the practical lift from pilot to scaled deployment.
👉 Read Obot's full MCP maturity model and Enterprise MCP Playbook →
MCP maturity stages: what do they mean for IAM teams?
Explore further
20/08/2026 6:28 pm
Shadow MCP adoption is the real governance starting point, not stage three maturity. Enterprises rarely encounter MCP first as a formal platform programme. They encounter it as local developer adoption, then discover that the access surface already exists before policy, ownership, or inventory does. That makes discovery the first identity control, because you cannot govern a server, assistant, or credential path you have not classified. The practitioner conclusion is simple: the first question is not how to scale, but how to see what already exists.
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.
- That exposure pattern sits alongside the finding that 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, showing that configuration leakage is already a scale problem.
A question worth separating out:
Q: What should teams do before moving from managed pilot to scaled MCP deployment?
A: Validate that access reviews, logging, support, and ownership can handle broader user groups and multi-MCP assistants. The key test is whether the organisation can explain, certify, and retire access paths after deployment, not just whether the platform is popular internally.
👉 Read our full editorial: MCP maturity models show where enterprise identity control breaks
