--- title: "Enterprise Managed Authorization (EMA): What It Is and How It Works · Highflame" description: "Enterprise Managed Authorization (EMA) lets your identity provider decide which MCP servers an agent can reach through corporate SSO. What it covers, and where it stops." doc_version: "0.1.0" last_updated: "2026-07-24T06:09:59.500Z" canonical: "https://www.highflame.com/learn/enterprise-managed-authorization" --- [Home](/index.md)·[Learn](/learn.md)·Enterprise Managed Authorization (EMA) Reference # Enterprise Managed Authorization (EMA) Enterprise Managed Authorization (EMA) is an extension to the Model Context Protocol that lets a company's identity provider decide, through corporate SSO, which MCP servers an agent is allowed to connect to. It replaces a hand-provisioned API key per server with one centrally governed admission decision. It governs admission only, not what the agent does once it is connected. Highflame EngineeringLast reviewed July 2026 Key takeaways - EMA moves MCP access from a per-server API key to one decision made by your IdP through corporate SSO. - The mechanism is the ID-JAG grant: sign in once, the IdP evaluates policy, the client exchanges the grant for a server access token. - EMA governs admission (which servers an agent may reach), not which tool calls it may make once inside. - Revoke the person in the IdP and their agent's access dies everywhere at once. ## The problem EMA solves When someone wires an MCP client like Claude Code into a set of MCP servers, each connection is normally authorized one server at a time, by the individual. Someone hand-provisions a credential per server, per person. Onboarding means manually authorizing a dozen services; offboarding means hunting down and revoking a dozen credentials and hoping you got them all. Security teams have no single place to say “engineers may use the GitHub MCP server, but not the production-database one.” It is API-key sprawl with a compliance problem attached. ## How it works: SSO in, a short-lived token out EMA fixes the admission step. The employee signs in once with their corporate identity, the same SSO they use for email, and the company’s identity provider decides which MCP servers that agent may reach. The mechanism is a grant type. After the user signs in, the MCP client exchanges that login for an Identity Assertion JWT Authorization Grant (an ID-JAG) from the corporate IdP. The IdP evaluates policy at that moment: group membership, role, conditional-access rules. If the agent is allowed to reach a given server, the IdP returns an ID-JAG, which the client exchanges for an access token from that server’s authorization server, and then uses to make calls. Authorized servers connect with no per-server prompts. Unauthorized ones never hand back a token. Revoke the person in the IdP and their access dies everywhere at once. FIG · ID-JAG GRANT FLOW EMA ADMISSION · ONE SIGN-IN → SCOPED TOKEN ## What EMA covers, and where it stops Read the spec closely and one thing stands out: it is about admission only. There are three distinct layers, and EMA owns exactly one. Layer The question it answers Who owns it Admission Which servers may this agent connect to? EMA, via your IdP Downstream credentials How does the server act on the user’s behalf? The gateway Runtime authorization What can each tool call actually do? A separate layer EMA leaves open The ID-JAG gets the agent through the door. It says nothing about what happens after, and “after” is where the incidents live: an agent legitimately admitted to a database server with a valid token can still be steered into running `DROP TABLE` or exfiltrating another tenant’s rows. ## EMA and runtime authorization EMA is a real upgrade to the _who_: it ties agent access to corporate SSO, governs it centrally, and revokes it everywhere at once. But it still answers _who_, not _what_. The damage happens at the tool call, long after the token was issued, so admission needs to be paired with request-time [authorization](/learn/ai-agent-authorization.md) that decides each individual action against policy. ## How Highflame supports EMA Highflame speaks the standard at the door and governs everything inside. Its open-source identity engine, ZeroID, acts as the MCP Authorization Server in this flow today: it validates an ID-JAG against your corporate IdP, maps the identity to a governed principal, and mints the access token the agent actually uses. You can run Highflame as the agent IdP or sit it behind Okta or Entra. Then every tool call the admitted agent makes is checked at the moment of the call, which is the runtime layer EMA deliberately leaves open. The [deep-dive post](/blog/mcp-enterprise-managed-authorization.md) walks the full flow. ## Frequently asked questions What is Enterprise Managed Authorization (EMA)? An extension to the Model Context Protocol that lets a company's identity provider decide, via corporate SSO, which MCP servers an agent may connect to, instead of provisioning a separate API key per server per person. What is an ID-JAG? An Identity Assertion JWT Authorization Grant. After a user signs in through corporate SSO, the identity provider evaluates policy (group, role, conditional access) and issues an ID-JAG, which the MCP client exchanges for an access token to the specific server. Does EMA control what an agent does after it connects? No. EMA answers admission: which servers an agent is allowed to reach. It does not decide which tool calls the agent may make once connected, or with which arguments. That runtime, per-tool-call authorization is a separate layer EMA leaves open. Which identity providers support EMA? The standard went stable in mid-2026 with Okta as the first identity provider, and it is designed to work with any compliant IdP and MCP client. Highflame validates an IdP-minted ID-JAG the same way it validates its own. Highflame Engineering Engineering and research on agent identity, runtime policy, and securing autonomous AI at Highflame. ▸ Related - [Agent Authorization (guide)](/learn/ai-agent-authorization.md) - [MCP Enterprise Managed Authorization (deep dive)](/blog/mcp-enterprise-managed-authorization.md) - [MCP gateway (glossary)](/glossary/mcp-gateway.md) ## See agent governance against your own agents. [Book a demo](/contact.md) [Explore the platform](/platform.md) ## Sitemap Full site map: [/sitemap.md](https://www.highflame.com/sitemap.md). Machine index: [/sitemap-index.xml](https://www.highflame.com/sitemap-index.xml).