Every MCP server used to mean one more OAuth consent screen per user. Enterprise-Managed Authorization (EMA) - promoted to stable on June 18, 2026 - moves that decision to the organisation's identity provider: an admin approves a server once, and every authorised employee inherits access automatically. That is a real fix to a real headache. It is also half the story.
What MCP enterprise authorization actually solves
The MCP team has added a centralised way for organisations to control access to MCP servers through their identity provider, with the stated aim of replacing per-server consent prompts with a zero-touch flow in which users sign in once and then access approved servers without further setup.
Before EMA, rolling MCP out to a team was a manual multiplication problem. Every employee who wanted Claude talking to Linear, or Cursor talking to Figma, clicked through their own OAuth consent screen for their own account. Multiply that by a dozen MCP servers and a few hundred employees and IT has no single place to see, let alone control, what's actually connected.
EMA lets an org's identity provider decide which MCP servers an employee can reach, replacing per-server consent screens with a token relay called ID-JAG. The mechanism: SSO login → IdP issues an ID-JAG (RFC 8693 token exchange) → client trades the ID-JAG for a real MCP access token → no redirect to the MCP server's own consent screen.
The MCP team says the extension has been adopted by Anthropic, Microsoft, Okta, and a growing number of MCP servers.
The current server list includes Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase, with Slack adding support.
The gap EMA does not close
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 MCP 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.
This is the part that matters for teams doing more than light read-only workflows. EMA answers "can this employee use the Linear MCP server?" It does not answer "can this agent delete a Linear issue?" or "can this agent write to the production branch?" Those decisions still live wherever they always have - inside the tool itself, or not at all.
The MCP docs name the friction directly: employees shouldn't need to understand the authorisation details of every server their org uses, and security teams can't enforce consistent policy if each person authorises independently. That is the problem EMA solves. But the companion problem - what an authenticated agent is allowed to do once it has a valid token - is left to the MCP server's own permission model, which varies widely.
The context-tax problem compounds this. At the Ask 2026 conference in March, Perplexity CTO Denis Yarats identified two problems at scale: MCP tool descriptions consume 40-50% of context windows before agents do real work, and auth flows across many services become unmanageable. Perplexity partially pulled MCP from internal use. EMA fixes the second. The first still needs an MCP gateway or strict server allow-lists.
Beagle in action#it-ops, Slack thread, mid-morningWho should actually turn EMA on right now
EMA is worth enabling immediately if three things are true:
- Your organisation uses Okta as its identity provider (it is currently the only supported IdP in the stable extension)
- You are rolling out Claude, Claude Code, or VS Code as MCP clients to more than a handful of people
- You have already approved the MCP servers you want teams to use and can express that policy as Okta group rules
If you're on Okta and rolling Claude, Claude Code, or VS Code out to more than a handful of people, EMA replaces a genuinely painful per-server consent grind with one admin decision. Skip it, or don't worry about it yet, if you're a solo developer - OAuth 2.1's Dynamic Client Registration flow is already frictionless for one person - or your org isn't on Okta.
If you are on a different IdP, the extension exists but requires the identity provider to implement the ID-JAG token exchange. 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. Organisations that do not use a supporting identity provider will still need a fallback path.
| Situation | EMA helps | Still your problem |
|---|---|---|
| Rolling out 10+ MCP servers to a team | Consent screen per server eliminated | Per-action scope inside each tool |
| On Okta, groups already defined | Automatic access inheritance | Runtime policy enforcement |
| Non-Okta identity provider | No - fallback to per-user OAuth | All of it, for now |
| Solo developer or small team | Minimal benefit | N/A |
| Agent writing to production systems | Connection governance | Blast-radius controls |
What changed in the broader MCP spec around the same time
EMA did not ship in isolation. The MCP project released three related updates in mid-2026: the release candidate for the 2026-07-28 specification, the stable enterprise-managed authorisation extension, and beta SDKs across Python, TypeScript, Go, and C#. Together these changes address three core production challenges: stateless scaling, centralised identity management, and protocol version stability.
The 2026-07-28 spec aligns MCP authorisation with OAuth 2.1 and OpenID Connect in ways that make it meaningfully enterprise-ready. MCP servers are now formally OAuth 2.1 resource servers. EMA sits on top of that foundation - it is not a replacement for the base OAuth layer, but a provisioning layer above it.
A new deprecation policy - SEP-2596 - guarantees a minimum 12 months between deprecation and removal, meaning teams building on the July 28 spec can expect stable ground going forward. That matters for security teams being asked to sign off on MCP as infrastructure rather than a developer experiment.
The honest summary: together, EMA and the 2026-07-28 spec changes are the clearest signal yet that 2026 is the year MCP stopped being a single-developer tool and started being infrastructure a security team has to sign off on. That is a true step forward. The next step - runtime policy that travels with the agent, not just the connection - is still unwritten.
MCP enterprise authorization: common questions
What is MCP Enterprise-Managed Authorization?
EMA is an MCP extension, stable since June 18, 2026, that lets an organisation's identity provider control which MCP servers employees can use. Instead of each user authorising each server, an admin approves a server once for the org, and the IdP provisions access automatically, scoped to each user's existing groups and roles.
Does EMA replace the need for individual OAuth tokens?
It replaces the interactive consent flow. The token exchange runs entirely in the background, removing the need for individual interactive consent screens. The extension is additive and opt-in; the default remains per-user OAuth for consumer configurations. Teams on Okta get the zero-touch experience; others fall back to standard OAuth 2.1.
Which MCP clients and servers support EMA right now?
Anthropic, Microsoft, and Okta are named in the launch, with a growing number of MCP servers added.
Clients include Claude, Claude Code, Cowork, and VS Code. Servers include Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase, with Slack adding support.
What does EMA not protect against?
EMA 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. An agent with a valid EMA-issued token can still take any action the underlying tool allows for that user. Per-action policy is the server's responsibility, not the protocol's.
How does the MCP context tax relate to enterprise deployments?
Separately from auth, loading many MCP servers burns significant context. A Claude Code session with 5-10 MCPs installed typically burns 50,000-67,000 tokens before the user types a first prompt, community-measured across r/mcp, dev.to, and engineering blogs in 2025-2026. Enterprise deployments that use EMA to simplify access should still audit which servers are actually needed - more approved servers means more context overhead on every agent turn.