Enterprise-Managed Auth Just Killed the MCP Consent Prompt Tax¶
Count how many MCP servers your team runs internally. Now imagine every new hire clicking "authorize" on each one, separately, the first time they touch it. Nobody designed that as an onboarding flow. It's just what happens when an authorization model built for one person connecting one personal tool gets dropped into a company with forty engineers and a dozen internal servers.
We've watched this play out at a few clients now. A new platform engineer joins, gets handed a laptop, and spends their first week clicking through consent screens for the internal Jira MCP server, the deploy-status server, the runbook server, and whatever else the platform team has stood up that quarter. Security has no central record of who approved what, because there isn't a "what" to record — approval lives in each user's own OAuth grant, invisible to anyone but them.
The Enterprise-Managed Authorization (EMA) extension to MCP went stable on June 18. It replaces that per-user model with something an identity team would actually recognize: the IdP decides who gets which server, once, and every client the user logs into inherits that decision automatically.
The list that made this worth writing about
EMA didn't launch as a spec nobody adopted. Okta shipped identity provider support on day one via Cross App Access. Anthropic wired it into Claude, Claude Code, and Cowork. VS Code added a preview integration. And on the server side, Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase already support it, with Slack on the way.
The problem with per-user MCP auth¶
The standard MCP authorization flow is user-scoped by design. You hit a new server, your client redirects you to a consent screen, you approve, and that grant lives with you alone. Do that once and it's fine. Do it across ten internal servers and three clients (Claude Code on your laptop, Claude in the browser, Cowork for the automations your team runs), and it's thirty separate approval events that nobody but you can see.
That falls apart in three specific ways once you're past a handful of users. First, there's no consistent policy — access is whatever each person happened to click through, not what security decided should be allowed. Second, onboarding a new engineer to ten-plus internal servers means ten-plus manual authorization steps, every single time, for every new hire. Third, and this one's easy to miss: without a way to require a corporate identity, someone can authorize an internal MCP server with a personal account by mistake, and nobody notices until it matters.
The audit trail that doesn't exist
If someone in security asks "who has access to the deploy-status MCP server right now," the honest answer under per-user auth is: nobody knows without checking every individual's grants by hand. There's no admin console, no group policy, no single place that says yes or no.
How EMA changes the flow¶
EMA makes the identity provider the decision-maker instead of the individual user. An admin authorizes a server for the organization once, and the IdP hands out access based on group membership and role from then on. Nobody sees a consent screen for that server again.
The mechanism is an Identity Assertion JWT Authorization Grant, ID-JAG for short. When a user signs into their MCP client, the client requests an assertion from the IdP as part of that same sign-in. It trades that assertion for an access token directly with the MCP server's authorization server. No redirect, no separate approval step, no second login. This is the same pattern Okta already ships as Cross App Access, so if your org runs Okta, the identity side of this isn't new engineering — it's turning on a capability that already exists.
# Illustrative EMA-style server provisioning entry —
# actual schema depends on your IdP's admin console / API,
# shown here to convey the shape of the mapping
server: deploy-status-mcp
authorization_server: https://mcp.internal.example.com/oauth
allowed_groups:
- platform-engineering
- on-call-rotation
grant_type: id-jag
Check client support before you plan around this
EMA only works end to end if your MCP client implements it. Claude, Claude Code, and Cowork support it now; VS Code has a preview integration. If your team's daily driver isn't on that list yet, the servers can be EMA-ready and users will still hit the old consent flow.
What changes for a platform team¶
Rolling this out isn't a big-bang migration — it's closer to turning on a switch per server, one at a time. Start by listing every internal MCP server your team runs and checking which ones support EMA today; most of the well-known SaaS servers already do, but anything you've built in-house needs to implement the extension yourself against the published spec. Then map your existing IdP groups to server access — if you already use groups for VPN or SSO app access, you're reusing infrastructure you've already got, not building new plumbing.
Not everything belongs under EMA on day one. Personal integrations and anything with high-risk write scopes are worth leaving on manual consent for now, at least until you've watched the centrally-managed servers run for a few weeks. This is opt-in per server, not a forced migration, so there's no reason to flip everything at once.
Where this actually saves time
The payoff shows up hardest during onboarding. A new engineer signs in once, and every EMA-enabled server they're authorized for connects without them touching a consent screen. That's the ten-tickets-to-zero-tickets shift platform teams have been asking for since MCP adoption started climbing.
Where this fits the Polarpoint stack¶
If you've been running ToolHive's Kubernetes operator for your self-hosted MCP servers, EMA slots in above that layer rather than replacing it — ToolHive handles RBAC and secret injection at the cluster level, EMA handles who's allowed to connect from the client side. The two aren't competing, they're solving different halves of the same problem.
The bigger pattern here is one we've written about before in a different context: policy-as-code for GitOps moved Kubernetes access decisions out of tribal knowledge and into version-controlled config that Kyverno enforces automatically. EMA does the same thing for AI tool access — the difference is the policy now lives in your IdP's admin console instead of a Kyverno ClusterPolicy. If you're already treating your platform as something you GitOps rather than click-ops, the group-to-server mappings that drive EMA are exactly the kind of thing that should live in version control too, even if the IdP itself doesn't enforce that for you yet.
If you're new to MCP itself
We covered the protocol fundamentals in Demystifying Model Context Protocol, and the production security checklist (auth, per-tool scoping, audit logging) in MCP in the Real World — worth a read first if EMA is your entry point into MCP rather than the other way around.
What you get¶
One login connects every server a user is authorized for, which means no onboarding checklist per tool and no ticket queue for access requests. Security gets a single audit trail instead of scattered per-user consent records living wherever each person happened to click "allow." And for the first time, there's a real lever to enforce group- and role-based access to AI tooling the same way you already do for infrastructure, instead of trusting that everyone clicked the right thing.
FAQ¶
Does EMA replace OAuth for MCP servers entirely?
No. EMA is an extension on top of MCP's existing authorization model, not a replacement for it. Servers and clients that don't implement EMA keep working exactly as they do today, with per-user consent. EMA just gives IdP-managed organizations a faster path when both sides support it.
What if our identity provider isn't Okta?
Okta is the first supported IdP, but EMA itself is provider-agnostic — it's built on an open OAuth extension (ID-JAG), not an Okta-specific mechanism. Expect more identity providers to add support as adoption grows; check the EMA extension spec for the current list.
Do we have to migrate every server to EMA at once?
No. It's opt-in per server. You can run some servers under EMA and leave others on standard per-user consent indefinitely, which makes it realistic to start with your highest-friction internal servers and expand from there.
Does this work for MCP servers we built ourselves?
Yes, but you have to implement the extension on your authorization server yourself. The ext-auth repository has the draft specification and reference material for what a server needs to support.
That deploy-status server your new hire still hasn't gotten around to authorizing? In a few months, that whole category of problem might just not exist. One login, and they're in everywhere they're supposed to be — which is, honestly, what MCP access should have looked like from day one.