When the Model Context Protocol project declared its Enterprise-Managed Authorization extension stable on June 18, 2026, the launch already looked like a coalition: Anthropic and Microsoft had client support ready, Okta stood up the identity provider side, and a first wave of apps from Figma and Linear to Atlassian and Supabase turned it on. The promise is that you sign in once with your corporate identity and your approved MCP servers are simply there, and having wired the flow together by hand, I understand the enthusiasm.
The best description I know for what shipped is a building badge, the kind that opens the lab, the garage, and the supply room without any of those doors interrogating you, because facilities already decided which doors you get. EMA, and the Cross-App Access pattern (XAA) underneath it, turns your identity provider into facilities for MCP, and inside one building that is a genuinely good design. What follows is about why it stops at the curb, where the spec shipped complete while the playbook never did, and why the shortest explanation lives in the four words every spec is written in: MUST, SHOULD, RECOMMENDED, OPTIONAL.
The floor is seven claims
The flow itself takes one sentence to describe: you sign into your MCP client through the company identity provider, the client quietly asks that provider for a special grant, and it trades the grant with the tool’s own authorization server for an access token, with no consent screen appearing anywhere along the way. That grant is a signed token called an ID-JAG, defined in an OAuth draft that EMA packages for MCP, and if you want to watch one get issued and honored live, Okta runs an open sandbox at xaa.dev.
Reading that draft the way you would read a contract changes how the whole thing looks, because the grant guarantees exactly seven things: who issued it, who it is about, which authorization server may accept it, which client is acting, plus an id and two timestamps to keep it fresh. That is the MUST tier, and while it is enough to validate a token, everything a product needs to recognize a human sits below it, where the user’s email is merely RECOMMENDED and the scopes, the delegation actor, and the claim that maps the user onto your own records are all OPTIONAL.
What that means in practice is that the one thing an issuer owes you about Ana is an opaque string like u_8f24c1, while her email address, the one line your onboarding code actually wants, is precisely the line the protocol does not owe you.
Inside an enterprise none of that optionality hurts, because optional really means configurable there: an admin who controls both ends of the connection can make every SHOULD behave like a MUST by assigning the claims, syncing the directory, and testing the pair, so bilateral configuration fills every gap the spec leaves open. That is exactly what the spec expects, since it only ever promises to work where a single sign-on relationship already exists.
Out in the open world the same optionality compounds against you: a server accepting grants from issuers it has never met can only build on what every issuer is required to send, and what every issuer is required to send is the opaque string. One provider includes the email, another includes a mapping hint, a third sends the bare subject, and all three are conformant.
My own testing made this concrete: I requested the email scope, the grant faithfully recorded that email had been asked for, and the address itself never arrived, because a recommendation is exactly the thing an implementation may skip. What you are left with is a token that validates perfectly while giving you nothing to provision from, map to a workspace, meter, or bill, which is the whole argument in miniature: the optionality that reads as flexibility in a bilateral deployment hands you the bare floor of the spec in an open one, and the floor is a very hard place to build a product.
Trust was the input
Beyond the claims, the enterprise supplies something even more fundamental, which is the trust itself. The draft is explicit that everything runs through an identity provider the tool’s authorization server already trusts for single sign-on, meaning the keys, the client registration, and the subject mapping were all put in place during SSO onboarding, by an admin, usually under a contract. Cross-App Access converts existing trust into access, and it never promised to do anything more than that.
Cross the street, though, and every pre-arranged answer becomes a live question, because an MCP server on the public internet receiving a grant from an issuer it has never heard of has to decide whether to accept assertions from that tenant at all, which tenants out of millions deserve that standing, and who carries the liability when one of them turns out to be wrong. The OAuth assertion framework has deliberately refused to answer any of this since 2015, leaving how a server comes to trust an issuer out of scope, and the new grant inherits that silence on purpose.
It would be easy to call all of that unsolved, and it would also be wrong, because the machinery for trust between strangers exists: OpenID Federation was finalized this year, national identity systems already run on it, and academic federations have connected thousands of parties for over a decade on the previous generation of the same idea.
What does not exist is an operator, some federation authority for MCP that admits issuers, publishes trust anchors, and absorbs liability when an assertion goes wrong, and every federation that has ever worked has been exactly that kind of governance artifact with a protocol attached. To call this an unsolved protocol problem flatters us engineers, when the missing piece is an unstaffed institution.
Between the building and the street sits a middle seat, the gateway, and it is the one I have been occupying for the past few weeks. A gateway can validate the grant and mint a token for its own proxy, and the flow genuinely works end to end, right up until one hop later, when the tool behind the proxy turns out to be another SaaS product with its own trust anchor and its own idea of who Ana is, none of which the grant can reach. Because the protocol moves a signed assertion across exactly one boundary, you can end up holding a perfectly valid token with nowhere downstream to spend it.
The coupling is conserved
Even if you never leave the building, seams remain, because the grant governs the connection and little else, and because the relationship between the tool’s authorization server and the identity provider never goes away. After weeks of operating one of those authorization servers, my conclusion is that the coupling is conserved, in the sense that you get to choose its channel and that is all you get to choose.
If you sync accounts ahead of time through SCIM, the coupling lives in a provisioning pipeline. Skipping the sync only relocates it, so it resurfaces as a runtime call to the provider’s user APIs the moment an unfamiliar subject shows up, and when you try to escape both by shaping richer claims through the provider’s own configuration surface, the coupling migrates into claim editors and product tiers, which is also where an open standard starts quietly reinforcing identity provider lock-in.
Nobody has written the playbook for any of this yet, and the official guidance only settles the first decision, which is to key users on the issuer and subject pair, before going quiet on deprovisioning, on which claims survive which product tiers, and on what happens the day the company migrates providers and every issuer value in your database goes stale. For now those questions live in operator discipline and vendor docs, which is a polite way of saying they live in you.
One last boundary deserves naming before the agents question, because the identity provider’s authority ends at issuance: it decides who may connect and at most which coarse scopes ride on the token, and since it never sees the MCP traffic that follows, whether a specific tool call should run on a specific resource remains a runtime question for a different layer entirely.
Agents, briefly
Everything above assumes the subject is a person, and the grant’s subject is exactly that, a signed-in user with room to note an actor working on their behalf. Autonomous agents running with no live user session have no identity assertion to exchange, and that gap deserves naming without blame, because giving agents identities of their own was never XAA’s purpose, and part of what makes the spec good is how disciplined it stays inside the problem it actually picked.
The proposals circling the autonomous side remain individual submissions with no formal standing, and most of the credible ones consolidate, treating agents as workloads inside the identity systems we already have. The exception worth watching is AAuth, an exploratory protocol built on the premise that agents deserve primitives of their own, with a cryptographic identity per agent and signed requests in place of bearer tokens, and it may end up answering the very questions this post leaves open. Those primitives sound familiar, because they are the ones I have already argued for: the plumbing and the primitives stay the same for agents, identities of their own with the human recorded in the delegation chain, and how any particular protocol implements them is mostly cosmetics, which is a case worth making properly in another post.
What I would do
If you run enterprise MCP, experiment before you commit, in the spirit of don’t trust, verify: the sandbox costs an afternoon and tells you what your identity provider actually sends, which is worth more than anything a launch post promises. Key users on the issuer and subject pair, treat email as a linking hint at most, since as a primary key it turns an address change at the provider into an account takeover at your server, and settle the provisioning and offboarding stories before the first grant arrives, because a revoked directory entry and an unexpired refresh token are perfectly capable of disagreeing.
In the open world, admit that your trust is pinned: an explicit allowlist of issuers is a respectable design, and when you outgrow it, study OpenID Federation before inventing an onboarding API of your own.
And ship it like the young protocol it is, behind guided setup and documented failure modes, with field reports filed upstream, because the grant reads the way it does thanks to implementers who built things and complained with specifics.
The badge works because somebody runs the building, and that is where XAA shines, with an admin on hand to turn every SHOULD into a MUST. Across the street there is no admin and no playbook, only the floor of the spec, and the institution that would raise it is still hiring.