Claude now auto-connects connectors: IdP-managed is GA, Claude as trusted issuer in beta

On 3 November 2026 Anthropic announced a way to authorize connectors in Claude at the organization level rather than per user. The accompanying support article, 'Auto-connect your organization's apps to Claude', summarizes the intent like this:

"you authorize a connector once for your entire organization, and your team inherits access automatically on first login."

For administrators, the combination of those two variants is what matters most. The IdP route relies on existing SSO and IdP groups; the Claude-issued route has Claude itself send a signal to the connector without an identity provider. Which variant you choose determines how entitlements, scopes and offboarding work in practice. Below you will find how it works, the configuration steps, the limitations and the technical layer underneath, with the variant named alongside every status claim.

What changes

At its core, the change is a shift from per-user consent to organization-wide authorization. Where an employee previously had to connect a connector themselves and pass through a consent screen, an organization can now authorize the connector once and let it follow the identity that already exists. Anthropic describes it as: the organization authorizes a connector once, and the team inherits access automatically on first login.

That does not mean personal connectors disappear. Personal connectors remain possible on top of the managed route, the support documentation states. Browser sign-in and managed authorization can be on at the same time; Claude tries managed authorization first and falls back to individual sign-in if that does not work. That order is practical: you keep the managed route as the default without locking users out entirely.

It is separate from other announcements in the same week. Anthropic's message threads of 2 November 2026 are a different product: server-side conversation persistence in the Messages API, not connector authentication. If you follow the business side of Anthropic, you will find that in the analysis of Anthropic's S-1/A; it is unrelated to the connector feature.

Connectors, apps or plugins: the naming

The naming varies, and that is useful to know for documentation and search work. The support article consistently uses the term 'connectors' in the body, while the title of that same article speaks of 'apps'. Anthropic's posts on X about the same feature — from @ClaudeDevs on 3 November 2026 and from Boris Cherny (@bcherny) — call them 'plugins'.

For your own runbook and for communication to users, it is sensible to pick one term and mention the other. In this article that is 'connectors', with the note that the same functionality appears on X as 'plugins'. If you search in the admin environment, you will find the settings under connectors, not under plugins.

Two identity sources

Each connector uses one identity source at a time. The first is IdP-managed: it "relies on single sign-on (SSO) being enabled on Claude and the connector. With that in place, the IdP signs the user into the connector." Identity is inherited from existing identity provider groups and roles. The second is Claude-issued (beta): Claude indicates to the connector which user is signed into Claude, under an issuer URL that is unique to your organization. No identity provider or SSO is needed for that; users are matched at the connector by email address.

That split is not a detail. With IdP-managed auth, access decisions and scoping stay with your identity provider's policies and with the permissions of the connected service, not with Anthropic. With Claude-issued auth, Claude makes a statement about membership and nothing more. Which source you choose per connector therefore determines where your access policy lives.

IdP-managed: generally available

IdP-managed auth is the variant that is generally available. The condition is that SSO is enabled on Claude and on the connector; once that is in place, the IdP signs the user into the connector. Because identity comes from existing IdP groups and roles, this route connects to what you have already set up for other applications.

The flip side is that you cannot manage anything without that SSO basis. On the identity provider side, the support article names Okta as supported, with more identity providers coming soon. If you use a different identity provider, the support article does not yet list it as supported; the Claude-issued route needs no identity provider, but comes with the limitations described below.

Claude-issued: beta and only a membership check

Claude-issued auth is in beta. Claude indicates to the connector which user is signed into Claude, under an issuer URL that is unique to the organization. No identity provider or SSO is needed, and matching happens on email address. To do this, Anthropic sends each member's email address and a unique identifier to the connector.

The security boundary is stated literally in the support text:

"Claude checks organization membership only, not SSO, MFA, or the connector's own sign-in rules."

The practical consequence: Claude-issued auth is a workable interim option for organizations that want to roll out quickly, but it is not a replacement for IdP policy. Treat it as an easy route with a narrower control base, not as the stricter of the two.

What you determine as an admin

The administrative role is broad. You choose which connectors are enabled and which roles get them. You can assign the built-in roles User, Admin, Owner and Primary owner as a group, or custom roles individually — for example to pilot with one team first. You also determine which scopes Claude can request.

In addition, you can revoke access. With IdP-managed auth, deprovisioning in the IdP removes connector access at the same time. With Claude-issued auth, signing stops as soon as someone is removed from the Claude organization, but you must also remove that person from the connected service. You can further require that a connector only connects via managed authorization, so that personal accounts stay out of your work tools.

How to turn it on

Configuration runs through Organization settings > Connectors. You select a connector, go to the Configuration tab and choose 'Set up' next to Managed authorization. Then follow the choice of identity source, a Roles step, a Scopes step and finally 'Save & turn on'.

For the Claude-issued variant there is one extra step: copy the issuer URL and add it as a trusted issuer in the admin console of the connected service. Optionally you paste a tenant ID, after which you go through 'Test connection' and 'Enable and continue'. Anthropic advises asking two or three users to confirm the connector works before you announce the rollout. That is a small step that saves a lot of support questions, especially with connectors where matching on email address plays a role.

Offboarding and reused email addresses

The most sensitive point is offboarding. Claude only signs for current members; the moment you remove someone, access already granted at a service lasts until it expires. So remove the person from every connected service before that email address is reused — otherwise a new person with that address could be signed in to the old account.

With SCIM, Claude removes a member when the directory deletes that person, but not when the directory only suspends them or marks them inactive. That distinction is exactly where things go wrong in practice: a suspension feels like cleaning up, but it leaves connector access in place. Because access tokens that have already been issued stay valid after someone is removed, the access token lifetime determines how long a removed user keeps access. Tie that to your existing practice for managing API keys and tokens securely, because the same questions about rotation and lifetime come back here.

Which connectors take part

These connectors can be provisioned through Enterprise-managed auth: Amplitude, Apollo.io, Asana, Atlassian, Canva, Crossbeam, Datadog, Dropbox, Figma, Granola, HubSpot, Linear, Lovable, Mixpanel, Monday.com, Notion, PagerDuty, Semrush, Slack, Supabase and Unblocked. Not every connector supports the Claude-issued variant; that beta works only with providers that support it. In the support list those are Amplitude, Apollo.io, Atlassian, Datadog, Dropbox, Figma, Granola, HubSpot, Linear, Mixpanel, Notion, PagerDuty, Semrush and Supabase.

If you manage an MCP provider that is not on this list: any MCP provider can add support for Enterprise-managed auth, according to the support documentation. The list is therefore a snapshot. For the broader development of the ecosystem, the MCP ecosystem tracker with new servers and practical experiences is a useful place to see who joins.

How it works technically: the MCP extension and ID-JAG

The IdP and enterprise-managed route is the open MCP extension 'Enterprise-Managed Authorization' (io.modelcontextprotocol/enterprise-managed-authorization) on modelcontextprotocol.io. @ClaudeDevs calls it "built on an open extension to MCP". In the flow, the client exchanges an Identity Assertion JWT Authorization Grant (ID-JAG, an IETF OAuth working-group draft) for an access token from the MCP server's authorization server. Extensions are opt-in and never active by default.

The Claude-issued 'trusted issuer' variant is an Anthropic beta on top of that model: Claude signs the assertion under https://identity.anthropic.com/issuers/<id>. That is not the MCP core specification, and the MCP specification does not prescribe Claude as issuer. Hold on to that distinction when you talk to vendors: the extension is the shared model, the trusted issuer is one vendor's implementation of it. You can follow the current state of the specification through the running tracker of the MCP version landscape.

What connector builders must arrange

On the connector side, several things change. A signed JWT identity assertion replaces the per-user OAuth consent screen. The authorization server must accept the JWT bearer grant (RFC 7523). Dynamic Client Registration (DCR) is not supported with Enterprise Managed Auth. Claude-issued assertions use ES256 and expire within a minute.

Important for implementation: a Claude-issued assertion "doesn't say that the user signed in through the customer's identity provider or used multi-factor authentication, and it carries no group claims". Servers must therefore find Claude-issued users by verified email, not by sub. The documentation also warns that "An issuer URL isn't a secret". Access tokens that have already been issued stay valid after removal, so the access token lifetime bounds how long a removed user keeps access. Developers who want their directory listing marked as supporting it email [email protected].

For teams that both build and consume connectors, it is useful to keep up with daily developments through the daily MCP and agent tooling news, because practice shifts quickly precisely on issuer trust and token lifetime.

Why this matters for security

The broader context makes clear why this kind of detail deserves attention. GitBook's status page reported on 3 November 2026 an attack "using AI agents", in which access to infrastructure credentials was obtained at 19:00 CET on 2 November; users of the GitBook MCP server are asked to re-authenticate it and rotate tokens. In addition, a token-validation vulnerability in the AWS API MCP Server has been fixed in version 1.6.0.

Those are not incidents in the Claude connector feature, but they show the kind of attack surface around connectors and MCP servers: tokens, assertions and the question of who may sign on whose behalf. Labs are scaling up their own security, as shown by OpenAI's security sprint and bug bounties, and how OpenAI and Anthropic detect misuse of their models is covered in an earlier piece. The idea that agent security requires assuming everything your agent reads can be attack input is worked out in this overview of agent security. And if you want to weigh the risks of LLM integrations more broadly, you will find starting points in the analysis of AI security for businesses.

As a single cross-reference, one line: on 3 November 2026 CrowdStrike announced an AI Kill Switch in Falcon Guardian (gateway first, endpoint later), with agent-level hooks including Claude Code, and runs its Falcon sensor inside the Claude Cowork VM in partnership with Anthropic.

What this means for teams in the Netherlands and Europe

The heart of the trade-off is least privilege. With IdP-managed auth, your identity provider determines which groups and roles get access, and the connected service determines which permissions come with that. That makes it possible to scope per team or per function instead of opening everything up per connector. With Claude-issued auth the check is narrower — membership of the Claude organization — and SSO, MFA and group claims are absent from the assertion. So choose the variant deliberately per connector, not as a default.

From a data minimization perspective, as general framing without new facts: every connector on which you enable managed authorization is a place where identity data goes. With Claude-issued auth, Anthropic sends each member's email address and a unique identifier to the connector. Limit the number of connectors to what you actually use, keep scopes as narrow as possible and record what the retention period is. For European organizations that is also the logical order: first determine which data is needed, then which identity source may transfer that data.

Practical checklist

• Decide per connector whether you use IdP-managed (GA) or Claude-issued (beta); each connector uses one at a time.
• Check that SSO is enabled on Claude and on the connector before you deploy IdP-managed; Okta is supported, more identity providers are coming.
• Consider 'require managed authorization' so personal accounts stay out of work tools.
• Pilot with one team first via a custom role or the role as a group, instead of all users at once.
• Limit the scopes Claude can request to what the use case requires.
• For Claude-issued: copy the issuer URL into the service's admin console, test the connection and have two or three users confirm it works.
• Arrange offboarding in both directions: remove people from the Claude organization and from every connected service.
• Watch SCIM behaviour: deleting in the directory removes the member, suspending or marking inactive does not.
• Align access token lifetime with your offboarding window, and only reuse email addresses after access has been revoked.
• Document which term you use internally: connectors in the admin environment, plugins on X.

The announcement is first and foremost an admin feature, not a new connector. What you gain is that the identity you already have determines access instead of a series of separate consent screens. What you must arrange for it is mainly discipline: one identity source per connector, limited scopes, and an offboarding path that goes beyond the Claude organization.

For teams that want to start today, the order is not very exciting: IdP-managed first where SSO is in place, then a pilot with Claude-issued for the connectors where the beta supports it, and check offboarding in the meantime. If you want to follow broader developments, keep an eye on the MCP trackers; the list of supported connectors is a snapshot and any MCP provider can join.

Checked on 2026-11-04.

This article was compiled with AI assistance and editorially reviewed; sources are listed below.

Sources

• Anthropic support article 'Auto-connect your organization's apps to Claude', with the configuration steps, roles, scopes, offboarding and the connector lists — https://support.claude.com/en/articles/15537633-auto-connect-your-organization-s-apps-to-claude
• Anthropic documentation for connector builders on Enterprise Managed Auth (JWT assertions, RFC 7523, ES256, email matching, issuer URL) — https://claude.com/docs/connectors/building/enterprise-managed-auth
• MCP extension 'Enterprise-Managed Authorization' with ID-JAG — https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization
• Post from @ClaudeDevs about the feature and the open MCP extension (3 November 2026) — https://x.com/ClaudeDevs/status/2117680635561312732
• Post from Boris Cherny (@bcherny) in which the same functionality is called 'plugins' — https://x.com/bcherny/status/2117693181651542387
• GitBook status page about the security incident of 3 November 2026, with the request to re-authenticate the MCP server and rotate tokens — https://www.gitbook.com/status/security-incident-2026-11-03