On June 18, 2026, the Model Context Protocol project promoted Enterprise-Managed Authorization (EMA) from preview to stable. EMA is an MCP extension that lets organizations govern which MCP servers their developers can connect to through the same identity provider they already use for SSO, instead of asking every engineer to paste personal API keys into local agent configs.
For teams rolling out Claude, Claude Code, VS Code agents, or any MCP-compatible client at scale, EMA addresses the gap between "works on my laptop" and "passes security review."
The ID-JAG Flow
EMA builds on the Identity-Based Just-in-Time Authorization Grant (ID-JAG) pattern. In plain terms: when a user opens an MCP client and selects an enterprise-managed server, the client redirects through the org's IdP. The IdP issues a scoped grant tied to that user's identity and group membership. The MCP server validates the grant and exposes only the tools and data scopes the org pre-approved.
The developer experience target is authorize once, inherit everywhere. Sign in through Okta (or future IdPs) once per session or per policy interval, and every EMA-enabled MCP server in the catalog inherits that trust without separate OAuth dances per vendor. IT defines which servers appear in the catalog; users pick from an allowlist rather than discovering random community servers on the open internet.
Okta and Cross App Access
The first IdP integration ships with Okta via Cross App Access (XAA), Okta's mechanism for federating authorization across SaaS applications without duplicating user provisioning. Security teams already running Okta for GitHub, Slack, and Figma can extend the same group policies to MCP server access: eng gets Linear and Supabase tools, design gets Figma, support gets a narrower slice.
XAA matters because MCP clients are not traditional web apps loading in a browser tab. They are desktop agents, IDE extensions, and CLI harnesses that need token exchange patterns IdPs understand. Stable EMA means those flows are spec-backed and vendor-supported rather than one-off integrations per MCP server author.
Supported Clients
At stable launch, EMA-compatible MCP clients include:
- Claude (Anthropic's consumer and team clients with MCP connectors)
- Claude Code (terminal and IDE agent workflows)
- Visual Studio Code (GitHub Copilot and third-party MCP extensions)
More clients are expected as the extension stabilizes, but these three cover the majority of agent tooling web teams already pilot. If your org standardizes on one client, EMA still helps because server-side policies travel with the user identity rather than living in a local JSON file only one engineer maintains.
Supported Servers
Launch partners publishing EMA-ready MCP servers span the tools web teams touch daily:
- Asana and Atlassian for project and issue tracking
- Canva for design assets and brand workflows
- Figma for component libraries and design-to-code handoff
- Granola for meeting notes and context capture
- Linear for engineering ticket flow
- Supabase for database and backend operations
Each server implements the EMA extension on its MCP endpoint so org admins can toggle access centrally. Developers stop storing long-lived Supabase service keys in Claude Code config files; they inherit read/write scopes mapped to their Okta groups.
Security Context
EMA does not replace threat modeling for agent tool use. It replaces ad hoc credential sprawl. Our AutoJack coverage showed how localhost MCP bridges can exfiltrate data when agents run with excessive privileges. EMA pushes authorization decisions upstream to IdP policies and server-side scope limits, which is the right layer for enterprises even though prompt injection and over-broad tool calls remain client-side risks.
Pair EMA with server allowlists, audit logging on MCP tool invocations, and least-privilege scopes per group. Treat agent MCP access like API access with human approval workflows, not like installing a browser extension.
Where to Learn More
The MCP project maintains spec docs, server implementation guides, and a growing catalog on our MCP hub. If you are evaluating agents for a regulated environment, stable EMA is the signal that MCP is building enterprise primitives, not just developer convenience features.
Why It Matters for Web Developers
Individual developers love MCP because it connects agents to Figma files, Linear tickets, and Supabase rows in one session. Security teams hate MCP for the same reason: every connection is a new exfiltration path. EMA splits the difference. You keep composable tooling; IT keeps kill switches and group-based scopes.
Stable status means you can reference EMA in procurement docs and architecture reviews without the "preview only" caveat. Start with one server (Linear or Supabase is a common first pick), one Okta group, and one client. Expand the catalog once logging and offboarding workflows prove out.