Dora NodaAn employee connects Claude to their company's MCP servers for the first time. No consent screen for Figma. No consent screen for Linear. No consent screen for Atlassian, Supabase, or the other half-dozen tools IT already approved. They log in once and every server they're allowed to reach is just — there.
That's Enterprise-Managed Authorization (EMA), the Model Context Protocol extension that went stable on June 18, 2026. It's a real fix for a real problem: per-server OAuth consent sprawl that made onboarding an AI agent into a company's tool stack feel like manually re-authorizing a dozen SaaS accounts one browser redirect at a time.
But here's the part worth landing before anything else: EMA answers can this user connect this client to this server, and with which scopes — a decision made once, at token issuance. It says nothing about whether this specific tool call, right now, in this context should go through. If your MCP server exposes a deploy tool and a destroy tool, EMA gets an agent connected to that server on the employee's first login. It has no opinion on whether the agent should be allowed to run destroy against production at 2 a.m. because a prompt told it to. That gap is exactly what a deploy-from-chat platform's own MCP server still has to close — and it's the reason this piece exists.
The problem EMA actually solves
Before EMA, MCP's authorization model was entirely user-driven, which is the right default for a consumer app deciding what accesses your personal calendar — and a genuine liability at company scale. A new hire who needs an AI agent wired into Figma, Linear, Atlassian, and Supabase had to authorize each one individually, clicking through four separate OAuth consent screens, each one a decision the user themselves was often unqualified to make ("should this agent see all of Linear, or just my team's project?").
Multiply that by every employee and every approved MCP server, and you get the failure mode the MCP team called out directly in their announcement: security teams can't enforce a consistent policy when access is whatever each user happened to click "Allow" on, with no central audit trail and no way to revoke it in one place. Offboarding an employee meant hunting down and revoking access server by server — assuming anyone remembered which servers that person had connected in the first place.
EMA moves the decision to where enterprises already manage every other application: the identity provider. IT configures once, in Okta or Azure AD or whichever IdP already gates Slack and email access, which MCP servers a given role or group can reach. Employees authenticate with the same corporate SSO they already use, and approved servers just appear — no per-app consent, no manual authorization queue, no orphaned grants after someone leaves.
How the ID-JAG flow actually works
The mechanism is called ID-JAG — Identity Assertion JWT Authorization Grant — and it was adopted as an IETF OAuth Working Group draft in September 2025 before being folded into the MCP specification that November. Under the hood it composes two existing OAuth standards rather than inventing new cryptography: RFC 8693 token exchange and RFC 7523 JWT bearer grants. Here's the actual sequence, per the published spec:
- The MCP client redirects the user to the enterprise IdP. The user logs in with their normal corporate credentials — nothing new yet.
- The IdP returns an authorization code, which the client exchanges for a standard OIDC ID Token. At this point the user is authenticated to the MCP client, same as logging into any SSO-backed app.
- The client exchanges that ID Token for an ID-JAG. This is the new step: the client asks the IdP, specifically, for a token scoped to a particular MCP server. The IdP evaluates policy right here — group membership, role, conditional access rules — and either issues the ID-JAG or refuses.
- The client exchanges the ID-JAG for an MCP access token at the MCP server's own Authorization Server. The Authorization Server validates the ID-JAG's signature against the IdP's JWKS endpoint, checks audience and issuer, and mints a scoped access token.
- The client calls the MCP Resource Server with that access token, same as any bearer-token API call, in a loop for the rest of the session.
The important design choice is in step 3: the client never gets redirected to the MCP server's own authorization endpoint at all. There's no per-server consent screen to skip, because there was never a per-server prompt to begin with — the IdP made the call before the client ever spoke to the MCP server's Authorization Server. And because the ID-JAG is signed with the same key the IdP already uses for ordinary SSO tokens, any MCP server that trusts that IdP can validate it without additional setup on the server's side.
Who's actually shipping it — and the caveat that matters
As of the June 2026 stable release, adoption spans both sides of the connection. On the client side: Anthropic's Claude apps and VS Code. On the server side: Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase, with Slack support in progress.
The caveat that belongs next to every one of those adoption numbers: Okta is the only identity provider shipping support at launch. If your organization runs Azure AD, Ping, or a homegrown SSO stack, "ends per-server OAuth consent hell" is a claim about where the ecosystem is heading, not something you can turn on this quarter. EMA's spec is IdP-agnostic by design — any IdP that can issue an ID-JAG and expose a JWKS endpoint qualifies — but a spec being IdP-agnostic and an IdP actually shipping the flow are different facts, and today only one of the major players has done the latter.
The boundary EMA doesn't cross
Here's the scenario that makes the connection/action distinction concrete instead of abstract. Say a release agent holds a valid, EMA-issued access token scoped to write on your deploy MCP server — legitimately, because IT approved that agent for that scope. Mid-run, the agent decides (because a prompt told it to, or because it misread a dependency) to delete a branch it shouldn't touch, or to act against a repository outside the one task it was given.
Nothing in EMA stops that. The token is valid. The scope was granted. ID-JAG scopes are a ceiling applied once, at issuance — not a check that re-runs for every individual tool call. The IdP's visibility, by the spec's own description, doesn't extend to the actual MCP traffic between client and server once the token is in hand.
What closes that gap is a layer EMA was never designed to provide: a policy decision point (an engine that evaluates "should this specific call happen, given this context") paired with a policy enforcement point sitting inline on the actual call path, in front of every tool invocation. That's a separate build — Rego-style policy rules, an approval-required flag on destructive actions, a signable audit event per call — layered on top of, not replacing, whatever EMA already handles at connection time.
What this means for a deploy-from-chat MCP server
If your platform exposes deploy, rollback, and destroy as MCP tools — which is exactly the shape of an AI-agent-as-operator PaaS — EMA and your own server split the work along a clean line:
| EMA's job | Your job | |
|---|---|---|
| Connection | Decide which employees/agents can reach your MCP server at all, via IdP policy | — |
| Onboarding/offboarding | Zero-touch first-login access; instant revocation at the IdP | — |
| Coarse scope | Issue a token scoped to e.g. "this tenant, write access" | — |
| Per-call authorization | — | Confirm-before-destroy gating on every destroy/rollback call, regardless of token scope |
| Context-aware policy | — | Block/allow decisions based on what is being deployed, when, and by which agent — not just whether the token is valid |
| Audit trail | Connection-level: who authenticated, when, to which server | Action-level: which tool call, with what arguments, approved by whom, at what timestamp |
| Account linking | ID-JAG carries a subject claim (stable identifier) and optionally email — use subject as primary, email as fallback for pre-existing accounts | Map that subject to your own tenant/user record |
Adopting EMA (declaring the extension, wiring your Authorization Server to validate ID-JAGs) buys the left column for free the moment your users are on an IdP that supports the flow. It buys none of the right column. A platform that ships deploy/rollback/destroy as MCP tools and stops at EMA has solved the onboarding problem and left the actual blast-radius problem — an agent with a valid token doing the wrong thing — exactly where it was.
MCP's enterprise story finally has a real answer for who gets in the door. The harder question — should this specific action, right now, actually happen — was never EMA's to answer, and it's the one a self-hosted, agent-operated platform can't outsource to an identity provider it doesn't control.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with deploy/rollback exposed as MCP tools an agent can call directly. Confirm-before-destroy and per-action audit trails are things the platform itself has to own, not the identity provider fronting it. Star the repo on GitHub or deploy your first app today.