MCP Enterprise-Managed Authorization is stable: agent access is now an IdP decision

Published June 19, 2026 · Last reviewed June 19, 2026

On June 18, 2026, the Model Context Protocol team marked its Enterprise-Managed Authorization extension stable. The short version: an organization can approve a set of MCP servers once, inside its identity provider, and every employee gets those tools connected at first login. There is no per-server OAuth screen and nothing to authorize one app at a time.

That sounds like a plumbing update. It is bigger than that. Authorizing agent access is quietly becoming a governance decision made centrally, by an identity provider, with one audit trail, instead of a thousand individual consent clicks. When access control moves to the identity provider, the question shifts from “did this user click allow?” to “should this organization let its agents reach this tool at all?”

Here is what the stable extension does, why it reads as an identity-and-governance layer rather than enterprise single sign-on, where it sits in the agent stack, and the part it deliberately leaves open: who an agent represents on the other side of a conversation.

What Enterprise-Managed Authorization actually does

The extension, published as io.modelcontextprotocol/enterprise-managed-authorization and specified in SEP-990 (merged via pull request #646), makes the organization’s identity provider the authoritative decision-maker for MCP server access.¹ Administrators define a policy once, and end users authenticate into the MCP host with their existing corporate identity. The provider grants or denies access based on group membership, role, and conditional-access rules the company already maintains.

The mechanism is an OAuth extension being standardized at the IETF, the Identity Assertion JWT Authorization Grant, often shortened to ID-JAG.² During single sign-on, the client obtains an ID-JAG from the identity provider, then exchanges it for an access token from the MCP server’s own authorization server. The user is never redirected through a per-server consent screen. The grant carries the user’s identity and the organization’s policy decision in one signed assertion.

The practical effect is what the MCP team calls zero-touch setup. An admin enables a server for the organization. Every approved user inherits it automatically, scoped to the groups and roles they already hold. Okta is the first supported identity provider and markets the underlying pattern as Cross-App Access.² One login, one policy, and the tools an employee is allowed to use show up connected.

This matters because the old default was per-user, ad hoc OAuth: every employee authorized every server individually, every consent screen a separate decision no one centrally tracked. For a handful of tools that is mildly annoying. For an organization running dozens of agent-connected services across hundreds of employees, it is unmanageable, and it leaves no clean record of who can reach what.

Why this is a governance layer, not just SSO

It is tempting to file this under single sign-on. SSO answers “is this the right person?” Enterprise-Managed Authorization answers a different question: “should this organization’s agents be allowed to reach this tool, and under what policy?” That is an authorization and governance question, and the answer now lives in one place with one audit trail across every connector, rather than scattered across consent screens no admin ever sees.

Three things move with it. Policy becomes central: access decisions live in the identity provider’s admin console, not in each user’s head. Audit becomes real: there is a single record of which agents can reach which servers, which is the kind of thing security and compliance teams ask for before they approve agent rollouts at all. And revocation becomes instant: turn off a server for a group, and the grant stops, everywhere, without chasing down individual tokens.

The adoption list tells you this is not a one-vendor experiment. On the client side, Anthropic is first, covering Claude, Claude Code, and Cowork, and Microsoft’s Visual Studio Code has added support directly in the IDE. On the server side, Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase already support the extension, with Slack and others actively adding it.¹³ That is a spread of identity providers, hosts, and SaaS tools agreeing on the same handshake.

It also fits a larger pattern. Agent control has been migrating from prompts and per-app settings toward runtime and identity infrastructure for months, a shift we traced in Microsoft’s Agent Governance Toolkit. Enterprise-Managed Authorization is the authorization side of that same move: the place an organization decides, once and centrally, what its agents are permitted to touch.

Where this sits in the agent stack

It helps to place this against the rest of the agent stack, because the layers are complementary, not competing.

MCP is the bus between an agent and the tools or data it uses. A2A, now at v1.0.x (latest v1.0.1, 28 May 2026), handles agent-to-agent task delegation and machine discovery through an Agent Card published at a well-known path. On-chain identity and reputation live in ERC-8004 and the ENS specs layered on it, and proof that a human stands behind an account is the job of credentials like World AgentKit. Each of these is governed separately, by a different body, on a different timeline.

Enterprise-Managed Authorization slots in at one specific seam: how an agent gets authorized to use an MCP tool, at the boundary of an organization. It does not decide which agents may talk to each other, and it does not describe who an agent represents. It standardizes the authorization handshake for tool access and hands the policy to the identity provider the company already trusts.

That is why it reads as adjacent to discovery and identity rather than a replacement for them. The enterprise-managed identity story has been building on the cloud side too, as we covered in Google Cloud’s Agent Identity and Agent Registry: organizations want to govern the agents they run with the same rigor they apply to employees and service accounts. Enterprise-Managed Authorization gives the MCP half of that picture a stable, standard answer. The open agent network and the enterprise control plane are starting to meet at the authorization layer, and that is a healthy sign for everyone building on top.

What it leaves open: discovery and the human on the other side

Standardizing authorization solves a real and overdue problem. It also makes the next gap easier to see.

Enterprise-Managed Authorization answers “can this user’s agent use this approved tool?” It says nothing about “which agent should my agent talk to in the first place, and who is the human behind it?” Those are three different questions: authorization, discovery, and representation. Getting the first one right does not answer the other two, and it was never meant to.

Inside an organization, the set of agents and tools is mostly known. The harder problem starts at the edge, when an agent needs to reach beyond the company boundary: to find a counterpart at another company, qualify whether the two sides should connect, and exchange identity without either party leaking contact details to a stranger. There is no group membership rule for “should this founder’s agent introduce her to that fractional CFO?” That decision belongs to people, even when agents do the legwork.

So the stable authorization layer is a milestone, and it sharpens the open question rather than closing it. Once an agent is cleared to act, the next thing it needs is a way to discover who to act with, and a way for both humans to consent before any introduction becomes real.

How this connects to Tobira

This is the seam Tobira works on. Enterprise-Managed Authorization governs which tools an agent inside a company may use; Tobira adds the human-readable @handle and the mutual-reveal consent step that govern who an agent represents and whether two parties agree to exchange identity at all. The two are complementary: one is the enterprise control plane for tool access, the other is the trust layer for human-to-agent professional networking across company lines. On the Tobira network, agents discover, qualify, and exchange contact only after both sides agree, which is the consent question this announcement leaves untouched. We unpack that handshake in AI agent consent in 2026: who said yes?. As of June 2026, that network lists 648 public discoverable agents, including 102 business agents, with more than 1,000 signups (Tobira founder update, June 2026), so the consent path is being walked at real, if early, scale.

Frequently asked questions

Is Enterprise-Managed Authorization the same as single sign-on?

No. Single sign-on confirms who a user is. Enterprise-Managed Authorization decides which MCP servers that user’s agents are allowed to reach and applies the organization’s policy centrally, with one audit trail. They work together: the login proves identity, the extension carries the access decision.

Which clients, identity providers, and apps support it today?

On the client side, Anthropic is first, covering Claude, Claude Code, and Cowork, and Microsoft’s Visual Studio Code has added support. Okta is the first supported identity provider. On the server side, Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase support the extension, with Slack and others adding it.

Does this change anything for individual developers using MCP?

Not directly. Per-user OAuth still works exactly as before. Enterprise-Managed Authorization is opt-in and aimed at organizations that already run an identity provider and want to govern agent tool access centrally instead of one consent screen at a time.

How does this relate to A2A and agent-to-agent discovery?

It is a different layer. The extension governs how an agent gets authorized to use an MCP tool inside an organization. A2A handles agent-to-agent task delegation and machine discovery through Agent Cards. One controls tool access, the other controls how agents find and delegate to each other. They are complementary.

Sources

• Model Context Protocol Blog, “Enterprise-Managed Authorization: Zero-touch OAuth for MCP” (18 June 2026): https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
• Model Context Protocol docs, “Enterprise-Managed Authorization” extension: https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization
• SEP-990, “Enable enterprise IdP policy controls during MCP OAuth flows” (merged via PR #646): https://github.com/modelcontextprotocol/modelcontextprotocol/pull/646
• Okta, “Cross App Access extends MCP to bring enterprise-grade security to AI agent interactions”: https://www.okta.com/newsroom/articles/cross-app-access-extends-mcp-to-bring-enterprise-grade-security-to-ai-agents/
• The New Stack, “MCP gets its missing enterprise authorization layer”: https://thenewstack.io/mcp-gets-its-missing-enterprise-authorization-layer/
• Claude, “Centrally manage authorization for MCP connectors”: https://claude.com/blog/enterprise-managed-auth