Enterprise MCP governance needs a control plane, not a ban

At a glance

What this is: This is a governance analysis of enterprise MCP sprawl, arguing that approved registries and enforcement layers are more effective than blocking AI use outright.

Why it matters: It matters because IAM, IGA, PAM, and NHI teams need a workable way to govern tool access, audit activity, and reduce shadow AI without driving adoption underground.

By the numbers:

• Large enterprises now average 2,191 applications, and 61.3% of discovered applications qualify as Shadow IT, according to Torii's 2026 SaaS Benchmark Report.
• 10 different AI applications
• The typical enterprise has 200 to 300 AI tools in active use and only knows about 60 of them, according to Larridin's analysis.
• Gartner projects 40% of enterprise applications will feature task-specific AI agents by the end of 2026.

👉 Read Obot's analysis of enterprise MCP governance and control planes

Context

Enterprise MCP governance is becoming a core identity problem because the number of AI clients, agents, models, Skills, and MCP servers is growing faster than central teams can inventory or control. In practice, that means access paths are multiplying across apps, data, and systems before most organisations have a reliable policy model for them.

The old response of simply blocking AI use does not hold up when employees can find sanctioned or unsanctioned alternatives in minutes. For IAM and NHI programmes, the real challenge is to make the approved path easier than the shadow path while still preserving identity-based access control, auditability, and lifecycle governance.

Obot's article is a vendor-side argument for a managed control plane, but the underlying issue is broader than one company. The governance question is how enterprises can let employees use AI productively without losing control of tool permissions, downstream OAuth access, or the audit trail needed for security and compliance.

Key questions

Q: How should security teams govern MCP-enabled AI assistants that can act on tools and data?

A: Treat MCP-enabled assistants as non-human identities with scoped authority, not as passive interfaces. Put a policy decision point between interpretation and execution, require explicit confirmation for privileged actions, and restrict which context sources the assistant may trust. Governance should focus on preventing unverified input from becoming executable intent.

Q: Why do MCP servers create new NHI governance concerns?

A: MCP servers create new NHI governance concerns because they expose application capability to non-human callers through tools and prompts that can be invoked at runtime. That shifts the question from who can reach an API to what an agent is allowed to decide and execute. The governance challenge is preventing the agent from inheriting broader privilege than the user or workflow intended.

Q: What breaks when organisations ban shadow AI instead of governing it?

A: Bans often push AI use into personal accounts, unmanaged devices, and hidden workflows, which removes visibility from security and makes data exposure harder to detect. The control failure is not usage itself, but concealment. A better model is to approve fast, workable alternatives and enforce policy on identity, data handling, and logging.

Q: Who should own governance for MCP tools inside AI environments?

A: Ownership should sit with the team responsible for identity governance and privileged access, not only application engineering. If an MCP tool can read secrets, access data, or trigger actions, the organisation should assign an accountable owner, define scope, and review it through the same governance path as other high-risk non-human identities.

Technical breakdown

Why MCP creates a new identity control surface

MCP, or Model Context Protocol, is an integration layer that lets AI clients and agents connect to tools and data sources through standardised servers. That changes identity governance because the control point is no longer just a user session or a service account, but the chain between the AI runtime, the MCP server, and the downstream app. Once that chain is live in production, each approved connection becomes a policy decision about scope, logging, and revocation.

Practical implication: treat MCP servers as governed access endpoints, not convenience plugins.

Why shadow AI expands through clients, Skills, and registries

The article describes a fragmented estate where employees can adopt AI through coding agents, SaaS copilots, workflow tools, and reusable Skills pulled from public registries. That is structurally similar to NHI sprawl, except the access surface is broader because the same user may switch between many clients while still touching the same back-end systems. The operational challenge is discovery and standardisation, not just tool approval.

Practical implication: build inventory and approval workflows that track AI tools by identity path, not by vendor category.

How a control plane becomes the enforcement layer

A control plane only matters if it can enforce identity policy at runtime. In this model, the registry, client allowlists, OAuth scope controls, audit logging, and data-plane filters work together so a user can only reach approved MCP servers and Skills. That is the difference between governance theatre and governable access: the policy must be visible to the client and enforceable before the tool call completes.

Practical implication: require runtime enforcement for tool access, scope limits, and logging before allowing enterprise AI deployment.

NHI Mgmt Group analysis

Approved AI paths work only when the sanctioned route is easier than the shadow route. The article is right to reject blanket prohibition as a control strategy, because people adopt AI to solve a work problem, not to bypass governance. When the approved registry is slower or harder to use than the unsanctioned alternative, identity policy loses at the point of adoption. Practitioners should read this as a usability problem with direct security consequences.

MCP is not just another integration mechanism. It is an NHI control plane in disguise. Once an AI client can chain through multiple MCP servers, the security question becomes who authorised which server, under what scope, for how long, and with what audit trail. That makes this an NHI governance problem, not a simple application approval problem. The practical conclusion is that lifecycle, scoping, and revocation need to follow the tool path, not just the human user.

Shadow AI and shadow IT are converging into the same governance failure mode. The article's numbers point to a familiar pattern: adoption moves faster than inventory, and inventory moves faster than policy. That creates an identity estate where the organisation cannot reliably say what is connected, who approved it, or whether it is still in use. For security teams, the issue is less about AI novelty than about losing authoritative control over access relationships.

Identity-based access for AI tools is the new minimum control. Role-linked permissions, versioned registries, and auditable approval paths are no longer optional extras. They are the baseline that separates usable enterprise AI from unmanaged tool sprawl. Practitioners should therefore assess AI governance through the same lens they use for NHI and PAM: scope, visibility, and revocation.

Obot's control-plane model reflects where the market is heading, but it also exposes a category shift. Enterprises are no longer choosing between AI adoption and control. They are choosing between governed enablement and invisible proliferation. That shift will favour programmes that can unify NHI governance, identity policy, and runtime enforcement across every AI entry point.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• That is why readers should also review OWASP Agentic AI Top 10 for the control failures that most often accompany agentic sprawl.

What this signals

Approved registries will become the practical boundary between governed AI use and shadow AI. The article points toward a future where the control question is not whether employees use AI, but whether they use it through a path the organisation can see, audit, and revoke. That is the same shift identity teams went through with SaaS sprawl, only now the downstream systems are more sensitive and the access paths are more dynamic.

Identity programmes should expect MCP and Skills to behave like reusable NHI assets, not like ordinary app features. That means the operational model must include ownership, scope, approval, runtime logging, and retirement. When those elements are missing, the organisation will keep discovering AI usage after the fact rather than governing it in advance.

With 92% of practitioners saying AI agent governance is critical but only 44% having implemented policies, the gap is no longer awareness but execution. Teams should align their AI access controls with the same lifecycle discipline they use for the Ultimate Guide to NHIs , 2025 Outlook and Predictions, then extend that discipline to agentic toolchains and MCP routing.

For practitioners

• Define an approved AI registry Create a single sanctioned catalog for MCP servers, Skills, and other approved AI entry points, and make it the easiest path for employees to find and use.
• Bind AI tool access to identity and role Map tool permissions to user identity, role, and business function so downstream access is predictable, reviewable, and limited to what the role actually needs.
• Enforce runtime allowlists and deny-by-default controls Require client-side and gateway-side allowlists for approved servers and tools, with explicit blocking for everything else at runtime.
• Instrument audit trails for every tool call Log which AI client, which identity, which MCP server, and which downstream system were involved in each session so investigations can reconstruct access paths.
• Replace blanket bans with governed enablement Measure whether employees can complete common tasks faster through the approved route than through an unsanctioned workaround, and adjust the control plane until they can.

Key takeaways

• MCP governance is an identity and access problem, not just an integration problem.
• Enterprise AI sprawl becomes unmanageable when sanctioned paths are slower than shadow paths.
• The control plane matters because it can turn approval, logging, and revocation into runtime enforcement.

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 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.
• AI Trust Control Plane: An AI trust control plane is the enforcement layer that converts governance intent into runtime decisions for identity, data, and model access. It sits between policy and execution, using context such as task, entitlement, and environment to approve, constrain, or revoke access as the system operates.
• Skill: A skill is a modular instruction package that teaches an agent how to perform a task at runtime. It can include a markdown instruction file, metadata, scripts, and supporting documents. In agentic environments, a skill is not passive documentation. It is an active control input that can shape behaviour, tool use, and execution.

What's in the full article

Obot's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for building an enterprise MCP control plane around approved registries and client allowlists.
• Implementation examples for deploying MCPs and Skills into real developer and business clients such as Claude Code, Copilot, and ChatGPT Enterprise.
• Reference architecture detail on identity-based access, audit logging, and runtime enforcement across the tool path.
• Practical migration guidance for moving employees from shadow AI usage to a governed approval model.

👉 The full Obot article covers registry design, enforcement points, and the mechanics of moving users off shadow AI.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security 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 or identity security programme, it is worth exploring.