MCP Enterprise-Managed Authorization: What It Is, Why It Matters, and What Your Security Team Needs to Know

The Executive Summary (For the Non-Technical Reader)

If your organization uses Claude — Anthropic's AI assistant — and connects it to business tools like Atlassian, Figma, Slack, or Asana through MCP connectors, this announcement directly affects your security posture.

On June 18, 2026, the Model Context Protocol community declared the Enterprise-Managed Authorization (EMA) extension stable. Anthropic simultaneously launched it in beta for Claude Team and Enterprise plan customers, with Okta as the first supported identity provider.

Here is what this means in plain language: before EMA, every employee in your organization had to individually authorize every AI connector — one at a time, through separate OAuth consent screens. Your security team had no centralized way to govern, audit, or revoke that access. EMA eliminates that entire problem. IT administrators configure connector access once through Okta, and every employee inherits the right connectors automatically when they log in. When someone leaves the company or changes roles, access is revoked through the same identity lifecycle process that already governs the rest of your software stack.

For organizations running Claude at scale, this is the difference between ungoverned AI tool access and enterprise-grade identity governance.

Why This Matters: The Governance Gap EMA Closes

Expand

Standard MCP authorization vs Enterprise-Managed Authorization. Source: Model Context Protocol Blog.

The standard MCP authorization model was built for consumer scenarios where an individual decides what touches their data and completes an interactive OAuth 2.0 consent flow to confirm it. That model has three structural problems in enterprise environments.

First, every employee has to authorize every MCP server individually. Onboarding a new hire to a dozen AI-connected tools means a dozen separate OAuth redirects — each one a friction point and a support ticket waiting to happen.

Second, security teams cannot enforce consistent policy. Access is whatever each user happened to authorize. There is no centralized view of who can reach what through their AI assistant, and no audit trail to prove it. Every user's access_token grants are opaque to IT.

Third, work and personal accounts blur together. Without a mechanism to require a corporate identity, an employee can accidentally — or intentionally — connect a personal OAuth account to a work tool. Data flows between personal and enterprise contexts with no guardrails.

This combination of factors was widely identified as the single largest obstacle to enterprise-scale MCP adoption. Organizations that needed centralized governance were either blocking MCP deployment entirely or accepting risk they could not quantify.

How Enterprise-Managed Authorization Works

EMA makes the organization's identity provider (IdP) the authoritative decision-maker for MCP server access. The extension is registered under the identifier io.modelcontextprotocol/enterprise-managed-authorization. Here is how the flow works at each step.

Step 1 — Employee Authenticates via SSO

The user logs in to their MCP client (Claude, Claude Code, or Cowork) using their corporate SSO credentials through the enterprise IdP (Okta). The client receives and stores an ID Token — either an OpenID Connect ID Token or a SAML assertion — during this standard login flow.

Step 2 — Client Obtains an ID-JAG

The client exchanges the stored ID Token for a special-purpose token called an Identity Assertion JWT Authorization Grant, or ID-JAG. This is an IETF draft standard (draft-ietf-oauth-identity-assertion-authz-grant) co-developed by Okta and adopted by the OAuth working group in September 2025.

The IdP evaluates its internal policies — group membership, role assignments, conditional access rules — before issuing the ID-JAG. If the user is not authorized for a given MCP server, the IdP returns an error and the client never receives a token for that server.

Step 3 — Token Exchange with the MCP Authorization Server

The client sends the ID-JAG to the MCP server's authorization server using a standard OAuth 2.0 token exchange. The authorization server validates the ID-JAG by:

• Verifying the JWT signature against the IdP's JWKS endpoint
• Checking the aud (audience), iss (issuer), and exp (expiration) claims
• Mapping the IdP claims (sub, email, scope, resource information) to local permissions

If validation succeeds, the authorization server issues an MCP access_token scoped to the user's authorized resources.

Step 4 — Access Granted, No Consent Screen

The user is never redirected through a per-server consent screen. The MCP client uses the access_token to call the MCP resource server directly. Every approved connector is automatically available, scoped to the groups and roles the user already holds in Okta.

The Flow in Sequence

The full sequence diagram from the MCP Enterprise-Managed Authorization specification:

Key Properties of the Flow

Authorize once, inherit everywhere. Admins enable a server for the organization. Users get it automatically.

Centralized policy and audit. Access decisions live in the IdP admin console with one auditable trail across every connector.

No personal/enterprise mixups. By removing the interactive account selection step, data cannot flow between personal and enterprise accounts by mistake.

Implementation Details

Declaring EMA Support (MCP Clients)

For an MCP client to support EMA, it must declare the extension capability during the initialize handshake:

{
  "capabilities": {
    "extensions": {
      "io.modelcontextprotocol/enterprise-managed-authorization": {}
    }
  }
}

What MCP Servers Must Do

Servers that want to require enterprise-managed authorization need to:

Validate:
  - JWT signature    → against IdP JWKS endpoint
  - iss claim        → matches expected IdP issuer
  - aud claim        → matches the MCP server's resource identifier
  - exp claim        → token is not expired
  - sub claim        → identifies the user
  - email claim      → optional, used for account linking
  - scope claim      → defines authorized resource access

1. 1Declare the extension in their authorization server metadata, signaling to clients that the enterprise-managed flow is required (not optional).
2. 2Validate `ID-JAG` tokens — this means hitting the IdP's JWKS endpoint for signature verification and validating standard JWT claims (shown below).
3. 3Map `IdP` claims to permissions — the ID-JAG carries scope and resource claims that the server uses to determine what the user can access. This is where the server's own authorization logic kicks in.

What Authorization Servers Must Handle

The MCP authorization server sits between the client and the resource server. It must:

• Accept ID-JAG tokens as a valid OAuth 2.0 authorization grant type
• Validate the JWT against the IdP's published JWKS
• Issue scoped access_token values based on the claims in the ID-JAG
• Handle account linking — the sub claim always identifies the user, and the email claim (when present) can link the IdP identity to an existing account in the server's user store

Okta's Implementation: Cross App Access (XAA)

Okta's implementation of the ID-JAG standard is called Cross App Access, or XAA. The protocol timeline:

Okta's TypeScript and Java SDKs already include XAA support, which means developers working in those languages can implement the authentication standard with minimal additional integration work.

What Launched and Who Supports It

Identity Providers

Okta is the first supported identity provider. Organizations using Okta can provision MCP access through any supported client using XAA.

Important limitation: Microsoft Entra ID (Azure AD) and Google Workspace SSO are not yet supported. Anthropic has confirmed these are on the roadmap, but no release timeline has been published. If your organization runs on Entra ID, you are in a waiting room for now. The underlying ID-JAG standard is IdP-agnostic, so the technical path is straightforward — but the timeline is Anthropic's to set.

MCP Clients

Anthropic has implemented EMA across its shared MCP layer for Claude chat, Claude Code, and Cowork. Microsoft Visual Studio Code (version 1.123+) also supports EMA at launch — meaning organizations using VS Code as a development environment get the same zero-touch connector provisioning.

MCP Servers (7 at Launch + Slack In Progress)

HubSpot, Ramp, and Webflow are among organizations already rolling it out. Ramp reports that 2,000 employees are now provisioned through Okta with zero additional steps.

Because the specification is open, any MCP connector — including custom-built internal tools — can adopt EMA support independently.

The SiegePal Perspective: What Your Security Team Should Evaluate

At SiegePal, we assess enterprise security changes through the lens of what they actually solve, what they leave unaddressed, and what new attack surface they introduce. Here is our take on EMA.

What EMA Solves Well

Credential lifecycle management. EMA ties MCP connector access to the same IdP lifecycle that governs every other enterprise application. When you deactivate a user in Okta, their AI tool access_token grants revoke alongside their email, Slack, and everything else. No stale OAuth tokens left behind, no orphaned connector grants to discover during your next audit.

Audit trail consolidation. Every connector authorization decision now flows through your IdP's admin console. For organizations subject to SOC 2, HIPAA, or PCI-DSS compliance requirements, this is a significant improvement — you can demonstrate centralized access control over AI tool integrations using the same evidence collection workflow you already have.

Reduced onboarding friction without reduced security. The zero-touch experience is not a security compromise — it is a security improvement. Every connector that previously required an unmonitored individual OAuth flow is now provisioned under centralized policy. Faster onboarding and stronger governance are not in tension here; they are the same mechanism.

What EMA Does Not Address

Runtime agent behavior. EMA governs who can connect to what. It does not govern what an AI agent does once connected. Prompt injection attacks — where malicious content in a document or tool output manipulates an agent into misusing its legitimate access_token — remain an active area of concern. EMA ensures the agent has authorized access to Jira; it does not prevent a crafted Jira comment from tricking the agent into exfiltrating data to an unauthorized destination.

Supply chain risk from third-party `MCP` servers. EMA does not validate the security posture of the MCP servers themselves. A connector that passes EMA authentication can still have vulnerabilities, misconfigurations, or malicious behavior in its own codebase. Organizations should continue to evaluate MCP server providers the same way they evaluate any third-party SaaS integration.

Non-Okta identity providers. If your organization uses Entra ID or Google Workspace as your primary IdP, you cannot use EMA today.

What We Recommend

1. If you are an Okta shop running Claude at scale: evaluate the EMA beta now. The governance improvement is substantial and the integration leverages infrastructure you already manage.

2. If you are on `Entra ID` or `Google Workspace`: document EMA as a requirement for your Claude deployment roadmap and monitor Anthropic's announcements for IdP expansion timelines.

3. Regardless of `IdP`: do not treat EMA as a complete solution for AI tool security. Layer it with runtime monitoring, prompt injection defenses, and MCP server supply chain assessments. The Center for Internet Security published MCP security guidance in April 2026 that covers the runtime risk category EMA intentionally leaves out of scope.

4. For compliance teams: update your access control documentation to reflect how MCP connector provisioning works in your environment — whether that is the legacy per-user OAuth model or the new EMA-governed flow. Auditors will ask.

5. For developers building custom `MCP` servers: implement EMA support now. The ext-auth repository at github.com/modelcontextprotocol/ext-auth contains the specification and reference materials. Okta's TypeScript and Java SDKs include XAA support out of the box. Enterprise customers will increasingly expect EMA as a baseline.

The Bigger Picture: An Emerging Enterprise Standard

The collaboration behind EMA is worth noting. Anthropic, Microsoft, Okta, and seven MCP server providers shipped interoperable support for the same open authorization extension simultaneously. VS Code supports EMA at launch alongside Claude. The ID-JAG standard is an IETF draft, not a proprietary protocol.

This pattern has the characteristics of a de-facto enterprise standard emerging in real time. Enterprise IT teams evaluating AI deployments may increasingly ask which MCP servers support EMA before approving deployment — similar to how SSO support became a procurement requirement for SaaS applications over the past decade.

Okta's broader work extends beyond connector provisioning. Through their integration with Anthropic, Okta can now import Claude Managed Agents into their Universal Directory, enabling organizations to assign human owners and enforce centralized policies on AI agents themselves — not just the humans using them. Additionally, an integration between Okta Identity Security Posture Management and the Claude Compliance API gives security teams centralized visibility into identity risks, dormant accounts, and misconfigurations within Claude Enterprise.

For organizations planning their AI security architecture, EMA is the first credible answer to the question of how identity governance extends to AI agent connections. It will not be the last, but it is the one that shipped this week with production support from the vendors that matter.

Key Resources

MCP Blog Announcement: Enterprise-Managed Authorization: Zero-touch OAuth for MCP

Technical Specification: MCP Enterprise-Managed Authorization Extension

IETF Draft (`ID-JAG`): draft-ietf-oauth-identity-assertion-authz-grant

Okta `XAA`: okta.com/solutions/cross-app-access

Source Code & Reference Implementations: github.com/modelcontextprotocol/ext-auth

EMA Interest Group: modelcontextprotocol.io/community/interest-groups/enterprise-managed-authorization

About SiegePal

SiegePal LLC is a San Diego-based cybersecurity consultancy specializing in cloud security engineering, compliance advisory, and AI-era security architecture. We help organizations navigate the intersection of identity governance, cloud platforms, and emerging AI tool ecosystems. If your team is evaluating MCP security, AI agent governance, or enterprise identity posture — get in touch.

Disclaimer: SiegePal LLC is not affiliated with Anthropic, Okta, or any MCP server provider mentioned in this article. This analysis reflects our independent professional assessment based on publicly available information as of June 19, 2026.