Notifications
Clear all
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.
NHIMG editorial — based on content published by Obot: enterprise MCP governance, approved registries, and control planes for AI adoption
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, rises now use more than 10 different AI applications, and 70% have not moved beyond basic integration, according to Zapier's survey of enterprise leaders.
- The typical enterprise has 200 to 300 AI tools in active use and only knows about 60 of them, according to Larridin's analysis.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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.
👉 Read Obot's analysis of enterprise MCP governance and control planes →
Enterprise MCP governance: why the control plane matters now?
Explore further
19/08/2026 4:10 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Enterprise MCP governance needs a control plane, not a ban
