Anthropic Lets Admins Provision MCP Connectors for the Whole Org Through Okta — Zero Setup for Users

Update, 7 July 2026: Claude’s Microsoft 365 MCP connector gains write tools: email, calendar, OneDrive, and SharePoint

The Microsoft 365 connector covered in this post has moved beyond read-only. As of today, Claude can draft and send email, manage calendar events, update mailbox settings, and create or edit files in OneDrive and SharePoint. Teams remains read-only for now.

Two separate admin actions are required before any of this is available to members. A Microsoft Entra administrator must first consent to the expanded permission set, then an org admin must enable write tools inside Claude. Until both steps are completed, the connector behaves exactly as before.

A few boundaries worth noting: write access stays within each member’s existing Microsoft 365 permissions, so Claude cannot do anything the user could not already do directly. Emails Claude sends include an attribution header identifying them as agent-initiated; file and calendar writes are not currently tagged. Attachments are not supported in write mode. Per-user rate limits apply to sends, writes, and recipients.

This update builds directly on the Okta-provisioning story here. Admins who already pushed the Microsoft 365 connector to their org through an identity provider now have a meaningful new capability to unlock, but activating write tools requires a deliberate, separate decision on both the Entra and Claude org-admin sides.

Full details are in Anthropic’s admin setup guide and the end-user connection guide.

Update, 30 June 2026: Anthropic launches Claude apps gateway for Bedrock and Google Cloud: corporate SSO, central policy, and per-user cost tracking for Claude Code

Anthropic has released the Claude apps gateway, a self-hosted control plane that extends the same governed provisioning story covered in this article to organisations running Claude Code through Amazon Bedrock, Google Cloud, or Microsoft Foundry.

Where this post described Okta-based MCP connector provisioning for Anthropic-hosted Team and Enterprise accounts, the gateway targets the separate audience that must route inference through their own cloud provider for data residency or compliance reasons. The two features share the same OIDC theme but serve different deployment models.

The gateway runs as a stateless container backed by PostgreSQL. Admins configure it once; developers sign in with their existing corporate identity provider (Google Workspace, Entra ID, or Okta), receive a short-lived session token, and inherit centrally enforced managed settings and model allowlists automatically. No per-developer cloud credentials are provisioned. Offboarding is IdP-native: remove a user from your identity provider and their access expires within one hour.

Additional capabilities include OTLP telemetry for per-user cost attribution, daily and monthly spend caps, and failover routing across providers. The gateway is built directly into the claude binary and documented here.

Organisations without a third-party cloud requirement should still consider Claude for Enterprise, which offers richer admin tooling including SCIM provisioning with nothing to host.

Update, 23 June 2026: Anthropic launches Claude Tag: a persistent, shared AI teammate inside Slack channels

Anthropic has launched Claude Tag in research preview for Enterprise and Team customers, and it extends the admin-first provisioning story covered in this article in a significant way.

Where this post focused on Okta-provisioned MCP connectors eliminating per-user OAuth flows, Claude Tag takes that logic further. In a Claude Tag channel, Claude operates under a workspace-level service account that an admin configures during setup rather than under any individual user’s credentials. Anthropic calls this “Agent Identity.” The channel Claude and the Okta connector model are now two parts of the same org-level control layer: admins wire up tools once, and Claude acts under those permissions on behalf of the whole team.

The feature itself is a meaningful shift from a per-user chatbot to a shared team assistant. Key capabilities include persistent memory scoped to designated channels, an ambient mode that monitors conversations and proactively surfaces relevant context, async task execution, and per-channel token spend limits with a full audit log.

One hard deadline applies: the existing Claude in Slack app is replaced by Claude Tag on August 3, 2026. The migration is not automatic. Admins need to configure Claude Tag through admin settings before that date, as the legacy integration stops working entirely after it.

Claude Tag runs on Claude Opus 4.8 and is not yet available on Pro plans.

If you’ve been rolling out MCP connectors in Claude for your team, you’ll know exactly where the friction lives. Admins enable a connector at the organization level, and then every individual employee still has to go through their own OAuth authorization flow before they can actually use it. For a team of ten, that’s annoying. For a team of two thousand, it’s a genuine deployment problem.

Anthropic has shipped a beta fix for this, and it’s a meaningful one.

What’s New

Enterprise-managed authorization for MCP connectors is now available in beta for Team and Enterprise Claude plans. Admins can provision connectors for their entire organization through their identity provider, with Okta supported at launch. Once configured, users get connector access automatically the first time they log in. No extra steps, no separate OAuth prompt, nothing to click through.

Access is scoped to the Okta groups and roles employees already belong to, so there’s no new permission model to learn or maintain. If someone’s in the engineering group, they get the engineering-relevant connectors. If they’re offboarded, Okta’s standard revocation path removes their connector access alongside everything else.

The connectors show up consistently across Claude chat, Claude Code, and Cowork.

How It Works Under the Hood

The feature is built on Cross-App Access (XAA), an OAuth extension that was adopted by the OAuth working group in September 2025 and is now incorporated into the MCP spec as the Enterprise-Managed Authorization extension. The spec is stable and open, which matters for a couple of reasons covered below.

The auth flow itself is straightforward: the MCP client calls the IdP’s token endpoint using OAuth Token Exchange, essentially presenting the user’s existing session and requesting access to a specific MCP server. The IdP evaluates that request against the organization’s configured rules, the same way it handles SSO access for any other app. No new credentials, no separate token store to manage.

Because access is verified through the IdP on each use rather than relying on a long-lived OAuth grant, admins can shorten token lifetimes without creating friction for users. A deprovisioned account loses connector access quickly rather than carrying a stale credential window until a token eventually expires.

What This Means for Your Team

For employees: Connectors are just there. First login, everything provisioned to your role is already available. You don’t need to know what an OAuth flow is.

For IT and security teams: This removes the two main objections that tend to stall MCP adoption in security-conscious organizations. Access decisions live in the Okta admin console alongside every other enterprise application, giving you a single auditable trail. You can scope connector access by existing groups and roles rather than managing a separate permission layer. And because offboarding flows through Okta’s standard path, you’re not left hunting for stale AI connector credentials when someone leaves.

Admins can also enforce that a specific connector only connects through the IdP, which keeps work and personal accounts cleanly separated and prevents someone from accidentally linking a personal account to a work tool. Personal connectors can still be added on top of what’s provisioned organizationally, so employees aren’t locked into a completely admin-controlled environment if the policy allows flexibility.

For compliance teams: Centralized policy, centralized audit trail, and access that’s tied to the same identity lifecycle as the rest of your stack. That removes a genuine procurement objection for organizations that have been watching MCP with interest but hesitating.

Ramp, one of the early customers, reports 2,000 employees provisioned through Okta with no extra steps. HubSpot and Webflow are also among the organizations in early rollout.

Which Connectors Are Supported

At launch, enterprise-managed auth works with Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase. Slack support is coming soon.

The open-standard foundation matters here: because Enterprise-Managed Authorization is a published extension to the MCP spec, any connector can implement it, including connectors your own teams build internally. They all work the same way, through the same IdP integration, without requiring any special treatment from Anthropic.

Microsoft and Visual Studio Code have also added support for the EMA spec, which suggests this is becoming the standard authorization approach for enterprise MCP deployments rather than a Claude-specific feature.

The Okta Caveat

Okta is the only supported identity provider at beta launch. The announcement says more providers are coming, but there’s no published timeline. If your organization runs on a different IdP, you’re waiting. That’s the honest limitation of the current beta, and it’s worth factoring into any near-term deployment planning.

How to Get Access

The feature is in beta for Claude Team and Enterprise customers. You can apply for access through the Claude admin console. MCP providers who want to support enterprise-managed auth can also apply separately.

If you’re running Claude at any meaningful scale in an Okta shop, this is probably worth a look now rather than waiting for general availability.