Claude AI Enterprise MCP Auth: Zero-Touch Setup With Okta

Introduction

If you manage Claude deployments across a team or enterprise, you have almost certainly felt the pain of MCP connector onboarding. Every employee, every connector, every OAuth consent screen — multiplied across an entire workforce. On June 18, 2026, Anthropic shipped a feature that eliminates this friction entirely: Enterprise-Managed Authorization (EMA) for MCP connectors.

EMA lets IT administrators provision MCP connector access once through their identity provider — starting with Okta — and push that access automatically to every employee on first login. No individual OAuth flows. No support tickets. No stale credentials when someone leaves. This is arguably the most significant enterprise feature Anthropic has released since launching the Model Context Protocol itself.

In this article, we will break down exactly what EMA does, how it works under the hood, which connectors support it at launch, and what it means for organizations running Claude at scale.

Why MCP Authorization Was Broken for Enterprises

The Model Context Protocol transformed how Claude connects to external tools. MCP connectors for services like Figma, Atlassian, Linear, and Asana gave Claude the ability to read and write data across an organization’s entire software stack. But the authorization model that shipped with MCP was designed for individuals, not enterprises.

The standard MCP auth flow works like any consumer OAuth setup. A user clicks "Connect," gets redirected to the service’s login page, authorizes access, and returns to Claude with a token. Simple enough for a single developer connecting their personal Figma account. Completely unworkable for an organization with 500 employees and a dozen MCP connectors.

The problems compound quickly. Every employee must individually authorize every connector. Security teams have no centralized visibility into which connectors are active, which tokens are live, or what data each agent can reach. There is no way to enforce that employees connect with their corporate identity rather than a personal account. When someone leaves the company, there is no reliable revocation path — their personal OAuth grants persist independently of the organization’s offboarding process.

Okta engineers working on the underlying protocol described the pre-EMA situation bluntly: giving an AI agent access through per-user OAuth effectively hands a nondeterministic entity the keys to the kingdom, with no central visibility into what it can reach or what it has already touched. For security-conscious organizations, this was a deployment blocker.

The MCP community identified per-user authentication as the single largest obstacle to enterprise-scale MCP adoption. EMA is the direct response.

What Enterprise-Managed Authorization Actually Does

At its core, EMA changes who makes the authorization decision. Instead of each employee individually deciding which MCP connectors to authorize, the organization’s identity provider becomes the single source of truth for MCP access.

Here is the practical experience for an end user: you log into Claude (or Claude Code, or Cowork) with your corporate SSO credentials. Every MCP connector that your IT administrator has approved for your role or team is immediately available. You do not see an OAuth consent screen for Figma. You do not manually connect Linear. You do not authorize Atlassian. Everything is simply there, ready to use, from your very first login.

For IT administrators, the workflow is equally clean. You configure which MCP connectors are approved for your organization in your Okta admin console. You assign access based on groups, roles, or conditional access rules — the same mechanisms you already use for every other enterprise application. When a new employee joins and gets added to the appropriate Okta groups, they inherit MCP connector access automatically. When someone leaves or changes roles, connector access is revoked through the same IdP lifecycle process that governs everything else in your stack.

Tom Moor, head of engineering at Linear, captured the user-facing impact: "Logging in once and automatically having all your MCP connectors automatically set up is pretty magical."

How It Works Under the Hood

EMA is built on a specific OAuth 2.0 extension called the Identity Assertion JWT Authorization Grant, known as ID-JAG. This is an IETF draft co-developed by Okta and others, and it represents a significant evolution in how identity propagates across interconnected services.

The flow works in three steps. First, when an employee logs into Claude through SSO, the MCP client obtains a signed ID-JAG JWT from the identity provider during the standard single sign-on session. This JWT is cryptographically signed using the identity provider’s existing private key — the same key that signs all other identity tokens in the organization.

Second, that signed JWT is exchanged for an access token from each MCP server’s authorization server. The key innovation here is that the user is never redirected through a per-server consent screen. The trust chain flows from the IdP’s signature through the JWT to the MCP server, establishing authorization without interactive consent.

Third, the MCP server validates the JWT signature, checks that the user belongs to an authorized organization and has the appropriate role or group membership, and issues an access token scoped to the user’s permissions. Token lifetimes can be shortened without degrading the user experience because the IdP reissues tokens silently during normal login sessions.

Okta’s implementation of ID-JAG is called Cross App Access (XAA). The protocol was adopted by the IETF OAuth working group in September 2025, incorporated into the MCP specification in November 2025, and declared stable as a formal MCP authorization extension on June 18, 2026. Anthropic’s EMA is the first live production implementation of that stable extension.

Because the specification is open, any MCP connector — including custom-built internal tools — can adopt EMA support without going through Anthropic. Okta’s TypeScript and Java SDKs already include XAA support, which means developers can implement the standard with minimal additional work.

Which Connectors Support EMA at Launch

Seven MCP providers support Enterprise-Managed Authorization at launch: Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase. These cover a significant portion of the tools that enterprise teams use daily — project management, design, development databases, and collaboration.

Slack support is actively in progress and expected soon. Given that Slack is one of the most heavily used MCP connectors for Claude, this addition will be significant for many organizations.

EMA works across all three Claude surfaces: Claude chat, Claude Code, and Cowork. This means a developer using Claude Code in their terminal gets the same zero-touch connector access as a product manager using Claude chat in the browser or a team lead using Cowork for desktop automation.

Administrators can also enforce a critical security constraint: requiring that a connector only ever authenticates through the organization’s IdP. This prevents an employee from accidentally connecting a personal account to a work tool, keeping corporate and personal data cleanly separated — a concern that has plagued enterprise AI deployments since MCP connectors first launched.

Real-world adoption is already underway. Ramp, the fintech company, reports that 2,000 employees are now provisioned through Okta with zero additional steps required of any individual user. HubSpot and Webflow are among the other enterprises actively rolling out EMA.

An Open Standard, Not a Proprietary Feature

One of the most important aspects of EMA is that it is built entirely on open standards. The underlying MCP authorization extension was developed collaboratively by Anthropic, Microsoft, Okta, and the broader MCP community. Visual Studio Code version 1.123 and later supports EMA at launch — meaning organizations using VS Code get the same zero-touch connector provisioning without being tied to Anthropic’s ecosystem.

This matters strategically. When Figma, Atlassian, Linear, Microsoft, Anthropic, and Okta simultaneously implement the same authentication standard, the pattern carries the characteristics of a de facto enterprise standard. Enterprise IT teams evaluating AI agent deployments may increasingly ask which MCP servers support EMA before approving rollout, much as they currently evaluate SSO and SCIM support when procuring SaaS tools.

Paul Carleton, a core maintainer of the MCP protocol, emphasized this point in the announcement: because EMA is an open specification, any MCP connector can adopt it and it works the same way for every customer, regardless of which AI platform they use.

Aaron Parecki, Director of Identity Standards at Okta, framed the broader significance: "By embedding the Cross App Access protocol into MCP as the Enterprise-Managed Authorization extension, we turn identity into a centralized governance plane and give security teams strict compliance control and users a seamless, secure experience."

What EMA Does Not Solve

It is important to be clear about the boundaries of what EMA addresses. Enterprise-Managed Authorization solves the provisioning and governance problem: who can access which MCP connectors, with centralized audit trails and reliable revocation.

It does not address runtime security risks. Once an agent has legitimate access to a connector, EMA does not govern what the agent does with that access. Prompt injection attacks — where malicious content in a document or tool output manipulates an AI agent into misusing its authorized access — remain an active area of concern that requires separate mitigation strategies.

Similarly, supply chain risks from malicious or compromised third-party MCP servers are outside EMA’s scope. The Center for Internet Security published MCP security guidance in April 2026 that covers these broader runtime concerns, and organizations deploying MCP at enterprise scale should review that guidance alongside EMA adoption.

There is also one significant limitation at launch: Okta is the only supported identity provider. Organizations running on Microsoft Entra ID (formerly Azure Active Directory) or Google Workspace SSO are not yet served by EMA. Anthropic has confirmed that additional identity provider integrations are on the roadmap, but no release timeline has been published. Given that the underlying ID-JAG standard is an open IETF specification, the Azure AD integration is technically straightforward — the timeline is Anthropic’s to set.

How to Get Started With EMA

If your organization is on a Claude Team or Enterprise plan and uses Okta as its identity provider, you can apply for the EMA beta today. The setup process mirrors how you would configure any other enterprise application in Okta.

First, you enable the MCP connectors you want to provision for your organization in Anthropic’s admin console. Then you configure the Okta integration, mapping your organization’s groups and roles to connector access policies. From that point forward, any user who logs into Claude through your organization’s SSO inherits the approved connectors automatically.

For organizations building custom internal MCP servers, the open specification means you can add EMA support to your own connectors using Okta’s TypeScript or Java SDKs. This lets you extend the same zero-touch provisioning model to proprietary tools that are specific to your organization.

The official documentation is available through Anthropic’s enterprise docs and the MCP protocol blog. Developers interested in contributing to the standard can join the EMA Interest Group through the MCP community.

What This Means for the Future of Enterprise AI

EMA represents a maturation point for AI agent infrastructure. The pattern of individual users managing their own AI tool connections was always a transitional phase — workable for early adopters and small teams, but fundamentally incompatible with enterprise governance requirements.

By routing MCP authorization through identity providers, Anthropic has brought AI agent connections under the same governance layer that already controls every other enterprise application. This is the kind of infrastructure that makes large-scale AI deployments viable for regulated industries, government agencies, and any organization where security and compliance are non-negotiable.

The fact that it launched as an open standard — simultaneously supported by Anthropic, Microsoft, and Okta — suggests that Enterprise-Managed Authorization will become a baseline expectation for enterprise AI tooling, not a differentiating feature. Organizations that are serious about deploying AI agents at scale should start evaluating EMA now, even if their identity provider is not yet supported.

If you are tracking your Claude usage across models and team members as you scale enterprise adoption, tools like Gaugr can help you monitor consumption and usage limits in real time — useful context when planning which connectors to provision and how aggressively to roll out AI tooling across your organization.