An identity provider owner gets handed an AI rollout to sign off. The request arrives with a specification reference attached. The current version of that request names a June 2026 extension to the Model Context Protocol called Enterprise-Managed Authorization. Somebody has to check the claim before IT builds a control on it. MCP enterprise-managed authorization, as a phrase, is doing two jobs at once. It names something people believe the protocol defines. It also names features that individual AI vendors already ship under similar words. Those are not the same thing, and only one of them is in front of you this quarter.
Is there an MCP enterprise-managed authorization extension?
Elaichi cannot confirm one, and does not cite a specification page it has not read. Every statement Elaichi publishes about another party's document carries a link to that party's own page. It also carries the month the page was checked. A June 2026 extension by that name does not meet that bar here. So this post asserts neither its existence nor its absence.
You can still make the claim checkable in about ten minutes. An MCP extension has a reverse-DNS identifier, and usually a numbered proposal behind it. The two extensions Elaichi implements show the shape: MCP Apps is io.modelcontextprotocol/ui, and the Skills extension is io.modelcontextprotocol/skills, SEP-2640. Ask whoever cites Enterprise-Managed Authorization for three things: the identifier, the proposal number, and the dated protocol revision it landed in. Read those in the protocol's own specification rather than in a vendor deck. If none of the three comes back, there is nothing for your identity provider to implement yet.
What a dated MCP revision pins down, and what it does not
A revision date tells you the method set and the handshake. It does not tell you what your admin console can enforce. Elaichi's MCP endpoint speaks four revisions: 2026-07-28, 2025-06-18, 2025-03-26 and 2024-11-05. Clients on the three older revisions handshake with initialize, and clients on 2026-07-28 use server/discover. An unrecognized requested version falls back to 2025-03-26. When Elaichi acts as a client toward a remote MCP server, it speaks protocol version 2025-11-25. What one MCP request looks like on the wire covers the transport underneath all four.
Extensions sit on top of that and are opt-in per request. Elaichi attaches MCP Apps card data only for a client that negotiated the extension in the same request. Every other client gets byte-identical results. Elaichi declares the Skills extension on every 2026-07-28 request. On the older initialize it declares Skills only to a client that declared the extension first. Nothing in a revision string governs who may connect. That part is authorization, and in Elaichi it is OAuth plus your directory.
How Elaichi authorizes an AI client today
With browser OAuth, one grant per person. OAuth here is the sign-in that issues the token behind an AI client's calls. A grant is the stored record of one person approving one client for one organization. MCP is the protocol the client then uses to find and run tools.
The mechanics are ordinary and public. Every request to POST /mcp must carry an Elaichi MCP OAuth access token as a Bearer token. Nothing else is accepted, and a request without one gets HTTP 401. That refusal carries a WWW-Authenticate pointer to Elaichi's protected-resource document. Elaichi publishes three discovery documents at https://api.elaichi.ai: RFC 9728 protected-resource metadata, RFC 8414 authorization-server metadata, and OpenID Connect Discovery. Clients register themselves through RFC 7591 dynamic client registration at POST /oauth/register, which needs no Elaichi credential. Nobody pastes a client ID or secret. PKCE with S256 is mandatory and plain is not implemented. The RFC 8707 resource parameter is optional, and must sit on the https://api.elaichi.ai origin.
Two absences matter to an identity provider owner. Elaichi does not support Client ID Metadata Documents, so a client ID must be one Elaichi issued at registration. Elaichi supports only the authorization-code grant with PKCE, plus refresh. There is no device-code and no client-credentials grant. A new grant always needs a person approving a consent screen in a browser signed in to Elaichi. Token lifetimes are short by design: an access token lasts 1 hour, a refresh token 30 days, an authorization code 60 seconds, and a consent request 30 minutes. If the sign-in itself is what you are debugging, the OAuth error walkthrough covers the common refusals. The case for OAuth over pasted keys covers why Elaichi refuses an API key on this endpoint.
Where SAML, OIDC and SCIM already decide
Your directory decides three things in Elaichi: who may sign in, which role they land on, and when access stops. Elaichi's enterprise SSO supports exactly two protocols, SAML and OIDC. Each is implemented in-house, with no third-party identity vendor in the sign-in path. SSO here is single sign-on through your identity provider. SCIM is the provisioning standard your directory uses to create, update and deactivate accounts.
Enforcement is anchored to a verified domain, which an organization proves by publishing a DNS TXT record. When a verified domain's SSO connection is enforced, signing in any other way for an address on that domain is refused. The refusal is 403 sso_required, with the message "Your organization requires signing in with SSO" and a login URL to the identity provider. That check runs on social and email-code sign-in, signup and invite acceptance. Passkey sign-in is separately refused for such a domain with "Passkey sign-in is disabled. Use SSO." Only an active connection enforces: an inactive connection never blocks other sign-in methods, even with the enforced flag set. Removing the verified domain switches enforcement off. That is why adding, verifying, updating or removing one asks for a step-up confirmation from a browser session.
Provisioning carries roles, narrowly. Each verified domain and each SSO connection has an optional default role for people who join through it. A join with no default set lands on Member. A SCIM group-to-role mapping names at most one role, and never Org Owner. A member in several mapped groups gets the single most privileged of them rather than a union. Mappings are deferred: they change nobody until the next SCIM sync recomputes membership. SCIM 2.0 is mounted at /scim/v2 with Users and Groups. Its bearer token is minted only from a signed-in session, with a fresh step-up confirmation. Deprovisioning suspends a member rather than removing them. Suspension revokes their API tokens, MCP OAuth grants and SCIM tokens. Sending active:true reactivates them but does not bring the grants back; they consent again.
Timing is worth writing on the runbook. A role, team, restriction or access-grant change reaches every surface within about two minutes. Removing or suspending a member stops their MCP clients on the next call, as does revoking a grant, revoking a share or disconnecting an account.
What vendors ship under managed auth
The features that most resemble the phrase are per-client, not per-protocol. Each one covers only that client's own connectors. Anthropic documents Enterprise Managed Auth, which lets a Team or Enterprise organization connect members to a connector through its identity provider's single sign-on, with no per-connector consent screen; Anthropic says it does not work with Dynamic Client Registration (Anthropic, Enterprise Managed Auth, checked October 2026). Anthropic's own help articles disagree on its status. One calls it a beta for Team and Enterprise plans, while its dedicated article calls it generally available (Anthropic, Use connectors to extend Claude's capabilities, checked October 2026).
Client identity handling varies the same way. Anthropic says Claude uses a Client ID Metadata Document only when the authorization server advertises both client_id_metadata_document_supported: true and none in its token endpoint auth methods. Otherwise Claude falls back to dynamic client registration (Anthropic, connector authentication, checked October 2026). Cursor documents that for OAuth MCP servers it can use static client credentials from mcp.json instead of dynamic registration, with fixed redirect URLs (Cursor, MCP, checked October 2026). OpenAI documents Codex picking a Client ID Metadata Document when the server advertises support, and dynamic registration otherwise; a configured client ID skips registration (OpenAI, Codex MCP, checked October 2026). Microsoft documents VS Code trying dynamic client registration first, then falling back to a client-credentials workflow when the identity provider does not support it (VS Code, MCP extension guide, checked October 2026). Because Elaichi advertises no Client ID Metadata Document support, clients that check for it register with Elaichi through dynamic registration.
What this changes for an identity provider owner
Plan for the part you own and stop waiting on the part you do not. You own sign-in, through an enforced SSO connection on a verified domain. You own the role each new person lands on. That comes from a domain or connection default, or from a group-to-role mapping that carries exactly one role. You own the stop, through suspension or removal, which revokes grants and fails the person's AI clients on their next call. A buyer's guide for IT teams sets out the rest of what lands on your desk.
You do not own the approval. Each member still connects their own client once and approves their own grant on Elaichi's consent screen, in a browser, because Elaichi has no unattended grant type. That is the trade-off, stated plainly. A per-person approval is a step your directory cannot remove. It is also what makes every call attributable to a person rather than a shared bot. Provisioning stops short in a second way too. SCIM writes a member's status, profile name and role assignment. It configures nothing about their connections, toolboxes or which connectors they may reach. Tool reach is set in Elaichi, as roles and restrictions. Where provisioning stops and grants begin covers that boundary in detail, and the rules layer covers who may do what in which app.
When you can leave this alone
If one small team uses one app's own MCP server, signed in with that app's own SSO, there is nothing here you need. The vendor's server runs under that app's permission model, needs no second vendor, and your existing controls in that app still apply. The case for a shared address and one set of rules starts later. It starts when the same people reach five or six apps from three AI clients, and nobody can answer which account made a change. When an MCP gateway is premature makes that call honestly.
If you are past that line, the parts to configure are the directory ones: an SSO connection, a verified domain, a default role, and a group mapping per role. The provisioning use case shows where each sits, and the connector catalog shows what a role can be pointed at once the people are in.
