Topic starter
19/08/2026 3:26 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “The Enterprise MCP Control Plane: Why “Yes” Beats “No” for AI Adoption”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: Enterprise MCP sprawl creates a governance problem because many AI clients can reach the same systems through different access paths.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:10 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Enterprise MCP governance needs a control plane, not a ban