Anthropic announced enterprise-managed authorization (EMA) for Claude’s MCP connectors on August 24, 2026. The feature is now generally available for Team and Enterprise customers. In plain terms: IT admins can provision tools like Asana, Figma, Atlassian, Datadog, Notion, and Slack through Okta. Employees get access automatically the first time they log into Claude. No OAuth consent screens. No IT tickets. No waiting.
I’ve sat through enough MarTech rollouts to know why this matters. The tooling itself was never the bottleneck. Getting a few hundred (or a few thousand) employees actually authorized to use it was.
Why This Actually Matters
Here’s the reality of enterprise AI rollouts up to now: a company enables a connector at the org level, but every employee still has to click through their own OAuth authorization for each tool. A new hire at a company running a dozen MCP-connected apps had to clear twelve separate consent screens before doing any real work.
I’ve watched this exact pattern kill momentum on tool adoption long before AI connectors existed. It’s the same story with any SaaS integration that requires per-user setup at scale. Claude connectors raise the stakes, though, because they sit on top of genuinely sensitive systems: your Jira backlog, your Figma files, your Supabase database. IT teams manage access to everything else in the stack through their identity provider. They had no equivalent lever for Claude. That’s a governance gap, not just a UX annoyance.
EMA closes that gap. Admins connect Okta once. They scope connector access to specific IdP groups or roles. Access just shows up for the right people. When someone changes teams or leaves the company, the IdP revokes access on the next token refresh — the same mechanism that already governs everything else they touch.
How the Mechanism Actually Works
This runs on an open standard called ID-JAG (Identity JWT Authorization Grant), not a proprietary Anthropic protocol. The IETF OAuth Working Group adopted the spec in September 2025. The MCP specification incorporated it that November. Anthropic declared it stable as a formal MCP authorization extension on June 18, 2026, the same day EMA launched in beta.
Here’s the core mechanism: the identity provider issues a signed identity assertion instead of prompting a user for OAuth consent. MCP servers use that assertion to verify identity and authorization in one round trip. Okta calls its implementation Cross App Access (XAA). Okta’s TypeScript and Java SDKs already support it, which likely explains why VS Code shipped its own EMA support the same day as Anthropic’s June beta.
Developers building MCP servers face a few specific requirements. The token exchange uses the JWT-bearer grant type from RFC 7523. It runs as a back-channel request with no browser redirect. Dynamic Client Registration doesn’t work here — the IdP must pre-register Claude’s client ID ahead of time. Short-lived access tokens (Anthropic cites one hour as an example) don’t force repeated re-authentication, because Claude refreshes the underlying identity assertion through the IdP’s longer-lived refresh token.
What’s Actually Live Right Now
Ten MCP providers support enterprise-managed auth as of the August 24, 2026 GA announcement: Asana, Atlassian (Jira, Confluence, Rovo), Canva, Datadog, Figma, Granola, Linear, Notion, Slack, and Supabase. Exa, Miro, and Zoom carry a “coming soon” label. Okta remains the only supported identity provider so far, though Anthropic says others are on the way without naming them.
This feature stays limited to Team and Enterprise plans — Free and Pro users don’t get it. It works consistently across Claude chat, Claude Code, and Claude Cowork.
What Early Customers Are Reporting
Companies that tested EMA during the beta describe a familiar pattern: the win isn’t a new capability, it’s the removal of friction that quietly cost time every single day.
Ramp’s Staff IT Engineer described onboarding 2,000 employees through Okta with zero extra steps, compared to a queue of per-connector approvals beforehand. Webflow’s Senior Manager of Enterprise AI Operations put it simply: EMA turned Claude into something people actually use instead of something they have to request.
That distinction tells the whole story here. Tools that require a ticket before anyone can use them get used less, full stop, regardless of how good they are.
The Security Case Is the Stronger One
The quotes from security and engineering leaders at partner companies point to something more specific than convenience. Supabase’s CISO described the pre-EMA choice bluntly: teams either made everyone an org owner or handed out Personal Access Tokens with no central revocation path. Neither option sits well with a security team, especially in regulated industries.
EMA offers a third option: access controlled by the IdP, scoped by role, and centrally audited. That matches how every other sensitive tool in a modern stack already gets managed. IT and security teams should pay more attention to this detail than to the onboarding-speed angle.

Where I’d Push Back — And What’s Still Open
A few things deserve a flag before anyone calls this problem solved:
- Single IdP dependency. Okta is the only supported identity provider right now. Organizations running Azure AD, Google Workspace, or another IdP as primary must wait for Anthropic to expand support, and no committed timeline exists beyond “coming soon.”
- Connector coverage keeps growing, but it’s not complete. Ten providers at GA marks a solid start. Plenty of commonly used MCP connectors haven’t made the list yet, and custom internal connectors will need engineering time to implement the ID-JAG extension.
- This doesn’t replace access review. Centralizing provisioning through IdP groups makes governance easier, but the payoff depends entirely on how carefully those groups get scoped. Sloppy group definitions just automate sloppy access faster.
None of that changes the overall direction. It just means “GA” doesn’t mean “finished.”
The Bigger Picture
The most interesting part of this story isn’t the feature — it’s the choice to build on an open standard instead of a proprietary mechanism. VS Code, Okta, and seven MCP providers rolled out support on the same day. That’s a real interoperability baseline, not a single-vendor lock-in play. It suggests the industry is converging on a shared answer to a hard question: how should an AI agent inherit enterprise identity? Vendors seem to prefer a shared answer over building three separate versions.
This question matters more than it looks for any team planning to deploy agents across a large organization. An agent that needs to touch Jira, Supabase, and Figma needs identity and access that IT can actually govern from one place, not three separate consent flows and three separate audit trails.
Teams on Claude Team or Enterprise that delayed connector rollout because of the OAuth-queue problem should revisit it now. Teams without Okta should watch Anthropic’s admin console for additional IdP support. In the meantime, clean up your IdP groups — that step matters regardless of which identity provider gets supported next.

