MCP maturity models show where enterprise identity control breaks

At a glance

What this is: This is a maturity framework for MCP adoption that maps how enterprises move from shadow use to governed deployment, with the key finding that identity integration and behavioral controls become the gating factors at scale.

Why it matters: It matters because IAM, NHI, and platform teams need a shared model for governing MCP access before experimentation turns into unmanaged tool sprawl across users, assistants, and departments.

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 Obot's full MCP maturity model and Enterprise MCP Playbook

Context

Model Context Protocol adoption is creating a familiar identity problem: users and developers adopt a new control plane faster than governance can classify, scope, and audit it. In practice, that means MCP is now behaving like earlier cloud and SaaS waves, where shadow usage appears before platform teams have a policy model for access, logging, and ownership.

The primary issue is not whether MCP is useful. It is whether enterprises can turn a fast-growing non-human identity surface into something governable without forcing users back into brittle manual workflows or leaving assistant-to-tool access outside IAM and PAM oversight.

Obot’s maturity model is therefore less about product marketing than about sequencing. The article frames a real operating question for identity teams: when usage is already spreading, what does an acceptable path from discovery to governed deployment actually look like?

Key questions

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

A: Treat MCP as an identity and authorization problem first. Assign ownership for every agent and tool, enforce runtime policy checks on each invocation, and limit what context can flow between tools. The goal is to reduce the agent’s blast radius before it reaches downstream systems, not to rely on static perimeter controls after the fact.

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. The failure is usually not obvious at the interface level. It appears later as leakage, unauthorised actions, or audit gaps that are hard to reconstruct after the fact.

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. If users still rely on ad hoc local setups for the same tasks, the pilot is not replacing shadow usage, only duplicating it.

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.

Technical breakdown

How MCP adoption creates a new identity perimeter

MCP turns tools, data sources, and assistants into an access graph that looks more like an identity layer than a simple integration layer. Each MCP server can expose credentials, permissions, and callable actions, which means the security boundary is no longer the application alone but the combination of gateway, registry, identity provider, and tool permissions. In enterprise use, that creates a non-human identity governance problem because access is often delegated to assistant workflows rather than to a single human operator.

Practical implication: Treat MCP as an identity-governed access plane, not just an integration pattern, and define ownership for every server, tool, and assistant path.

Why Stage 2 is an IAM and RBAC problem, not just a deployment milestone

Stage 2 in the model depends on a curated catalog, identity provider integration, audit logging, and role-based access control. Those are not optional hygiene items. They are the controls that convert shadow usage into a managed pilot by making access visible, bounded, and reviewable. Without them, the organisation still has MCP usage, but now with an administrative wrapper that does not actually change the underlying governance exposure.

Practical implication: Anchor managed pilot design in RBAC, auditability, and identity provider integration before broadening the catalog or user base.

What changes when MCP moves from IT-managed access to business-user assistants

Stage 3 introduces a different risk profile because users start composing multi-MCP assistants that can chain actions across systems. That increases the importance of behavioural controls, not only entitlement checks. Behavioural controls matter because the risky event is no longer whether a user can reach one tool, but whether an assistant can combine several permitted actions into an outcome that was never explicitly reviewed end to end.

Practical implication: Review assistant workflows as chains of access, and test how combinations of allowed tools can create unintended business actions.

Threat narrative

Attacker objective: The objective is to gain durable tool and data reach through the MCP layer in a way that bypasses normal governance and expands effective access.

1. Entry occurs when shadow MCP adoption spreads through local developer tools and unmanaged assistants before IT has a complete inventory of servers and permissions.
2. Escalation happens when a managed pilot lacks enough access scoping or audit discipline to distinguish approved use from broad, implicit tool reach.
3. Impact emerges when multi-MCP assistants chain actions across systems, creating business-wide execution paths that are harder to govern than single-tool access.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

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

NHI Mgmt Group analysis

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.

Stage 2 is where NHI control becomes visible or fails. The model’s managed pilot stage only works if identity provider integration, RBAC, and audit logging are present together. A curated MCP catalog without lifecycle ownership or logging is still shadow access with a prettier interface. The implication for IAM teams is that MCP governance should be measured by whether access can be certified, revoked, and reconstructed after the fact.

Behavioral controls become necessary once assistants can chain tools across systems. At Stage 3, the central problem changes from whether a user may invoke an MCP server to what a multi-step assistant can do with several allowed tools in sequence. That is a governance gap because traditional access reviews certify entitlements, not action chains. Practitioners should treat assistant behaviour as the unit of review, not the individual tool grant.

Identity blast radius is the right concept for MCP scaling. The model is really about how far a single assistant, server, or account can reach once usage scales from one team to many. That matters because broad MCP reach can create organisational blast radius long before the platform feels fully centralised. Security teams should therefore align ownership, logging, and access scope to the blast radius each MCP workflow can create.

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.
• 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.
• For a broader control lens, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle governance patterns that help reduce standing exposure.

What this signals

Identity blast radius will become the practical measure of MCP maturity. Once assistants can chain approved tools across departments, the relevant question is no longer whether MCP is deployed but how far one workflow can reach before governance intervenes. That shift makes access scope, logging depth, and ownership more important than the number of approved servers.

With 53% of MCP servers exposing credentials through hard-coded values in configuration files, the governance gap is not hypothetical. Teams should expect MCP control discussions to move quickly from experimentation to lifecycle management, especially where tool permissions and credential storage are still informal.

The next programme decision is whether to treat MCP as a developer convenience or as an identity surface that needs recurring review. That means aligning IAM, platform engineering, and security operations around the same control plane before stage growth turns into untracked sprawl.

For practitioners

• Map the current MCP estate before formalising governance Inventory local MCP servers, assistants, and tool endpoints across developer machines and business-user workflows. Classify each path by owner, data sensitivity, and whether identity provider integration already exists.
• Build the managed pilot around identity controls first Require RBAC, audit logging, and explicit access scoping before approving a broader catalog. Use the Stage 2 checklist to decide whether the pilot is actually governed or only centrally visible.
• 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. Focus on unintended outcomes created by permitted tool sequences.
• Assign lifecycle ownership to every MCP integration Tie each server and assistant to a named owner responsible for onboarding, access changes, logging, and retirement. If no one can revoke or explain an MCP path, it is not governable.
• Set progression criteria before expanding the catalog Define what must be true to move from shadow adoption to pilot and from pilot to scaled deployment, including minimum logging, support coverage, and access review cadence.

Key takeaways

• MCP maturity is fundamentally an identity governance problem once usage spreads beyond a single team.
• The hardest transition is from managed pilot to scaled deployment because behavioural controls matter as much as access controls.
• Enterprises that cannot inventory, scope, and audit MCP workflows will struggle to govern assistant-driven access at scale.

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.
• Shadow adoption: Unapproved or unmanaged use of MCP servers and assistants before security and platform teams have inventory or policy coverage. It is the first sign that the identity surface already exists, even if the organisation has not formally accepted it.
• Behavioral controls: Controls that assess what an assistant or workflow does across multiple steps, rather than only whether a single permission exists. They matter when MCP usage can chain actions across systems and create outcomes that entitlements alone do not capture.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

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.

👉 Obot's full post covers stage checklists, architecture patterns, and progression criteria for enterprise MCP adoption.

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.