# MCP enterprise-managed authorization: what IT owns

> MCP enterprise-managed authorization gets cited as a spec feature. Here is what is checkable, and what SAML, OIDC and SCIM already decide for you.

**TL;DR** Elaichi does not cite a specification page it has not read, so it states neither that a June 2026 MCP enterprise-managed authorization extension exists nor that it does not. What is checkable today: Elaichi's MCP endpoint authorizes AI clients with browser OAuth, one grant per person, and your identity provider decides sign-in, the role someone lands on, and when access stops, through SAML, OIDC and SCIM. Provisioning never approves a client on a member's behalf, because Elaichi has no device-code or client-credentials grant.

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](/blog/json-rpc-over-streamable-http/) 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](/blog/mcp-oauth-errors/) covers the common refusals. [The case for OAuth over pasted keys](/blog/oauth-vs-api-keys-for-ai-agents/) 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](https://claude.com/docs/connectors/building/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](https://support.claude.com/en/articles/11176164-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](https://claude.com/docs/connectors/building/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](https://cursor.com/docs/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](https://learn.chatgpt.com/docs/extend/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](https://code.visualstudio.com/api/extension-guides/ai/mcp), 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](/blog/enterprise-mcp/) 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](/blog/identity-provider-scim-vs-mcp-grants/) covers that boundary in detail, and [the rules layer](/blog/mcp-governance/) 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](/blog/when-you-dont-need-an-mcp-gateway/) 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](/use-cases/provisioning/) shows where each sits, and the [connector catalog](/connectors/) shows what a role can be pointed at once the people are in.

## FAQ

### Does Elaichi support an MCP Enterprise-Managed Authorization extension?

Elaichi does not state that such an extension exists, or that it does not. Elaichi publishes a claim about another party's document only with a link to that party's own page and a check date, and no page meeting that bar has been read. The two MCP extensions Elaichi implements are MCP Apps (io.modelcontextprotocol/ui) and Skills (io.modelcontextprotocol/skills, SEP-2640), both negotiated per request. To check any extension claim, ask for its reverse-DNS identifier, its proposal number and the dated protocol revision it landed in.

### Can SCIM provisioning connect an employee's AI client for them?

No. SCIM provisioning in Elaichi writes a member's status, profile name and role assignment. It configures nothing about their connections, toolboxes or which connectors they can reach. Each person still connects their AI client once and approves their own OAuth grant on Elaichi's consent screen, in a browser. Elaichi supports only the authorization-code grant with PKCE plus refresh, with no device-code or client-credentials grant. SCIM deprovisioning suspends the member and revokes their grants, which fails their clients on the next call.

### Does enforcing SSO stop someone signing in to Elaichi another way?

Yes, for addresses on the verified domain the enforcement is anchored to. Signing in with a social provider or an emailed code, signing up, or accepting an invite is refused with 403 sso_required. The message reads "Your organization requires signing in with SSO" and carries a login URL to the identity provider. Passkey sign-in for that domain is refused with "Passkey sign-in is disabled. Use SSO." Only an active SSO connection enforces, and removing the verified domain switches enforcement off.

### How quickly does a role or deprovisioning change reach an AI client?

In Elaichi, a role, team membership, restriction or access-grant change reaches every surface within about two minutes. Removing or suspending a member is faster: it revokes their MCP OAuth grants, so their AI clients fail on the next call. Revoking a grant, revoking a share and disconnecting a connected account also take effect on the next call rather than when the current access token expires, because every MCP request re-reads the grant.

### Which MCP protocol revisions does Elaichi's endpoint speak?

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, clients on 2026-07-28 use server/discover, and 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.

## Read next

- [Enterprise MCP: a buyer's guide for IT teams](/blog/enterprise-mcp/) — Enterprise MCP for buyers: what changes when MCP goes from one laptop to a whole company, and what to ask a vendor before you sign.
- [Roles, Restrictions and ACLs in MCP: Three Layers](/blog/roles-restrictions-acls-three-mechanics/) — Roles restrictions and ACLs in MCP are three layers: a role says what a member may do, a restriction which tools they reach, an ACL who may use one connection.
- [What is an MCP control plane, and who needs one?](/blog/what-is-an-mcp-control-plane/) — An MCP control plane is one org-wide MCP endpoint that serves the tools, signs each person in and decides access on every call.