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.
NHIMG editorial — based on content published by Obot: MCP roadmap and enterprise governance implications
By the numbers:
- MCP reached 110 million SDK downloads per month in sixteen months, a pace that shows how quickly a standard can become infrastructure.
- Claude Code’s earlier MCP implementation consumed roughly one fifth of a 200K-token context window with tool definitions.
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: Why do MCP environments create new identity governance risk?
A: MCP environments create risk because they connect agents to tools, registries, and data sources through dynamic trust relationships.
Q: What breaks when MCP servers expose all tools to every agent session?
A: Overexposure breaks least privilege and makes delegated action harder to contain.
Practitioner guidance
- Map MCP servers to identity-critical assets Inventory every internal MCP server connected to production systems such as CRM, knowledge bases, finance, or HR.
- Put an access broker in front of cross-app access Require token brokering, policy checks, and audit logging at the gateway rather than allowing direct server connections from clients.
- Scope tools by role and task Use progressive discovery so an agent only receives the tools needed for the current session or role.
What's in the full article
Obot's full article covers the operational detail this post intentionally leaves for the source:
- David Soria Parra’s keynote framing for the MCP roadmap and why the community expects enterprise-grade control patterns.
- The June spec revision details for cross-app access, including how token issuance and user experience are expected to change.
- More explanation of the proposed task primitive for long-running work and how server-initiated triggers affect enterprise workflows.
- The practical discussion of skills over MCP and how that changes tool use inside internal servers.
👉 Read Obot's analysis of MCP, enterprise identity, and agentic governance →
MCP in the enterprise: are your identity controls keeping up?
Explore further
MCP is now an identity governance surface, not just a protocol layer. Once MCP moves from demos into Salesforce, Jira, Confluence, Snowflake, and HR systems, the security question shifts from whether tools can connect to who or what is allowed to invoke them. That makes token handling, server scoping, and auditability central to programme design. For IAM and NHI teams, MCP should be treated as governed access infrastructure rather than a developer convenience.
A few things that frame the scale:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 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: How do teams keep MCP and agentic AI from outgrowing existing IAM controls?
A: They should extend IAM controls into the gateway, where token brokering, policy enforcement, and audit logging can be applied consistently. The key is to govern the session and the tool set together, because agentic systems can change what they touch faster than legacy access review cycles can follow.
👉 Read our full editorial: MCP is entering enterprise governance, not just developer adoption