SONNET CODE
← Back to all articles
AI DevelopmentJune 27, 2026·11 min read

Anthropic Ships Okta Enterprise Auth for Claude's 7 MCP Connectors

What Anthropic shipped on June 18 and the governance-plane that lands with it

Anthropic's June 18 launch shipped Enterprise-Managed Authorization (EMA) for Claude's MCP connectors — the per-user OAuth consent screen the team and enterprise admin has been negotiating compliance reviews around since the first Claude-in-the-channel rollouts moves out of the user flow and into a silent identity-assertion JWT (ID-JAG) token exchange mediated by the organization's identity provider. Okta is the first IdP partner at launch; Microsoft Entra is in the same shipping queue. Seven MCP providers support EMA on day one: Asana, Atlassian (Jira, Confluence, Rovo), Canva, Figma, Granola, Linear, Supabase. HubSpot, Ramp, and Webflow are among the early organizations rolling out enterprise-managed auth across their teams.

The operationally important pieces:

  • The ID-JAG flow replaces the consent screen with a silent IdP-mediated token exchange. Identity Assertion JWT Authorization Grant — the IETF standard the flow is built against — replaces the redirect-and-consent step with a silent token exchange: the MCP client requests a signed identity assertion JWT from the IdP, the IdP applies admin-configured policy and issues the assertion, the MCP server validates it against the same trust relationship as regular SSO, and the MCP server issues a scoped access token. No user action is required, and no consent screen appears — the per-connector OAuth-fatigue surface that has been the load-bearing compliance objection collapses into the standing-SSO flow the IT team already operates.
  • The day-one onboarding inheritance is the default shape, not an opt-in feature. A new hire walking in on day one inherits every approved MCP connector — Figma, Atlassian, Asana, Linear, Canva, Granola, Supabase — without opening a ticket to IT. The default-onboarding shape moves the connector-access decision from per-user, at-first-use, against a consent screen to per-role, at-onboarding-time, against the admin-configured policy. The day-one inheritance is the procurement-grade user-experience asset the regulated-industry buyer has been asking for; the per-role policy is the governance-grade administration asset the compliance committee has been asking for. Both ship in the same flow.
  • The deactivation codepath closes the access-loss loop the FY25 audit flagged. Revocation runs the same path as activation: deactivate a user in Entra or Okta, and their MCP access goes with it. The FY25 audit finding that surfaced the most often in regulated-industry reviews — user-deactivated-in-IdP-still-has-API-access-to-the-connected-tool — closes on the same codepath the IdP team already maintains. The deactivation-loop closure is the load-bearing audit-finding the EMA flow neutralizes; the per-role provisioning is the load-bearing onboarding-finding the EMA flow neutralizes; the consent-fatigue collapse is the load-bearing user-experience finding the EMA flow neutralizes. Three audit-grade findings, one flow.
  • Seven connectors at launch is a partial coverage of the knowledge-work surface, not a complete one. Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase is the day-one coverage; HubSpot, Ramp, and Webflow are in the early-rollout queue. The standing knowledge-work surface — Slack, Notion, Salesforce, Google Workspace, Microsoft 365, ServiceNow, Workday — is not yet on the EMA day-one list. The FY27 rollout calendar that assumes day-one EMA coverage of the standing knowledge-work surface is sizing against a coverage map the launch list does not match; the rollout calendar that grades against the seven-connector day-one list plus the early-rollout queue plus the legacy per-user OAuth flow for the rest is the one the standing-contract has to encode.
  • The IdP partner-list expansion is the structural roadmap event, not the seven-connector list. Okta is at launch; Entra is in the same queue; the IdP-partner expansion is what determines whether the FY27 IT-stack the buyer already operates ships into the EMA flow without a re-platforming. The buyer running on Ping Identity, ForgeRock, or Auth0 is on the legacy per-user OAuth flow until Anthropic's IdP-partner expansion lands the buyer's IdP; the FY27 rollout calendar that does not encode the buyer's IdP against the partner-expansion schedule is a calendar whose Q3 rollout stalls on the wrong IdP-partner.

The structural read isn't Anthropic shipped enterprise SSO for MCP. It's that **identity becomes the centralized governance plane for Claude's tool-use surface, the per-connector friction surface that has been the load-bearing compliance objection collapses into the standing-SSO flow the IT team already operates, and the FY27 knowledge-work-stack procurement conversation moves from whether Claude is compliance-ready to which two-of-three tool categories get the EMA-flow on day one and which sit on the legacy OAuth flow until the partner-expansion lands. The governance plane is the substrate; the per-tool-category rollout calendar is the operating decision; the per-IdP standing-contract is the procurement artifact.

What the EMA launch restructures about the FY27 knowledge-work-stack procurement plan

Four concrete shifts that follow when the per-user OAuth consent screen collapses into a silent IdP-mediated token exchange across seven day-one MCP connectors and a queued IdP-partner expansion.

The compliance-review gate moves from per-connector to per-IdP-policy. The FY25 and FY26 compliance reviews ran per-connector — grade Asana against the data-classification policy, grade Atlassian, grade Figma, grade each connector against the per-tool data-access matrix. The EMA flow moves the per-connector grading up the stack to per-IdP-policy grading against the admin-configured connector list. The compliance gate is now one policy review per IdP per quarter, with the per-connector list grading against the standing policy — a calendar compression the FY27 plan that still encodes the per-connector compliance gate is not budgeted for.

The IT-onboarding flow moves from per-user-per-connector to per-role-per-connector-list. The FY26 IT-onboarding ticket-volume against the new-hire connector-provisioning surface was the load-bearing cost item in the IT-ticket-volume report the CFO grades against. The default-onboarding inheritance moves the ticket-volume to zero against the EMA-flow connectors — the per-role-per-connector-list policy is the artifact the IT team operates against once, and the per-user new-hire onboarding inherits the role's connector list with no IT action required. The IT-ticket-volume compression is the FY27 cost-line the FY26 plan was not budgeted to absorb; the per-role policy library is the FY27 engineering artifact the IT team has to ship.

The deactivation-audit gate moves from a separate quarterly review to the standing IdP-deactivation codepath. The FY26 audit-grade quarterly review of which deactivated users still have access to which connector is the audit-finding the IT team has been racing against the user-deactivation calendar to close. The EMA-flow closes the gate on the standing IdP-deactivation codepath — the deactivation runs once, the connector access drops at the same instant. The audit-finding is neutralized at the source; the quarterly review the team has been running collapses to a single annual sanity check; the IT-attention-hours freed up move to the per-role policy library the FY27 plan has to staff against.

The standing IdP contract has to be re-negotiated against the EMA-flow scope. The standing Okta or Entra contract was sized against the standard SSO + provisioning surface — the EMA-flow expands the scope to the Claude-MCP-connector governance surface the contract was not drafted against. The FY27 standing-contract negotiation has to encode the per-connector-policy seat-count, the per-policy-review cadence, and the IdP-partner-expansion fee schedule. The standing-contract that does not encode the EMA-flow scope is a contract whose Q3 spend lands two-to-three-times the FY27 forecast on the IdP-partner-expansion fee the team did not budget against.

Where the EMA launch is signal and where it is noise

Four honest reads on what the EMA launch actually tells the buyer.

Signal: the per-IdP governance plane is the structural change the FY27 plan has to encode. Identity-as-the-governance-plane is the substrate the compliance committee has been asking for since the first chat-window rollout. The FY27 plan that encodes the per-IdP governance plane as the standing-administration surface is the plan that closes the load-bearing audit-findings on the same codepath the IT team already operates; the plan that does not is the plan whose Q3 audit surfaces the same per-connector findings the FY26 audit surfaced.

Signal: the seven-connector day-one list plus the early-rollout queue is the FY27 rollout-calendar anchor. The FY27 rollout calendar should be drafted against the seven-connector day-one list plus the early-rollout queue (HubSpot, Ramp, Webflow) plus a partner-expansion-tracking column for the standing knowledge-work surface (Slack, Notion, Salesforce, Google Workspace, Microsoft 365, ServiceNow, Workday). The calendar that does not separately track the three buckets is a calendar whose Q3 rollout stalls on a connector that did not make the early-rollout queue.

Noise: the ID-JAG mechanism is implementation detail, not procurement signal. Identity Assertion JWT Authorization Grant is the IETF standard the EMA flow is built against; the standard is the implementation guarantee the IT team's SSO-stack already knows how to validate. The procurement-grade signal is the governance-plane shape and the day-one connector coverage, not the underlying token-exchange mechanism. The team that grades the procurement decision on the mechanism is grading on the wrong unit.

Noise: the headline 'Anthropic shipped enterprise SSO for MCP' is not the FY27 procurement question. The procurement-cycle question is the per-tool-category rollout calendar, the per-role policy library, the per-IdP standing-contract renegotiation, and the partner-expansion-tracking artifact. The headline is the event; the four artifacts are the decisions the FY27 plan has to encode.

What the FY27 procurement planner should do this quarter

Four concrete actions that close the gap between the EMA launch and the FY27 knowledge-work-stack procurement plan the launch forces.

Map the team's current MCP-connector surface against the seven-connector day-one list, the early-rollout queue, and the partner-expansion-tracking column. The single most operationally useful artifact the FY27 plan can produce inside the next four weeks is a per-tool-category coverage mapwhich of the team's standing connectors are on the day-one EMA list, which are in the early-rollout queue, which are not yet on either list and sit on the legacy per-user OAuth flow. The coverage map is the rollout-calendar anchor the standing-contract has to encode; the missing map is the audit-finding the FY27 review will surface.

Stand up the per-role policy library against the day-one connector list and route the per-role library through the standing IdP team. The per-role policy library is the load-bearing engineering artifact the IT team operates against once and the per-user onboarding inherits from the role's connector list on day one. The library should be drafted against the team's existing role-based-access-control surface — engineering, design, sales, finance, leadership — with a per-role connector-list and a per-role per-tool data-classification grade. The policy library is the FY27 operating substrate; the team that ships it this quarter has a per-role onboarding flow the CFO can underwrite against; the team that defers it ships the same per-user OAuth ticket-volume the EMA-flow was supposed to neutralize.

Re-negotiate the standing IdP contract against the EMA-flow scope before the rollout-calendar locks. The standing Okta or Entra contract has to be re-graded against the per-connector-policy seat-count, the per-policy-review cadence, and the IdP-partner-expansion fee schedule. The renegotiation cycle is a six-to-eight-week procurement workstream the FY27 plan has to budget against; the renegotiation that does not land before the rollout-calendar locks is the renegotiation that ships the rollout against a contract whose seat-count assumption surfaces as un-budgeted spend in the first quarter.

Stand up the partner-expansion-tracking artifact and route the artifact into the standing FY27 procurement review. The standing knowledge-work surface — Slack, Notion, Salesforce, Google Workspace, Microsoft 365, ServiceNow, Workday — is not yet on the EMA day-one list, and the buyer's FY27 rollout calendar that assumes day-one EMA coverage of these connectors is sizing against a coverage map the launch list does not match. The partner-expansion-tracking artifact is a per-connector grading of the EMA-launch probability against the per-quarter rollout-calendar the FY27 procurement review re-grades each cycle; the artifact is the load-bearing forecasting tool the team operates against the rollout calendar.

The senior-judgment work the EMA flow makes necessary but does not replace

The EMA flow compresses the cost of the per-user OAuth consent surface to zero and moves the per-connector compliance gate up the stack to a per-IdP-policy review the IT team operates against once. Both compressions touch the per-user friction and per-connector compliance overhead the team has been racing against; neither compression touches the senior-judgment work the FY27 plan still has to do: deciding which tool categories get the day-one EMA rollout, writing the per-role policy library that encodes the team's data-classification assumptions, owning the per-IdP-partner standing-contract negotiation, and grading which workloads route through the connector-mediated Claude flow versus the direct-API flow versus the local-knowledge-base flow.

The teams that confuse the cheapened per-user friction for the cheapened judgment will, six months from now, be reading post-mortems on per-role policy decisions whose root cause is we let the EMA-flow drive the per-role library, and the per-role library turned out to encode a data-classification assumption the audit surfaced as a compliance finding. The teams that keep the senior judgment at the center of the per-role policy library will, six months from now, be on the audit-clean side of the FY27 compliance review and on the day-one-onboarding side of the new-hire experience. The governance plane is the substrate; the per-role policy library is the surface; the senior judgment is the load-bearing wall.

The procurement question is no longer whether Claude is compliance-ready for the regulated-industry buyer; it is which two-of-three tool categories get the EMA-flow on day one of the rollout, how much senior-IT attention the per-connector provisioning workstream will cost the standing identity-governance program, and where the ID-JAG pattern lands inside the standing IdP contract that was negotiated against per-user-OAuth-consent friction six months ago. The teams that ask the right question this quarter buy themselves the per-role onboarding flow the new-hire walks into on day one and the audit-clean per-connector deactivation path the IT team operates against the standing IdP codepath; the teams that ask the wrong one buy themselves another year of per-connector compliance reviews against the per-user OAuth consent surface the EMA flow was shipped to neutralize.