MCP Gets Its Enterprise Authorization Layer — What the EMA Extension Means for Healthcare AI Governance

AI Security Series #44

On June 18, 2026, the Model Context Protocol project published a significant update: the Enterprise-Managed Authorization (EMA) extension is now stable. Anthropic, Microsoft, and Okta are among the first adopters. If your organization is running or planning MCP-connected agent deployments, this changes the governance picture in a concrete and useful way — and it surfaces a gap in the broader MCP security landscape that healthcare security teams should understand before they assume EMA solves everything.

The Problem EMA Solves

MCP's standard authorization model was built around individual users authenticating to individual servers — one OAuth prompt per server, per user, per connection. For general consumer use cases that model is fine. For enterprise deployments, it creates three compounding problems.

First, every employee has to authorize every MCP server individually. Onboarding means manually connecting service after service, with no central provisioning. Second, security teams have no way to enforce consistent policy across those connections — access is whatever each user happened to authorize, with no central control or audit trail. Third, there is no mechanism to require corporate identity. A user can connect a personal account to a work MCP tool with nothing stopping them, creating data boundary violations that are invisible to the security team until something goes wrong.

The cumulative effect, as the MCP project's own announcement acknowledges, is that most enterprise MCP servers end up effectively switched off because the per-user authorization overhead makes them impractical to operate at scale.

What EMA Does

Enterprise-Managed Authorization makes the organization's identity provider (IdP) the authoritative decision-maker for MCP server access. Administrators define access policy once — which servers are available to which users, based on group membership and existing roles — and users get those servers automatically connected on first login with no additional prompts.

The technical mechanism is an Identity Assertion JWT Authorization Grant (ID-JAG), obtained from the IdP during single sign-on and exchanged for an access token from the MCP server's authorization server. The user is never redirected through a per-server consent screen. Three security properties fall directly out of this flow:

Centralized policy enforcement: Access decisions live in the IdP admin console. Provisioning and deprovisioning happens in one place, consistently, across every connected MCP server.
Auditable trail: Every access decision flows through the IdP, creating a single audit log across all MCP connections rather than fragmented per-server records.
Corporate identity enforcement: By removing the interactive account selection step, EMA prevents users from accidentally or intentionally connecting personal accounts to enterprise MCP tools — a data boundary control that the previous model couldn't provide.

Who Is Implementing It

The launch brought together three tiers of the MCP ecosystem simultaneously, which matters for practical adoption timelines.

On the identity provider side, Okta is the first supported IdP, implementing EMA through its Cross App Access (XAA) protocol. Organizations already running Okta can begin provisioning MCP server access through their existing Okta admin console without standing up new infrastructure.

On the client side, Anthropic has implemented EMA across its shared MCP layer — meaning Claude, Claude Code, and Cowork all inherit the extension. Microsoft has added support in VS Code. For healthcare organizations that have standardized on either of these clients for their agent development workflows, EMA is available now without waiting for additional client updates.

On the server side, Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase launched with EMA support. Slack is actively adding support. The server list is narrower than the client list at this point — a gap worth tracking, since EMA's value is proportional to how many of your connected servers actually support it.

The AND Gate Problem

One of the most useful conceptual contributions in the broader MCP authorization conversation — surfaced at the April 2026 MCP Dev Summit — is what Arcade CEO Alex Salazar described as the AND gate requirement: every MCP request should be evaluated against the intersection of what the agent is authorized to do AND what the authenticated user is authorized to do, enforced on every call.

EMA addresses the user half of that AND gate well. By binding MCP server access to the user's existing IdP identity and roles, it ensures that what MCP servers a user can reach reflects their organizational access policy. What EMA does not address is the agent half — the question of what an individual agent is permitted to do within the scope of servers it can reach.

That second layer requires tool-level authorization: policy enforcement that evaluates not just whether a user-agent pair can reach a server, but whether this specific tool call, with these specific arguments, against this specific resource, is permitted given the current context. EMA is the foundation. Tool-level authorization is the next layer that enterprise MCP deployments will need to build.

For healthcare organizations specifically, the AND gate framing is directly relevant to HIPAA minimum necessary requirements. An agent operating on behalf of a clinical user should not be able to access any PHI the user could theoretically access — it should only access the PHI required for the specific task being performed. That distinction requires policy enforcement at the tool-call layer, not just at the server connection layer.

The Gap EMA Doesn't Close

EMA is a governance layer that sits on top of MCP's OAuth 2.1 foundation. That foundation has a significant adoption problem. As of May 2026, only 8.5% of MCP servers had implemented OAuth 2.1 authentication — despite it being the mandatory standard for remote deployments since the November 2025 spec revision. EMA does not help organizations that are connecting to servers that never implemented the underlying OAuth 2.1 requirement.

This matters for healthcare organizations evaluating third-party MCP servers for clinical workflow, EHR integration, or administrative tooling. Before EMA's governance properties are meaningful, the servers being governed need to be running compliant authorization foundations. Vendor MCP server security posture — specifically OAuth 2.1 compliance and scope implementation — should be on your AI vendor assessment checklist before deployment, not after.

The MCP authorization evolution over the past year also illustrates how quickly the spec has been moving: OAuth 2.1 as the foundation in March 2025, MCP servers formalized as OAuth Resource Servers with mandatory Resource Indicators in June 2025, Client ID Metadata Documents replacing Dynamic Client Registration in November 2025, and EMA going stable in June 2026. Organizations building MCP governance programs need to account for continued spec evolution — what you implement today may need to be revisited against a spec that looks materially different in six months.

What This Means for Healthcare

EMA Directly Addresses Healthcare's IAM Integration Problem

Healthcare organizations typically run mature, centralized identity infrastructure — Active Directory, Okta, Azure AD — with role-based access control tied to clinical and administrative functions. The previous MCP authorization model was incompatible with that infrastructure by design: it was user-scoped and interactive, with no path for centralized provisioning. EMA closes that gap. For healthcare organizations already running Okta, the path to centrally governed MCP deployments is now available without custom integration work.

The Audit Trail Is a Compliance Asset

HIPAA requires organizations to maintain audit controls that record and examine activity in systems that contain PHI. An MCP deployment where access decisions are centralized in the IdP and every connection is logged through a single audit trail is substantially more defensible in an OCR audit than one where access records are fragmented across individual user OAuth grants. EMA's centralized audit capability should be called out explicitly in your AI governance documentation as a HIPAA-relevant control.

Deprovisioning Is Now Reliable

One of the most overlooked risks in the previous MCP model was termination hygiene. When an employee left, their individual OAuth grants to MCP servers required manual revocation across every server they had connected — a process that was easy to miss and difficult to audit. With EMA, deprovisioning happens at the IdP layer. Revoke access in Okta and the user loses access to all EMA-connected MCP servers simultaneously, with no per-server cleanup required. For healthcare organizations managing contractor and vendor access to clinical systems, this is a material improvement in offboarding risk.

Personal/Enterprise Account Separation Matters More in Healthcare

The blurred personal/enterprise account problem that EMA addresses has specific consequences in healthcare that go beyond general data governance. A clinician who connects a personal Microsoft or Google account to an MCP server configured for clinical workflow creates a data boundary violation that may constitute impermissible PHI disclosure under HIPAA — regardless of intent. EMA's corporate identity enforcement makes this class of error structurally harder to commit.

Server Compliance Posture Is Now a Vendor Assessment Item

Healthcare organizations evaluating MCP-connected tools from EHR vendors, clinical AI providers, and administrative software vendors should now include MCP authorization compliance in their security assessments. Specifically: does the vendor's MCP server implement OAuth 2.1 with PKCE, Resource Indicators (RFC 8707), and EMA support? The answers determine whether your centralized governance controls actually extend to that server or stop at the perimeter of your own infrastructure.

The Bigger Picture

EMA's release marks a meaningful maturation point for MCP as an enterprise protocol. The original specification solved a real problem — giving AI agents a standardized way to connect to tools — but it was designed for individual developers and general consumer use cases. The authorization model reflected that origin. EMA is the first MCP extension that was designed explicitly for enterprise security requirements from the ground up: centralized governance, auditable access decisions, corporate identity enforcement, and IdP integration.

The deployment scale that enterprise MCP governance needs to support is significant. Healthcare systems building toward high agent density need governance infrastructure that scales with the deployment, not manual processes that worked with three agents and will fail with three hundred. EMA provides the provisioning and audit foundation that makes that scale governable.

EMA is not the complete answer. Tool-level authorization, server-side OAuth 2.1 compliance, and continued spec evolution all represent open work. But it is the right foundation piece, arriving at the right time, from the right layer of the stack. For healthcare security teams building MCP governance programs now, understanding what EMA provides — and what it doesn't — is the starting point for designing controls that will still be coherent when the deployment scales.

This is entry #44 in the AI Security Series. For related coverage, see AI Security Series #43: The Four Types of AI Agent Memory.