AI Model Context Protocol Adds Centralised Auth for Enterprise

The Model Context Protocol team has promoted its Enterprise-Managed Authorisation extension to stable status, adding a centralised way for organisations to control access to MCP servers through their identity provider. The project states the aim is to replace per-server consent prompts with a zero-touch flow in which users sign in once and then access approved servers without further setup.

In the launch announcement, the MCP team says the extension is now stable and has been adopted by Anthropic, Microsoft, Okta, and a growing number of MCP servers. The post says the community has been clear that repeated authorisation prompts are a major pain point in enterprise MCP deployments, as the standard model is user-scoped and tied to interactive auth conventions that do not scale well in larger organisations.

The practical effect is to move the authorisation decision into the enterprise identity provider, rather than leaving it to each employee and each server. The enterprise posts say the result is a "single log in" experience for connected servers and a setup where users inherit access to the servers their organisation has approved. The flow is described as using an Identity Assertion JWT Authorisation Grant, or ID-JAG, which is exchanged for an access token by the MCP server’s authorisation server.

The post highlights the importance of that architecture; it separates identity policy from the tool call itself. The enterprise-managed layer decides whether a user can connect a client to a server, and at what scope, but it does not inspect the MCP traffic after the token is issued. The guide explicitly warns that this is not runtime authorisation for individual actions, which means organisations still need their own controls for what happens once an agent is inside a system.

"Organisations can centrally manage authorisation for MCP servers, and end-users can access all connected MCP servers through a single login."
-- Model Context Protocol blog

The announcement frames this as a response to the way MCP has been adopted in practice. It says the old per-user model creates manual onboarding work, makes it harder for security teams to enforce policy, and blurs the line between personal and work accounts. By contrast, the new extension lets admins define policy once and apply it through their existing identity controls.

Several external write-ups have reached the same conclusion. Ehsan Hosseini describes EMA as the answer to a "mess" created by per-user, per-server OAuth and argues that enterprise identity providers become the authority that determines which clients can reach which servers. That article also makes a useful distinction between connection-level control and per-action control, arguing that EMA does not replace separate policy enforcement for sensitive runtime decisions. Okta is the first identity provider named in the launch, using its Cross App Access approach as the first supported path for enterprises. That makes the current rollout a meaningful but still partial step, since the model depends on both the identity provider and the MCP server supporting the extension. Hosseini notes that the protocol remains additive, so organisations that do not use a supporting identity provider will still need a fallback path.

Community reaction has been broadly positive, especially around the promise of less friction. Jiquan Ngiam wrote on LinkedIn that the extension helps address one of the messiest parts of using agents with data and can improve both security and observability by avoiding awkward auth flows. Other posts called EMA a structural fix for MCP server access, pointing to the move from per-user prompts to a shared enterprise control plane.

"We've heard from the community that authorisation and repeated consent prompts from connected MCP servers is one of the biggest pain points when it comes to managing connectivity in enterprise environments."
-- Model Context Protocol blog

The launch also highlights the ecosystem around the new extension. The announcement says Anthropic has implemented support in its shared MCP layer for Claude, Claude Code and Cowork, while Visual Studio Code has also added support in the IDE. On the server side, Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase are listed as supporting EMA, with Slack and others in progress. That breadth suggests the project is trying to make centralised enterprise auth feel like a default rather than a special integration. This release removes one of the most obvious operational frictions in enterprise adoption of MCP which might be significant for teams trying to connect assistants to internal tools at scale.