TL;DR: MCP adoption is moving from experimentation to enterprise infrastructure, and Obot argues that the real challenge is governance: access control, auditing, and policy design around reusable MCP servers that can expose apps and data to LLMs, AI agents, and chat users. The identity lesson is that MCP becomes an NHI governance problem as soon as non-technical users can assemble powerful workflows with their own privileges.
NHIMG editorial — based on content published by Obot: enterprise MCP strategy for scaling AI safely
By the numbers:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems.
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
Questions worth separating out
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first.
Q: What breaks when MCP access is not centrally enforced?
A: When MCP access is not centrally enforced, agents can bypass the sanctioned protocol and reach the same data through alternative connectors or direct application paths.
Q: When should organisations treat MCP as part of IAM and PAM planning?
A: As soon as the server can expose real business systems through reusable workflows.
Practitioner guidance
- Define MCP as a governed identity surface Classify every MCP server as an access boundary that requires explicit ownership, approval, and logging before it is exposed to users or AI clients.
- Bind MCP access to approved business roles Map each reusable server to a documented role and business function so that end users only receive the minimum action set needed for their work.
- Centralize onboarding and audit trails Use one control plane for server registration, policy enforcement, and usage tracking so that every MCP connection is reviewable across teams.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- How the Obot MCP Gateway is positioned as a control plane for onboarding and monitoring servers.
- The specific stage model Obot uses for moving from early experiments to scaled enterprise deployment.
- The article's detailed discussion of elicitation, sampling, and MCP-UI support in enterprise chat tools.
- Obot's own architecture and governance checklist for running MCP more safely at scale.
👉 Read Obot's enterprise MCP strategy article on secure AI adoption →
MCP servers at enterprise scale: what identity teams need to do?
Explore further
MCP governance is now an identity architecture problem, not a tooling add-on. Once AI clients can reach enterprise systems through reusable servers, the control question shifts from integration management to identity policy. That means IAM, PAM, and NHI ownership all become relevant, because the same access path can carry human privileges into AI-driven workflows. The practitioner conclusion is simple: MCP belongs in the identity operating model, not outside it.
A few things that frame the scale:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, which shows how quickly privilege assumptions drift.
A question worth separating out:
Q: What is the difference between a one-off AI integration and a governed MCP estate?
A: A one-off integration is usually a narrow connection with limited reuse. A governed MCP estate standardizes server ownership, access policy, auditability, and lifecycle oversight across many teams and systems. The difference is not technical reach alone but whether the organisation can control reuse at scale.
👉 Read our full editorial: Enterprise MCP strategy is becoming an identity governance problem