TL;DR: Enterprise AI is spreading across clients, agents, models, Skills, and MCP servers faster than IT can govern it, and Obot argues that the answer is an approved control plane rather than blanket prohibition. The deeper issue is not access volume alone, but the loss of visibility, policy enforcement, and identity-based control across a rapidly expanding non-human estate.
At a glance
What this is: This is an analysis of why enterprise MCP and AI tool sprawl needs a governed control plane instead of blanket blocking, with the core finding that sanctioned paths must become easier than shadow ones.
Why it matters: IAM, PAM, and NHI teams need to understand how identity-based control, auditability, and enforcement shift when employees can reach enterprise systems through many AI clients, agents, and MCP servers.
By the numbers:
- Large enterprises now average 2,191 applications, the average employee interacts with 40 applications, and 61.3% of all discovered applications qualify as Shadow IT, with only 15.5% formally sanctioned, according to Torii research cited by Obot.
Context
Enterprise MCP governance is the problem of controlling how AI clients, agents, Skills, and tools reach applications and data without forcing employees into unmanaged workarounds. In this article, the governance gap is not a lack of AI adoption, but the absence of a central control plane that can make approved paths visible, auditable, and easier to use than shadow alternatives.
For IAM and NHI programmes, the issue is that access no longer sits in one client, one workflow, or one integration model. When employees can combine MCP servers, Skills, OAuth apps, browser extensions, and internal APIs across many products, policy has to follow the identity path rather than the tool catalog.
Key questions
Q: What breaks when enterprise AI is governed but not enforced?
A: Policy-only programmes fail because they can define acceptable use without stopping prompt injection, tool misuse, or data leakage during live execution. The result is compliance language without operational control. Security teams need enforcement at the point where the model, agent, or retrieval layer actually acts, otherwise the same risk keeps reappearing in production.
Q: Why do approved AI registries reduce shadow usage more effectively than bans?
A: Bans usually push usage underground without removing demand for the capability. Approved registries work when they make the sanctioned path easier, faster, and more reliable than the shadow one. That changes behaviour because employees keep productivity while security retains visibility, version control, and identity-based policy enforcement.
Q: How should security teams govern managed MCP access for AI clients?
A: Security teams should treat managed MCP as a federated resource server and issue identity-bound tokens for each delegated task. That means no shared service-account secrets, narrow role scopes, and audit logs that can tie the human requester to the agent session and the resulting data access. Use the token as the control boundary, not the client config.
Q: Should organisations prioritise discovery or runtime enforcement first for AI governance?
A: Discovery comes first because runtime enforcement cannot be meaningfully scoped without knowing where AI exists and what it can access. Once the inventory is live, teams can apply policy checks, output controls, and retention requirements to the highest-risk systems first.
Technical breakdown
Why MCP sprawl defeats static allowlists
MCP creates a shared integration layer between AI clients and enterprise systems, but the control problem grows because the same user can chain multiple servers, models, and tools in one session. Static allowlists fail when the real risk is not one approved tool, but the combination of approved and unapproved components assembled at runtime. In practice, the attack surface is distributed across local servers, public registries, OAuth grants, and downstream data sources. That makes inventory, provenance, and runtime policy enforcement more important than simply naming allowed products. A control plane is therefore not just a directory, it is the decision point that ties identity, policy, and execution together.
Practical implication: treat MCP inventory and runtime authorisation as one control problem, not separate ones.
How identity-based enforcement changes enterprise AI access
Once AI tools are used operationally, identity becomes the only stable enforcement layer across clients and platforms. The article’s model assumes approved access should vary by role, data sensitivity, and system scope, not by whoever happens to have installed a client. That is the same logic used in NHI governance for service accounts, except the access path is now mediated by human users plus AI-assisted tooling. The useful shift is from tool-centric approval to identity-centric policy, where the control plane can apply allowlists, audit logging, and data-plane filters before requests leave the organisation. Without that layer, governance stays advisory while the work happens elsewhere.
Practical implication: bind MCP access to identity, role, and data scope before it reaches downstream systems.
Why approved registries reduce shadow AI more effectively than bans
A ban assumes employees will stop using the tool. The article shows the more common outcome is that they move to workarounds, which lowers visibility without removing risk. A curated registry works differently because it makes the safe path faster than the unsanctioned one. That changes the adoption dynamic from concealment to governance: approved MCP servers and Skills become the default, and the organisation retains logs, policy, and version control. The technical point is that convenience and control must align, otherwise users route around the policy surface. That is why enterprise AI governance fails when it is only prohibitive.
Practical implication: design governance so the approved path is easier than the shadow path.
Threat narrative
Attacker objective: The objective is to use uncontrolled AI integration paths to reach enterprise data and systems without passing through governed identity and policy controls.
- Entry happens when employees install or connect local MCP servers, public Skills, browser extensions, or API glue outside central review.
- Credential and policy exposure follow as those tools inherit OAuth grants, scoped credentials, or permissions that were not approved for the full tool chain.
- Impact occurs when a single AI session chains across apps and data sources, creating unauthorized actions, audit gaps, or data disclosure across multiple systems.
Breaches seen in the wild
- Smithery.ai MCP hosting breach 2025: A Smithery.ai build flaw gave GitGuardian a live fly.io token controlling 3,000+ hosted MCP servers and the API keys their clients sent.
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
Enterprise MCP governance is now an identity control problem, not a software preference problem: The article is really about who can reach which enterprise systems through AI clients, not which client teams prefer. Once AI tools can chain through apps, data, and infrastructure, governance has to move from product approval to identity-based enforcement. That means the control plane becomes the place where access, audit, and policy intersect for humans and non-human workflows alike. Practitioners should treat the integration layer as part of the identity plane.
Shadow AI is a control-plane failure, not a user-behaviour problem: The article correctly argues that blanket prohibition pushes usage underground rather than removing it. That is a familiar governance pattern in IAM and NHI programmes: when sanctioned paths are slower or less useful than unsanctioned ones, users route around controls. The named concept here is approved-path governance: making the governed route the easiest route. Practitioners should measure whether the safe path is actually the path of least resistance.
MCP introduces identity blast radius across the tool chain: Once one client can touch many systems in a single session, the access decision is no longer bounded by one application. The blast radius is defined by the farthest reachable app, data store, or API that the client can chain into, which makes trust boundaries much harder to reason about. The implication for governance is that access policy must be enforced at runtime, not assumed at enrolment or procurement.
Control planes will become the default governance pattern for enterprise AI: The market signal here is that broad AI adoption is forcing organisations to centralise policy, observability, and enforcement without standardising on one end-user client. That is a practical shift in how security teams think about agentic and NHI control surfaces. The teams that prepare now will be able to govern multiple clients and tool types without rewriting policy for each product.
The real test is whether governance makes sanctioned use faster than unsanctioned use: The article’s strongest operational insight is that adoption follows friction, not policy intent. If governance adds ticket queues, unclear approvals, or brittle setup steps, users will keep bypassing it. Practitioners should judge their AI control plane by whether it changes behaviour at scale, not by whether it exists on paper.
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
Approved-path governance: Enterprise AI programmes now need a control surface that makes the sanctioned route easier than the unsanctioned one. If employees can reach the same data through multiple clients and registries, the programme’s real job is to reduce friction on the governed path rather than simply expand policy language.
The governance lesson for identity teams is that visibility alone does not change behaviour. Access control, audit logging, and data filters only matter when they are enforced where AI clients actually execute, which is why MCP governance is becoming part of the broader identity architecture.
For practitioners
- Map all AI integration surfaces Inventory clients, agents, Skills, MCP servers, OAuth apps, browser extensions, and custom API glue as one access ecosystem instead of separate tools.
- Publish an approved registry Create a single curated registry of allowed MCP servers and Skills so employees can find vetted options faster than shadow alternatives.
- Bind policy to identity and role Apply access control rules so role, data sensitivity, and system scope determine what an AI client can reach through the control plane.
- Move enforcement to runtime Use allowlists, audit logging, and data-plane filters to block unauthorised tool use at the point of execution rather than relying on policy documents.
- Measure adoption friction Track whether approved AI paths are easier to deploy and use than unapproved ones, because governance fails when the sanctioned route is slower.
Key takeaways
- Enterprise MCP sprawl creates a governance problem because many AI clients can reach the same systems through different access paths.
- The article argues that a control plane works better than bans because it makes approved AI use easier to find, deploy, and govern.
- Identity-based enforcement, runtime policy, and auditability are now central to managing AI tool use across the enterprise.
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 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on access scope and overbroad tool reach across MCP-connected identities. |
| NHI-04 — Insecure Authentication | MCP and Skills access depends on identity-based authentication into downstream systems. | |
| NHI-08 — Environment Isolation | The article stresses separating approved AI paths from unmanaged shadow usage. | |
| Recommendation — Limit MCP-connected identities to the minimum tool and data scope their role requires. Harden authentication paths for AI clients and MCP servers before they reach enterprise systems. Isolate approved AI execution paths from local, unvetted, or public integration environments. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes chained tool access that can cross multiple systems in one session. |
| Recommendation — Map chained MCP activity to credential access and lateral movement so detection covers multi-tool sessions. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The core problem is enforcing permissions across AI clients and tool chains. |
| Recommendation — Apply PR.AA-05 to align AI tool permissions with role, entitlement, and authorisation scope. | ||
| NIST Zero Trust (SP 800-207) | Policy Enforcement Point | The control plane functions as the policy decision and enforcement layer for AI access. |
| Recommendation — Place policy enforcement at the runtime boundary where AI clients request tools and data. | ||
Key terms
- MCP Control Plane: The policy layer that governs which identities can reach which MCP servers and tools. In practice, it centralises registration, authorisation, and audit so access does not depend on the specific AI client a person or workflow happens to use.
- Approved registry: An approved registry is a curated list of sanctioned MCP servers or Skills that users can discover and deploy without building or sourcing unvetted integrations. It turns governance into a practical path of least resistance rather than a blocking mechanism.
- Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
- Identity-aligned enforcement: Identity-aligned enforcement means policy decisions are tied to the user, workload, or service account behind a connection, not only to network location. This matters because valid credentials often determine whether an attacker can move laterally, even when perimeter controls appear intact.
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 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org