MCP EMA Stable — Fixes OAuth, Leaves Agent Trust Exposed

On June 18, the Model Context Protocol community shipped Enterprise-Managed Authorization as a stable extension. Paul Carleton, a core MCP maintainer, announced the release alongside simultaneous adoption by Anthropic, Microsoft, and Okta — with seven MCP server providers already supporting it. EMA replaces the per-user OAuth consent loop that made MCP unusable at any company with more than fifty employees. It is the biggest enterprise deployment blocker removed to date. And it leaves the security gap that actually matters completely untouched.

TL;DR

• What: MCP’s Enterprise-Managed Authorization (EMA) extension went stable — admins provision MCP connectors through their IdP, employees inherit access at login with zero consent screens
• Who: Okta (first IdP), Anthropic (Claude, Claude Code, Cowork), Microsoft (VS Code), plus seven MCP servers: Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase
• Gap: EMA governs who connects to what. It says nothing about what the agent does once connected — prompt injection, lateral movement, data exfiltration through legitimate tool calls are all out of scope
• Action: Ship EMA for access provisioning. Build your runtime governance layer separately — EMA is not it

What Happened

The old MCP authorization model was a per-user OAuth nightmare. Every employee had to manually consent into each MCP server individually — one at a time, no central audit trail, no reliable revocation path. When someone left the company, their OAuth grants sat there indefinitely unless someone remembered to hunt them down. At scale, this created a support ticket queue that IT teams learned to dread and a security posture that compliance officers learned to ignore.

EMA flips the model entirely. Admins configure MCP server access once in their identity provider — Okta is first, with its Cross App Access (XAA) implementation — and employees inherit every approved connector automatically on first login. A new hire walking in on day one gets Figma, Atlassian, Asana, Linear, Canva, Granola, and Supabase connectors without touching a single consent screen. When that employee is offboarded, access expires within the token’s TTL rather than persisting on a forgotten grant.

The underlying standard is ID-JAG — Identity-Delegated Authorization for Agents — adopted by the IETF OAuth working group in September 2025 and incorporated into the MCP spec two months later. Because the spec is open, any custom-built MCP connector can implement EMA without going through Anthropic or Okta. Okta’s TypeScript and Java SDKs already include XAA support, and the implementation path for MCP server authors is straightforward: declare the EMA extension in your authorization metadata, validate incoming ID-JAG JWTs against the IdP’s JWKS endpoint, map IdP claims to your permission model. Teams using any of the seven supported providers can ship this with minimal custom integration.

On the client side, Anthropic supports EMA across Claude, Claude Code, and Cowork. Microsoft added EMA support to Visual Studio Code simultaneously. Slack is in progress. The launch coalition is broad enough that most enterprise teams using MCP already have at least one supported server in their stack.

MCP governance transferred to the Agentic AI Foundation, a Linux Foundation-hosted project, in December 2025 — with OpenAI and Block as co-founders and AWS, Google, Microsoft, Cloudflare, and Bloomberg as members. EMA shipping as a stable extension under this governance structure carries more institutional weight than a typical protocol update from a single vendor.

Why This Matters

EMA solves the IT helpdesk problem, and that problem was real. I have talked to platform teams that spent more time managing MCP OAuth tickets than building integrations. The per-user consent model was designed for a world where one person connects one app — not a world where an AI agent needs simultaneous access to seven services on behalf of three hundred employees. Zero-touch provisioning through the IdP is obvious in retrospect, and credit to the MCP team for getting the standard right rather than shipping a proprietary shortcut.

But here is where I keep getting stuck: EMA governs who can connect to what. It does not govern what the agent does once it is connected. The spec’s own documentation acknowledges this directly, and I think enterprise teams are going to underestimate how large that gap is.

Consider the attack surfaces EMA explicitly does not address. A prompt injection attack that manipulates a legitimately authorized agent into calling tools it was never supposed to invoke — EMA has no opinion on that. A malicious third-party MCP server that exfiltrates data through valid tool calls — EMA provisioned the connection, so the traffic looks authorized. An agent using a Figma connector to read design files and then passing that content to a Linear connector to write it into a public project — EMA sees two legitimate connections, not lateral data movement.

EMA validates identity and authorization at the connection layer. It does not enforce tool-level permission scopes, audit agent actions at runtime, or detect anomalous behavior patterns. If your threat model includes agents acting outside their intended scope — and it should — EMA is not your control plane.

These are not theoretical concerns. CIS published companion guides for MCP security on April 20, 2026, specifically because the authorization layer and the governance layer are different problems requiring different solutions. Microsoft shipped a .NET governance package for MCP servers in May 2026 that adds startup tool scanning, runtime policy enforcement, and response sanitization — three capabilities that sit entirely outside EMA’s scope. Databricks built Unity Catalog integration for MCP governance for the same reason. The ecosystem is telling you something: access provisioning is step one, not the whole staircase.

The comparison that clarifies the gap is traditional SSO versus application-level permissions. Your IdP tells Jira that an employee is authorized to use the platform. It does not tell Jira which projects that employee can edit, which workflows they can trigger, or which data they can export. EMA is SSO for MCP. The application-level permissions — what the agent is allowed to do once connected — remain your problem to implement, monitor, and enforce.

The Take

EMA is genuinely good infrastructure solving a genuinely painful problem. The per-user consent model was blocking enterprise MCP adoption, and now it is gone. Every platform team running MCP connectors should ship EMA this quarter. The provisioning story alone — zero consent screens, centralized revocation, short-lived tokens enforced by the IdP — saves enough operational pain to justify the integration work.

But I worry about what happens when procurement teams see “enterprise authorization” and check the security box. EMA is table stakes for access provisioning. It is not a security posture. The runtime governance layer — tool-level permissions, agent action auditing, anomaly detection on MCP traffic, supply chain validation for third-party servers — is still your problem to build. The ecosystem is shipping pieces of that stack (Microsoft’s governance package, Databricks’ Unity Catalog integration, the CIS guides), but nobody has assembled the full picture yet.

If you are an enterprise team shipping EMA this week: great, you solved the easy problem. Now fund the hard one. Your agent has a valid JWT and seven connectors. What is it actually doing with them?