What Is Enterprise-Managed Authorization for MCP?

Every MCP server, by default, uses the same authorization model: a user connects a client, gets redirected to the server's consent screen, and authorizes access one server at a time. That's the right default for a person wiring up a personal integration. It's a genuine headache once you're doing it across an entire company.

Enterprise-Managed Authorization (EMA) is the MCP extension that fixes this. It went stable on June 18, 2026, and it's already being adopted by Anthropic, Microsoft, and Okta, among others. Here's exactly what it does, how it works under the hood, and where its limits are.

The problem EMA solves

Picture Northlight Analytics — a mid-size company rolling out MCP-connected agents across its sales and support teams, each employee needing access to five or six internal servers. Under the standard model:

• Onboarding doesn't scale. Every employee has to individually authorize every server. New hire, new round of consent clicks.
• Security teams can't centralize policy. Access is whatever each person happened to authorize, with no single place to review or revoke it.
• Personal and corporate access blur together. There's no way to require a corporate identity, so someone can connect a personal account to a work tool without anyone noticing.

None of these are hypothetical. They're the same three problems that show up in any bring-your-own-SaaS rollout, just moving faster because agents connect to new tools constantly.

How EMA actually works

EMA makes the organization's identity provider (IdP) the authority on who can reach which MCP servers, replacing the per-server consent screen with a background token exchange. The mechanism has three standard pieces stacked together: an OIDC or SAML login, an RFC 8693 token exchange, and an RFC 7523 JWT bearer grant.

Walking through the actual flow:

1. The user signs in once, through the enterprise IdP, to the MCP client (Claude, VS Code, whatever they're using).
2. The client requests an ID-JAG — an Identity Assertion JWT Authorization Grant — from the IdP, exchanging the identity token it already has via an RFC 8693 token exchange request. The IdP evaluates its own policies here: group membership, role, conditional access rules.
3. The client presents the ID-JAG to the MCP server's own authorization server, using it as a JWT bearer grant. The server's auth server validates it and mints a normal MCP access token.
4. The client calls the server with that access token, exactly like a standard OAuth-protected MCP request.

The part users actually notice is what's missing: no redirect to the MCP server's own consent screen. They log in once, and every approved server is just there.

A few properties fall directly out of this design:

• The token is audience-restricted to the one server it was requested for. There's no universal cross-server token — each ID-JAG exchange targets exactly one destination.
• The IdP never sees MCP traffic. Its involvement ends the moment it issues the ID-JAG. It's not in the path of any actual tool call.
• Revocation is centralized. Turn off a user's access in the IdP, and they lose every EMA-connected server at once, instead of requiring per-server cleanup.

EMA vs. standard per-user OAuth

EMA is additive, not a replacement — the standard per-user model remains the default for consumer scenarios, and servers have to explicitly advertise EMA support as a capability before a client will negotiate it.

Who supports it today

As of this writing:

• Identity providers: Okta is the first to ship support, building on its existing Cross App Access (XAA) product.
• Clients: Anthropic has implemented EMA across Claude, Claude Code, and Cowork. VS Code has added support directly in the IDE.
• Servers: Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase support EMA today, with Slack and others actively adding it.

This list moves fast — treat it as a snapshot, not a source of truth. For current status, check the official MCP client support matrix.

If you're building or securing an MCP server yourself, this is the same territory our MCP OAuth 2.1 implementation guide covers for the standard flow — EMA sits on top of that same authorization-server foundation rather than replacing it.

What EMA doesn't do

Worth being direct about this, because it's the single most important thing to understand before you treat EMA as a complete security story: EMA decides whether a connection happens. It does not decide whether a specific action, in the moment, should be allowed.

The IdP's involvement stops the instant it hands over the ID-JAG. It never inspects the actual MCP traffic that follows — meaning it has no visibility into, and no say over, any individual tool call an agent makes after the connection is live. That's a deliberate design choice, and a reasonable one. But it leaves a real gap for anyone deploying agents that act autonomously once connected.

That gap matters especially when AI agents perform tool calls that modify data across multiple systems. The question of what an agent can do after it's connected — not just whether it can connect — is the harder authorization problem. Runtime controls like MCP authorization layers and multi-tenant access control are where that enforcement lives.

Also in this series: Enterprise MCP: How Identity, SSO, and Scoped Auth Actually Work, MCP Security Risks in the Enterprise.