On June 18, 2026, the official Model Context Protocol blog announced that Enterprise-Managed Authorization (EMA) — marketed as “Zero-Touch OAuth for MCP” — is now a stable extension of the spec. The core change fits in one sentence: authorization decisions for MCP servers move from each individual user clicking “allow” to the organization’s identity provider (IdP). The moment an employee signs in via SSO, the MCP servers they are approved for connect automatically, with no parade of per-server consent screens.
For teams wiring AI agents into internal tools, this fixes the most boring yet most dangerous problem in the stack: on day one, every employee had to manually authorize every connector, while security teams could neither see who approved what nor revoke anything centrally.
How ID-JAG Works
The technical core is a new token format: the Identity Assertion JWT Authorization Grant (ID-JAG), which maps to the IETF draft draft-ietf-oauth-identity-assertion-authz-grant. During single sign-on, the IdP issues an ID-JAG to the client, and the client exchanges it for an access token from the MCP server’s authorization server — the user is never redirected through per-server consent pages. The mechanism builds on Okta’s Cross App Access (XAA) protocol, originated as spec proposal SEP-990, and is not MCP-specific: it can secure data sharing between any set of applications that share an SSO provider.
The administrative logic is “authorize once, inherit everywhere.” An admin defines policy once in the IdP — group membership, roles, conditional access rules — and from then on, who can reach which server, and when access is revoked, is decided in one place with a single auditable trail.
Three Pain Points It Solves
- Onboarding friction: every employee previously had to manually authorize every MCP server; with EMA, approved connectors live from the first login.
- No central control: the effective access surface was the sum of whatever each person had clicked “allow” on, invisible to audit and security. Policy now concentrates in the IdP with one trail to inspect.
- Account mixing: an employee could connect a personal account to a corporate tool and quietly exfiltrate enterprise data to a personal project-management workspace. Standard OAuth had no guard against this; EMA closes the path at the protocol layer.
The Security Debate: Zero Friction Cuts Both Ways
The most substantive criticism in the Hacker News thread comes from the prompt-injection angle: if a repository carrying injected instructions triggers tool calls, does removing friction make attacks easier? One commenter argued that a bank-type MCP server should at least prompt once at connection time. The rebuttal: controlling tool invocations is the client’s job, and MCP servers were always authenticated once per user, not once per conversation — EMA does not change that.
There are clear security wins too. Compared with Dynamic Client Registration (DCR), one commenter argued EMA is “vastly superior from a security perspective,” because attackers can no longer register their own clients — blunting confused-deputy and phishing patterns. The flagged gap is visibility: delegation happens at IdP policy level, so a user may never learn which applications were authorized to share their data.
Ecosystem Status and the Entra ID Gap
Adoption so far: Okta is the first supported IdP. On the client side, Anthropic implemented EMA in its shared MCP layer covering Claude, Claude Code, and Cowork, and VS Code supports it in the IDE. On the server side, Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase are live, with Slack and others in progress.
The biggest deployment pain point is Microsoft Entra ID. Many MCP clients assume DCR exists and will not accept a pre-registered client_id, while Entra ID does not support DCR — one developer ended up proxying the OAuth flow, lying to the client that DCR is available while injecting a hardcoded client_id. Anthropic’s maintainers say they are “in touch with the Microsoft Entra ID folks.” Meanwhile the OAuth working group is advancing task-level authorization and multi-hop delegation drafts, pointing toward proof-of-possession tokens whose scope narrows at each hop.
What It Means for Enterprise Agent Deployments
First, identity is the next battleground for agent security. When one agent calls dozens of internal APIs on an employee’s behalf, “who approved this, and on what basis” needs a protocol-level answer — EMA hands that answer to the IdP, in line with the broader shift toward centralized governance in enterprise agent tooling (see our earlier coverage of Vercel’s enterprise apps and agents push). Second, do not treat EMA as a complete defense: prompt injection and tool-abuse controls still live in the client and the agent framework. Zero-touch onboarding saves administration cost, not threat model. Third, plan for mixed-IdP reality: until Entra ID support lands natively, large organizations spanning identity platforms will need proxy-layer workarounds — and those improvisations are exactly the technical debt to repay at the next upgrade.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.