Anthropic has introduced a new capability allowing organizations to automatically provision their workforce with access to Claude plugins, eliminating the need for staff to authenticate and authorize each service separately. The system also enables Claude to confirm that users belong to their organization, streamlining how companies control access to internal tools.

The capability extends the Enterprise-Managed Authorization (EMA) extension to the Model Context Protocol (MCP), which launched in June. At that time, The New Stack reported on how the extension allowed companies to manage MCP connections through their existing identity providers, with Okta being the first to implement support.

Anthropic announced EMA support across Claude, Claude Code and Cowork in June and released developer guidance for building compatible MCP servers. However, the original approach required that an organization's identity provider had EMA capability. Since Okta remained the sole early adopter and uptake among other providers stayed minimal, many organizations continued authorizing connections manually.

The company unveiled a new path forward this week: Claude itself can generate the signed identity assertions that MCP services rely on to recognize employees. This removes the dependency on identity provider support, allowing businesses to enable automatic connections without waiting for their existing authentication systems to catch up.

Claude itself can issue the signed identity assertions that participating MCP services use to recognize employees.

Anthropic, via ClaudeDevs X account

Anthropic encouraged developers to adopt the capability in a message on ClaudeDevs: "If you're building plugins for Claude, add support so users get started faster and stay connected without re-authorizing." The feature is currently available in beta for Team and Enterprise customers.

Reducing authentication overhead

Boris Cherny, head of applications at Anthropic, highlighted the pain point the feature addresses in a post on X on Tuesday:

Signing in to your company's plugins one by one is annoying.

Boris Cherny, Anthropic

Cherny elaborated: "Signing in to your company's plugins one by one is annoying, so we let Claude auto-connect to them now. Team and Enterprise admins can set them up, and teammates are connected automatically the first time they use the plugins."

Administrators gain granular control over which services are enabled and which employee roles can access them. A company might permit all staff to use a general productivity plugin while restricting access to sensitive systems—such as databases—to specific roles to prevent exposure of confidential data or unauthorized modifications.

When a qualified user opens a plugin, Claude transmits a signed assertion confirming their organizational membership. The service receiving this assertion validates it before issuing an access token. The mechanism also handles future connections without requiring users to re-authenticate when tokens expire.

The initial wave of supported services includes more than a dozen platforms: Amplitude, Apollo.io, Atlassian, Datadog, Dropbox, Figma, Granola, HubSpot, Linear, Mixpanel, Notion, PagerDuty, Semrush, and Supabase.

Supabase detailed the capability in a November 3 blog post, noting that its customers can now use Claude to verify employees accessing its MCP server even if their identity provider does not support EMA. The company highlighted the slow adoption of the extension among enterprise identity providers as a significant barrier that this new approach overcomes.

Okta was the only identity provider that supported the extension at launch and most still don't. Organizations on those providers no longer have to wait because Claude can now be the issuer instead.

Supabase

Setting up the connection requires a Supabase administrator to first authorize Claude for the organization. An administrator then selects Claude-issued authorization in Claude's connector settings, registers the unique issuer URL in Supabase, validates the connection and activates access for the relevant employee roles.

Supabase notes that employees must already possess a matching SSO account, and their existing permissions determine what they can access. The company also warns that removing someone from the company's identity provider alone will not revoke Claude-issued access; administrators must remove departing employees from both Claude and Supabase separately.

Supabase authorization screen showing Claude requesting access to a user's account.
Authorizing Claude to access Supabase.

Claude stepping into identity territory

The net effect is that Claude now performs a function traditionally reserved for enterprise identity providers: attesting to user identity when they access third-party services. Though still in early stages and currently limited to business use cases, the announcement has drawn positive feedback from users.

Tired of reauthorizing in every other session.

One user on X expressed enthusiasm: "This is soo good, tired of reauthorizing in every other session." Other users have called for broader adoption, with one noting heavy friction around Stripe integrations: "I spend more time reconnecting Stripe than every other plugin combined."

The announcement also sparked discussion about the broader implications for enterprise authentication. One observer noted, "Claude becoming an identity provider," raising questions about Anthropic's expanding role in user identity verification.

From a technical standpoint, Claude functions as a trusted issuer for participating MCP services, confirming that users belong to a specific Claude organization. It does not provide the full suite of capabilities associated with a traditional identity provider, and connected services retain responsibility for enforcing their own access controls.

For now, Claude's identity role remains limited to services that choose to accept its assertions about who users are.