# Claude Auto-Connect: How Claude-Issued Auth Works for Team and Enterprise

Claude can now vouch for organization members directly, but connector permissions and offboarding still need careful attention.

By Paras Madan | 2026-11-04


Anthropic announced Claude-issued auto-connect on November 3, letting eligible organization members use supported plugins without signing into each one separately. The beta is for Claude Team and Enterprise. It gives admins another way to provision access when their identity provider cannot support enterprise-managed authorization.

The [official announcement](https://x.com/ClaudeDevs/status/2117680635561312732) lists integrations including Linear, Notion, Figma, Dropbox and Supabase. Support is connector-specific, so an available Claude connector does not automatically support this new authentication path.

## What changed from existing managed authorization

Anthropic's [admin documentation](https://support.claude.com/en/articles/15537633-auto-connect-your-organization-s-apps-to-claude) separates two options. IdP-managed authorization is generally available and uses an organization's identity provider. Claude-issued authorization is the new beta: Claude signs an assertion under an organization-specific issuer URL that the connected service agrees to trust.

Users are matched by email address. Admins control eligible roles and requested scopes, while the connected service still determines what its accounts can access.

There is a meaningful security distinction. **Claude-issued auth checks Claude organization membership, not SSO, MFA or the connector's own sign-in rules.** Anthropic still recommends enforcing SSO for the Claude organization. Removing an employee from Claude stops new sign-ins, but existing service sessions continue until their tokens expire or are revoked. The employee must also be removed from connected services before their email address is reassigned.

That means the shorter onboarding flow needs a clearly owned offboarding process. An organization should know which system removes membership, which system ends access and whether those actions happen together.

## How the token exchange works

The [MCP Enterprise-Managed Authorization extension](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization) describes a signed grant called an ID-JAG, short for Identity Assertion JWT Authorization Grant. The client exchanges that grant with the MCP server's authorization server for an access token.

In the identity-provider flow, the IdP makes the policy decision. The receiving authorization server validates the issuer, signature, audience and expiration before mapping the identity to permissions. Claude-issued auth provides an alternative issuer for supported integrations, rather than making every MCP server trust Claude automatically.

For a plugin builder, this moves some integration work to the organization level. The experience can become simpler for each employee, but the trust relationship still has to be configured and validated.

## Provider requirements still matter

[Linear's documentation](https://linear.app/docs/mcp) makes the commercial boundary concrete. Its auto-connect beta requires Linear Business or Enterprise alongside Claude Team or Enterprise, with admin access in both products. Members keep their existing Linear permissions, and the emails in both services must match.

Linear's setup also uses a tenant ID in addition to the Claude issuer URL. The practical lesson is to check the provider's guide, rather than assume that the Claude plan alone makes an integration ready.

[Supabase documents a different set of requirements](https://supabase.com/docs/guides/platform/sso/enterprise-mcp-authorization). Its organization needs Team or Enterprise, SSO configured and members who have signed in through SSO at least once. Email matching ignores case but does not accept aliases or plus-addresses.

Supabase also trusts only one issuer per SSO provider. Replacing an IdP issuer with Claude's issuer causes it to reject grants from the old issuer, which can interrupt other AI tools using that path. Registering an issuer alone is insufficient: an owner or admin must authorize the MCP client too.

## What to test before a wider rollout

The useful pilot checks both success and denial. Can an intended member reach the right workspace? Does someone outside the selected group remain excluded? Does the connector retain the person's existing permissions? What happens when that person leaves?

These checks matter because onboarding convenience is visible immediately, while a mismatched account or incomplete removal can stay unnoticed.

Auto-connect can remove repeated setup from employees' daily work. Its lasting value depends on whether the organization can make access just as predictable when roles change or people leave.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help enterprise AI teams turn complex product capabilities into clear technical stories that developers and decision-makers can understand.

[Book a 30-minute call](https://cal.com/paras-madan/30min).