Notifications
Clear all
Topic starter
06/06/2026 11:18 am
TL;DR: MCP has become the de facto protocol for connecting AI systems to tools and data, with roughly 97 million monthly downloads across the Python and TypeScript SDKs and a 2026 roadmap focused on enterprise readiness, according to WorkOS. The governance question is no longer whether MCP will spread, but which identity, consent, and session controls can keep up when AI clients reach into many systems at once.
NHIMG editorial — based on content published by WorkOS: Everything your team needs to know about MCP in 2026
By the numbers:
- The Python and TypeScript SDKs alone see roughly 97 million monthly downloads.
Questions worth separating out
Q: How should security teams govern MCP access in enterprise environments?
A: Treat MCP as a non-human identity and authorization problem, not just an integration protocol.
Q: Why does MCP change identity governance for AI applications?
A: MCP turns AI connectors into standardized access paths to tools and data, which means every server becomes a governed entitlement surface.
Q: What breaks when MCP access is left on long-lived tokens?
A: Long-lived tokens assume access is stable enough to review later, but MCP workflows often involve temporary, multi-step delegation.
Practitioner guidance
- Define MCP server ownership as an identity control Assign each server a named owner for authentication, authorization, logging, and revocation so no deployment exists without an accountable control point.
- Prefer session-scoped access for AI clients Use short-lived access tied to a single task or workflow, and require a new human approval before the agent can open a fresh session.
- Separate local and remote trust models Treat stdio subprocesses as host-bound trust and remote servers as OAuth-governed services, then apply different review rules to each path.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step auth flow differences between stdio servers and remote OAuth-protected servers
- Implementation guidance for OAuth 2.1, resource indicators, and client metadata documents in MCP
- The 2026 roadmap items around enterprise-ready authentication and registry discovery
- Specific guidance on using WorkOS AuthKit as the authorization server for MCP
👉 Read WorkOS's full guide to MCP architecture, auth, and enterprise readiness →
MCP in 2026: what IAM teams need to evaluate now?
Explore further
06/06/2026 12:01 pm
MCP is becoming an identity governance problem before it becomes a platform problem. Once AI clients can reach multiple servers, the control question shifts from connector availability to who or what is allowed to act across those connectors. That puts MCP squarely inside NHI governance, because the protocol is defining machine access paths that behave like identities with delegated authority. Practitioners should treat every MCP server as an entitlement surface, not just an integration endpoint.
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.
- 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: What is the difference between MCP and ordinary API integration for IAM teams?
A: Ordinary APIs are point-to-point connections, while MCP standardises how AI clients discover and use external capabilities across many servers. For IAM teams, the difference is that MCP adds a protocol layer where consent, scoping, and client identity must be governed consistently rather than per integration.
👉 Read our full editorial: MCP in 2026: architecture, auth, and enterprise readiness
