What happened
Anthropic’s Claude Help Center describes Enterprise-managed auth as an authentication and authorization model for connectors on Claude Team and Enterprise plans. Rather than asking every person to authenticate each connector separately, an administrator configures access centrally. The organization can decide which connectors are enabled, which groups or roles receive them, and which permissions Claude can request. Once enabled, a team member gets the connector automatically the first time they log in.
The article describes two identity sources. With IdP-managed auth, the organization’s identity provider signs the user into the connector; Claude and the connector must have SSO enabled. The identity provider’s groups and roles determine inherited access. The administrator confirms the identity-provider connection, configures the connector’s own admin settings, tests the connection, selects roles, and chooses scopes. The chosen scopes apply to all selected roles, while permissions can be narrowed for an individual role in that role’s connector settings.
The second option, Claude-issued auth, is in beta. Claude can send a signed assertion to the connected service under an issuer URL unique to the organization. The service must list that URL as a trusted issuer. The setup does not require an identity provider or SSO, although Anthropic recommends enforcing SSO for the Claude organization. Users are matched by email address, so their Claude email must match the account email at the connected service. Each connector uses one identity source at a time, though administrators can switch later.
Administrators can pilot access by selecting a custom role for one team, then expand it by adding more roles. They can also set authentication behavior from a custom role: members can authenticate individually, use managed authorization, or choose per connector. Browser sign-in can remain enabled alongside managed authorization; Claude tries managed authorization first and falls back to individual sign-in if that fails.
The article makes an important distinction about what Claude-issued auth establishes. Claude checks whether someone is a current member of the Claude organization; it does not check SSO, MFA, or the connected service’s own sign-in rules. Anthropic sends the member’s email address and a unique identifier to the connector at the organization’s instruction. Access decisions, scopes, and reachable data remain governed by Claude settings and the connected service’s permissions. The source says token lifetimes and lifecycle are managed by the connected authorization server and, for IdP-managed auth, the identity provider. Removing a person from Claude ends Claude-issued sign-in, but Anthropic says the person should also be removed from the connected service.
What the archive adds
This is a new fact on a known connector-authorization story, not a wholly new topic. Earlier coverage of Claude users auto-connecting MCP plugins via Enterprise Managed Auth described avoiding per-user OAuth prompts. The present help article adds a distinct beta path: Claude-issued authorization for supported connectors, including organizations without an identity provider. Prior coverage of the Claude Marketplace provides broader context on Anthropic’s connector ecosystem, but does not establish that this auth method applies to every marketplace listing.
Trend signal
This supports agent-ready software exposes capabilities: organizations can expose connectors selectively, assign them to roles, scope requested permissions, and revoke access. It is a concrete administrative boundary around what Claude can connect to, rather than a general claim that the integrations are automatically safe. The source also makes clear that the connected service retains a role in governing permissions and data access.
Why it matters
Connector availability is only one part of making an AI assistant useful inside an organization. Teams also need a way to provision access consistently, pilot integrations, and remove access when someone leaves. Central administration can reduce repeated sign-in steps and make connectors available by role, which may lower friction for routine work without asking each employee to configure every integration.
The beta Claude-issued method could matter to organizations that want managed sign-in but do not want to set up an identity provider for a connector. Its boundary is equally important: membership in Claude is not proof that a user passed the connector’s own MFA or SSO requirements. Administrators should assess the connected service’s trust and permission model, keep scopes narrow, and determine how account removal is handled on both sides. This is an access-management choice, not a substitute for reviewing what data an integration can reach.
Limits and uncertainty
The help article does not name the supported Claude-issued connectors in the supplied material, quantify adoption, or provide a general availability date for the beta. It says only connectors whose providers support Claude-issued auth can use it. It also does not establish that all connected services accept the organization’s issuer, or that a trusted issuer bypasses those services’ own requirements. Claude-issued auth checks organization membership only; the article explicitly says it does not check SSO, MFA, or the connector’s own sign-in rules. The source provides no pricing or measured reduction in setup time.
Reader takeaway
Enterprise-managed auth makes connector access an organization-level configuration, with role and scope controls rather than one-by-one employee setup. Claude-issued auth extends that model without requiring an identity provider, but it is beta and checks Claude organization membership—not MFA or the connector’s own login policy. Treat the issuer trust, connector permissions, and removal process as part of the deployment decision.