Enterprise-Managed Authorization for MCP Explained
Enterprise-Managed Authorization (EMA) is an MCP extension that moves the authorization decision for every connected MCP server out of that server and into the organisation’s identity provider. Instead of each server running its own consent screen and access rules, the IdP issues a short-lived Identity Assertion JWT (ID-JAG) that proves a user’s access was already checked against group membership, role and conditional-access policy centrally, once.
What Is Enterprise-Managed Authorization for MCP?
Enterprise-Managed Authorization is the MCP extension that makes an enterprise’s identity provider the single authority for deciding who can reach which MCP server, replacing per-server consent with one centrally enforced policy.
Before EMA, every MCP server that supported OAuth ran its own authorization server, its own consent screen, and effectively its own opinion about what a given user was allowed to do. That works for a single tool. It breaks down the moment an organisation connects dozens of MCP servers to an agent host, because IT and security teams end up with no single place to see who has access to what, no single place to revoke it, and no consistent policy about which groups can reach which tools. The Model Context Protocol blog describes EMA as closing exactly this gap: administrators define policy once, in the IdP they already run, and every MCP server honours it without a bespoke consent flow of its own.
Anthropic, Microsoft, Okta and a growing list of MCP servers have adopted the extension as it has moved toward stability, according to The New Stack’s coverage of the rollout. That adoption pattern matters for an architect scoping a project today: EMA is no longer a proposal to track, it is infrastructure to plan around.
Why Can’t Individual MCP Servers Make Their Own Authorization Decisions?
Individual MCP servers can’t be trusted to make organisation-wide authorization decisions because none of them has visibility into the full picture: which groups a user belongs to, what conditional-access rules apply, or what happened when that user’s role changed yesterday.
Per-server authorization was never designed as an enterprise control plane; it was designed to let one client talk to one resource server under OAuth 2.1. Stack it across twenty or thirty MCP servers inside one company and you get twenty or thirty independent policy engines, each with its own idea of what “authorized” means, none of them synchronised with the identity system that actually tracks joiners, movers and leavers. When someone leaves the business, deprovisioning means finding and revoking access at every server individually, and missing even one leaves a live credential nobody remembers granting.
This is the specific failure mode EMA closes. By moving the decision to the IdP, revocation, role changes and conditional-access policy apply everywhere at once, because there is only one place the decision gets made. An AI architect evaluating MCP at scale should treat “how many independent authorization decisions exist in this design” as a concrete metric, not an abstraction: fewer is better, and EMA is the mechanism for getting to one.
How Does the ID-JAG Flow Actually Work?
The ID-JAG flow works by having the client exchange a standard SSO identity token for a short-lived, policy-checked assertion before it ever talks to the MCP server’s own authorization server.
Based on the MCP extension’s stable specification and implementation write-ups from Atlassian and PostHog, the sequence runs in four steps:
- Standard SSO login. The MCP client sends the user’s browser to the enterprise IdP for a normal login, then exchanges the resulting authorization code for an OpenID Connect ID Token.
- ID-JAG request. The client exchanges that ID Token for an Identity Assertion JWT Authorization Grant via an RFC 8693 token-exchange request. The IdP evaluates policy here, checking group membership, role and conditional-access rules before issuing anything.
- Token exchange at the MCP server. The client presents the ID-JAG to the MCP server’s own authorization server, which validates it and issues a normal MCP access token.
- Ordinary tool calls. Every subsequent tool call carries that access token in the Authorization header, exactly like any other OAuth-protected MCP server.
The architectural payoff is in step 2: policy is evaluated once, centrally, before the user ever sees a per-server consent screen. Revoke the ID Token or change the user’s group membership at the IdP, and every downstream MCP server inherits that change automatically, because none of them stored an independent decision to begin with.
How Does EMA Compare to Standard OAuth 2.1 Consent for MCP?
| Dimension | Standard per-server OAuth 2.1 | Enterprise-Managed Authorization |
|---|---|---|
| Where the decision is made | Each MCP server’s own authorization server | The organisation’s IdP, once |
| User experience | A separate consent screen per server | Single sign-on, no per-server consent prompt |
| Policy source | Whatever the server implements | Group membership, role, conditional access, set centrally |
| Revocation | Must be repeated at every server individually | One change at the IdP applies everywhere |
| Audit trail | Fragmented across servers | Centralised at the IdP |
| Deprovisioning on offboarding | Manual, per server, easy to miss one | Automatic once the IdP account is disabled |
This is the table an architect should put in front of a security or platform team when the question is “why add this extension layer at all”: every row is a governance gap that exists under plain OAuth 2.1 and closes under EMA.
What Must an AI Architect Build Before Adopting EMA?
An AI architect needs three things in place before EMA delivers its promised control: a governed gateway in front of MCP traffic, per-agent tool allowlists, and immutable audit logging, because EMA solves who is allowed to connect, not what a connected agent is then allowed to do.
EMA answers the identity question well but deliberately leaves tool-level policy to the deployment. A gateway pattern is how architects close that remaining gap: a single MCP gateway can filter list_tools responses so an agent only sees the tools its policy permits, enforcing least privilege at the tool level rather than the connection level. Aptible’s analysis of what it calls “beyond EMA” makes the same point: agent permissions, tool-level access control and audit logs are a separate layer that EMA does not itself provide.
Non-human identity governance is the piece architects most often skip. An agent acting under a delegated identity is, from a security programme’s perspective, a privileged account: it needs a registered owner, a defined permission scope, and a lifecycle that includes deprovisioning when the workflow it serves is retired. Without that registration, an agent is what one governance writeup calls invisible to the enterprise security programme: broader access than the person it represents, no deprovisioning trigger, and no attributable record of what it did in anyone’s name. Diagnosing which agents exist, who owns them and what they can currently reach is exactly the kind of mapping work that has to happen before a business commits budget to any EMA rollout, not after.
Who Is Adopting Enterprise-Managed Authorization Today?
Adoption is concentrated among the vendors that sit closest to enterprise identity and the largest MCP server operators, because they carry the most exposure if per-server authorization sprawl goes unmanaged.
Atlassian has shipped EMA support for Rovo MCP using its own XAA (cross-app authorization) implementation alongside ID-JAG. Okta, as a traditional identity provider, and Microsoft are both named participants in the extension’s development, alongside Anthropic on the model-vendor side. That combination, an identity provider, a model vendor and an enterprise software vendor all implementing the same extension, is a signal an architect can use directly when scoping a client’s MCP rollout: this is heading toward a default expectation for any MCP server sold into the enterprise, not an optional hardening step.
FAQ
Does Enterprise-Managed Authorization replace OAuth 2.1 for MCP? No. EMA is built on top of OAuth 2.1 and RFC 8693 token exchange; it adds a centralised policy step before the existing MCP OAuth flow, rather than replacing that flow.
Does adopting EMA remove the need for a tool-level allowlist? No. EMA controls who can reach an MCP server at all. Which tools a connected agent can then call is a separate policy layer, typically enforced by a gateway sitting in front of the MCP traffic.
Which identity providers support EMA today? Okta and Microsoft are both named participants in the extension’s development, and MCP servers including Atlassian’s Rovo MCP have shipped support using ID-JAG-based flows.
What is an ID-JAG? An Identity Assertion JWT Authorization Grant: a short-lived token an enterprise IdP issues after validating a user’s SSO identity against org policy, which the MCP client then exchanges for a normal MCP access token.
Do architects still need to worry about deprovisioning under EMA? Deprovisioning gets far simpler under EMA because disabling a user at the IdP removes their access everywhere at once, but architects still need to register agent identities separately, since an agent’s delegated access can outlive the workflow it was built for if nobody owns that lifecycle.
Bedrock AI maps your systems, team and workflows to show where AI actually pays, before you spend a pound building. Book a strategy call.