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.
At a glance
What this is: This is a maturity model for enterprise MCP adoption that maps four stages from shadow usage to AI-powered integration, with the central finding that identity, access control and auditability become the limiting factors as deployment scales.
Why it matters: IAM teams, NHI governance leads and platform architects need this because MCP moves from developer experimentation to shared enterprise capability only when identity integration and access controls keep pace with adoption.
Context
MCP maturity is really an identity governance problem once usage moves beyond individual experimentation. The article argues that organisations do not just need to discover MCP usage, they need to decide how identity, access and audit controls will behave as assistants and users begin sharing tools across teams.
The practical failure point is the jump from a small managed pilot to scaled deployment. At that point, identity provider integration, role-based access control, audit logging and behavioural controls stop being optional plumbing and become the conditions for safe expansion. The article frames this as a staged operating model, not a product decision.
Key questions
Q: What breaks when MCP deployments move from pilot to shared enterprise use?
A: Pilot-era controls often assume a small number of users and narrow workflows. When assistants are shared across teams, access scope, reuse and auditability all expand at once, so governance based only on approved tools is no longer enough. The control gap appears when identity and logging were designed for experimentation, not reuse.
Q: Why does identity provider integration matter so much for MCP governance?
A: It gives the organisation a central place to authenticate users, map roles and enforce access decisions before assistants reach tools and data. Without that anchor, MCP usage remains fragmented across local clients and ad hoc approvals, which makes visibility incomplete and policy enforcement inconsistent.
Q: How do teams know when an MCP pilot is ready to scale?
A: Readiness shows up when the gateway, catalog, role model, audit logging and operating ownership all work together without manual exceptions. If any of those pieces are still informal, scaling usually increases confusion faster than it increases control. The real test is whether the current setup can support shared use without creating unmanaged drift.
Q: How should security teams govern shared assistants that use multiple MCPs?
A: Treat them as governed enterprise workflows rather than simple chat interfaces. Teams need access scoping, auditability and limits on cross-tool behaviour, because the risk comes from how the assistant combines services and how widely it can be reused once shared.
Technical breakdown
Why MCP gateways need identity provider integration before scale
A managed MCP environment needs a gateway because the control point is not the assistant itself, but the way identities are authenticated, authorised and logged before they touch tools. Identity provider integration lets teams centralise policy, but it also exposes whether the organisation can express access decisions cleanly enough for dozens or hundreds of MCP servers. In practice, this is where shadow usage becomes governable only if identity assertions, role mappings and audit events are consistent across clients and servers.
Practical implication: treat identity provider integration as a prerequisite for scaling MCP beyond a pilot.
Role-based access control versus behavioural controls in scaled deployment
The article makes clear that Stage 2 controls are not enough for Stage 3. Role-based access control can limit who reaches which MCPs, but it does not by itself govern what a multi-MCP assistant does once it starts combining tools, sharing outputs or being reused across teams. Behavioural controls matter when assistants become reusable enterprise assets because the risk shifts from simple access to how actions unfold across multiple services and contexts.
Practical implication: add behavioural governance when assistants start chaining multiple MCPs across departments.
Why audit logging becomes an operational control, not a reporting feature
Audit logging in the model is not just evidence collection after the fact. It is the record that tells security and platform teams which MCPs were used, by whom, through which assistant, and under what approved pattern. Without that trail, readiness checklists and progression criteria become self-reporting exercises rather than controls. The article’s emphasis on governance and success metrics shows that logging is part of the operating model, not a compliance afterthought.
Practical implication: instrument MCP activity so audit data can support governance decisions and stage progression.
Threat narrative
Attacker objective: The objective is to exploit unmanaged MCP adoption paths to reach enterprise tools and data through weakly governed assistant workflows.
- Shadow MCP use appears first, with developers and early adopters connecting local tools to ungoverned MCPs before IT has a formal control plane.
- The next stage is unmanaged expansion, where assistants and MCP servers spread faster than identity integration, access scoping and logging can be standardised.
- At scale, loosely governed assistants can combine tools and share workflows across users, turning poor scoping and weak observability into enterprise-wide impact.
Breaches seen in the wild
- Massive Docker Hub Secrets Leak: 10,000+ Docker Hub container images expose hardcoded secrets and authentication keys.
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Stage transitions, not adoption volume, expose the real control boundary: The article is less about whether MCP will be used and more about when enterprise identity governance stops fitting the adoption pattern. Stage 1 is discovery, Stage 2 is managed access, and Stage 3 is the point where shared assistants force controls to move from individual entitlements to governed operating models. Practitioners should treat the stage jump as the security event, not the rollout itself.
Identity provider integration becomes the first real enterprise gate: The maturity model shows that MCP only becomes governable when identities, roles and audit trails are anchored in a central access fabric. Until then, MCP usage remains shadowed by local tooling and informal approvals, which makes standard IAM visibility incomplete. The implication is that MCP control maturity starts with identity integration, not with assistant design.
Behavioural governance is the named gap that pilot-era controls do not cover: Role-based access control for MCP was designed for bounded access, not for assistants that chain tools and share workflows across business teams. That assumption fails once users build multi-MCP assistants and redistribute them laterally. The implication is that Stage 3 requires governance for action patterns, not just entitlement lists.
Scalable MCP introduces an identity blast radius problem: When a shared assistant can check inventory, update CRM records and draft outputs for an entire team, one control weakness can propagate through many business processes. That is the same structural problem identity programmes have seen in over-permissioned service accounts and shared secrets, except the blast radius now comes through assistant reuse. Practitioners should map MCP sharing to blast radius, not just user count.
MCP maturity is a governance maturity test disguised as a technology roadmap: The strongest organisations are not simply adopting faster, they are deciding whether governed infrastructure can be better than shadow convenience. That is a familiar enterprise pattern, but MCP compresses the timeline because users can assemble value quickly and spread it laterally. The practical conclusion is that identity, access and audit foundations determine whether MCP becomes enterprise infrastructure or persistent shadow IT.
From our research library:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- Read next: MCP Security Guide
What this signals
Identity control has to move upstream of the assistant. Once MCP use spreads across local tools and shared assistants, the meaningful security question becomes who can invoke which tool under which identity, not whether the tool catalog is approved. This is why the gateway, the identity provider and the audit trail need to be designed as one control plane rather than separate projects.
Stage 3 is where governance stops being theoretical. The moment a sales or operations user can build a reusable assistant that reaches multiple systems, the organisation inherits a new identity blast radius. That is the point where role-based access control, logging and behavioural constraints either hold together or fail as a package.
MCP configuration files already expose the scale of the problem: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption. The operational lesson is that discovery, scoping and secret handling need to be governed before shared assistants become normal business infrastructure.
For practitioners
- Map MCP usage before standardising controls Inventory where MCPs are already being used, including local developer tools, shared assistants and pilot gateways, so policy starts from observed behaviour rather than assumptions.
- Anchor MCP access in your identity provider Require central authentication and role mapping for the MCP gateway before expanding the approved catalog or allowing broader business-user participation.
- Separate pilot access from scale-ready access rules Use different controls for a small managed pilot and for shared assistants, because Stage 3 introduces reuse, cross-team sharing and broader blast radius.
- Instrument audit trails for assistant reuse Record which assistant invoked which MCP, which identity authorised it and which workflow it followed, so governance decisions can be based on evidence.
- Test behavioural controls before business rollout Validate limits on tool chaining, assistant sharing and task completion paths before moving from pilot to enterprise deployment.
Key takeaways
- MCP maturity is really a governance story about when identity integration and access control must catch up with adoption.
- The hardest jump is from a small managed pilot to enterprise-wide shared assistants, because reuse multiplies the blast radius of weak controls.
- Teams that want to scale MCP need central identity, auditability and behavioural limits before broad business rollout.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Stage growth depends on narrowing MCP access before shared assistants spread privileges. |
| NHI-10 — Human Use of NHI | Business users building and sharing assistants create a human-to-NHI governance boundary. | |
| Recommendation — Apply NHI-05 to cap MCP permissions at the gateway and remove broad defaults from shared assistants. Use NHI-10 to govern when humans can create, share and reuse assistants that invoke MCPs. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Shared assistants can combine tools in ways that expand privilege beyond the original scope. |
| Recommendation — Map assistant reuse and cross-tool chaining to ASI03 and constrain privilege escalation paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article centres on centralising entitlements for MCP gateways and shared assistants. |
| Recommendation — Apply PR.AA-05 to enforce role-based access and entitlement review for MCP users and assistants. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Shadow adoption and shared assistants create pathways for credential exposure and tool spread. |
| Recommendation — Use TA0006 and TA0008 to hunt for exposed MCP credentials and lateral spread through shared workflows. | ||
Key terms
- MCP maturity model: A MCP maturity model is a staged framework for assessing how securely and effectively an organization uses the Model Context Protocol. It typically measures governance, authentication, authorization, tool exposure, logging, policy enforcement, and operational controls across pilot, controlled, and scaled deployments, helping teams reduce agent-to-tool risk as adoption grows.
- 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.
- Managed Pilot: A controlled MCP deployment stage where a central team provides approved infrastructure, curated tools and basic governance. It is the first point where identity provider integration, role scoping and logging become practical requirements rather than optional improvements.
- 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.
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.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org