TL;DR: MCP has moved from developer curiosity to enterprise infrastructure, with 110 million SDK downloads per month and a roadmap now centered on cross-app access, long-running tasks, triggers, and skills, according to Obot. The governance question is no longer whether MCP works, but whether identity, audit, and control-plane design can keep pace with agentic systems at production scale.
Editorial analysis by NHI Mgmt Group, based on content published by Obot: “MCP Is Just Getting Started: Unpacking MCP Founder’s Vision for 2026”.
By the numbers:
- MCP reached 110 million SDK downloads per month in sixteen months.
Key questions
Q: How should security teams govern MCP in enterprise environments?
A: Treat MCP as an identity and authorization problem first.
Q: Why do long-running agent tasks increase identity risk in MCP deployments?
A: Long-running tasks increase identity risk because the work window and the credential window can diverge.
Q: What breaks when MCP servers are added without a gateway?
A: Authentication, authorization, and audit responsibilities fragment across servers, which makes policy inconsistent and revocation slow.
Practitioner guidance
- Establish MCP gateway enforcement Centralise token issuance, server allowlisting, and audit logging at a control plane that can scope which identities may connect to which MCP servers.
- Map agent task duration to credential lifetime Review whether long-running agent work can outlast the tokens and approvals it depends on, then block execution paths that can continue on stale credentials.
- Separate tool visibility from tool execution Use role-based scoping so clients only discover the tools they are allowed to use, and so the server cannot implicitly broaden access through discovery.
Bottom line: MCP is no longer just a developer protocol. In enterprise use it becomes a governance problem because every connection creates a new identity decision, a new audit requirement, and a new revocation path.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
MCP governance is now an identity problem, not an integration problem. Once a protocol becomes the default layer for connecting agents to business systems, the question shifts from connectivity to who can authorise, observe, and revoke those connections. That is why the enterprise use case belongs in IAM, PAM, and NHI governance conversations, not only architecture reviews. Practitioners should treat MCP as part of the identity fabric, not a side channel.
A few things that frame the scale:
- 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: How should identity teams govern MCP compared with conventional API integrations?
A: MCP needs runtime identity governance because it is not just a transport layer for requests. Conventional integrations can often be reviewed at design time, but agentic workflows require control over context, delegated authority, and the lifecycle of the credentials that power each tool path.
👉 Read our full editorial: MCP is entering enterprise governance, not just developer adoption