--- title: "MCP Enterprise Managed Authorization (EMA): What It Is and How Highflame Supports It · Highflame" description: "MCP Enterprise Managed Authorization (EMA) lets your identity provider decide which MCP servers an agent can reach via corporate SSO. How it works, and where it stops." doc_version: "0.1.0" last_updated: "2026-07-27T05:42:48.105Z" canonical: "https://www.highflame.com/blog/mcp-enterprise-managed-authorization" --- [← All articles](/blog.md) # MCP Enterprise Managed Authorization (EMA): What It Is and How Highflame Supports It Jun 20, 20267 min read Highflame Engineering ![MCP Enterprise Managed Authorization (EMA): What It Is and How Highflame Supports It](/blog/mcp-enterprise-managed-authorization/hero.png) The Model Context Protocol just shipped an extension called [Enterprise-Managed Authorization](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization). It is a big deal, and it validates a thesis we have been building on for a while. **MCP Enterprise Managed Authorization (EMA) is an extension to the Model Context Protocol that lets a company’s identity provider decide which MCP servers an agent may connect to**, brokered through corporate SSO instead of a hand-provisioned API key per server, per person. It governs admission, who gets in, not what the agent is allowed to do once it is inside. Here is the problem it solves. Today, when an employee wires an MCP client like Claude Code into a set of MCP servers, each connection is 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. Enterprise-Managed Authorization fixes the _admission_ step. The employee logs in once with their corporate identity (the same SSO they use for email and Slack), and the company’s identity provider, Okta or Entra or whatever you already run, decides which MCP servers that agent is allowed to reach. Authorized servers connect with no per-server prompts. Unauthorized ones never hand back a token at all. Revoke the person in the IdP and their access dies everywhere, immediately. ## **How It Works: SSO In, a Short-Lived Token Out** The mechanism is a new grant type. After the user signs in, the MCP client exchanges that login for an **Identity Assertion JWT Authorization Grant**, or ID-JAG, from the corporate IdP. Crucially, _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. The client then exchanges the ID-JAG for an access token from that server’s authorization server, and uses that token to make calls. ``` Agent -> corporate SSO login -> ID-JAG (IdP evaluates policy here) -> exchange ID-JAG for an access token -> call the MCP server ``` Our [Enterprise Managed Authorization guide](/learn/enterprise-managed-authorization.md) walks this same flow as an animated diagram, from the single sign-in through to the scoped, short-lived token. That is what enterprises have been asking for: control access from one place, turn a whole team’s access to a server on or off at once, and cut someone off everywhere the instant they leave, with a clear record of who was let into what. It is the model Highflame is built around, and the market is now standardizing on it. ## **What the Standard Covers, and Where It Stops** Read the spec carefully and one thing stands out: it is about **admission only**. It answers a single question (_which MCP servers may this agent connect to?_) and it answers it well. It does not address two other questions that decide whether an agentic deployment is actually safe: - **How does the server get the downstream credential** it needs to act on the user’s behalf, the GitHub token, the Slack token, the database credential? - **What is the agent allowed to do once it is inside?** Which specific tools, with which arguments, under which conditions? There are three distinct layers here, and the standard owns exactly one of them: Layer The question it answers Who owns it **Admission** Which servers may this agent connect to? The standard, via your IdP **Downstream credentials** How does the server act for the user? The gateway **Runtime authorization** What can each tool call actually do? **Wide open.** This is the hard part. The ID-JAG gets the agent through the door. It says nothing about what happens after. And “after” is where the incidents live. ## **A Valid Token Is Not a Safe Action** We have [written before](https://www.highflame.com/blog/authentication-isnt-enough) that authentication tells you _who_ made a request, never _whether the request should be allowed_. Enterprise-Managed Authorization is a big upgrade to the _who_: it ties that identity to corporate SSO, governs it from one place, and lets you revoke it everywhere at once. But it is still answering _who_, not _what_. An agent that is legitimately admitted to a database MCP server with a perfectly valid token can still be steered into running `DROP TABLE`, exfiltrating another tenant’s rows, or chaining a sequence of innocent-looking tool calls into something harmful, whether by a prompt injection buried in a document it read, a confused plan, or a compromised upstream. Admission is necessary. It is nowhere near sufficient. The damage happens at the _tool call_, long after the token was issued. ## **Highflame: Speak the Standard at the Door, Govern Everything Inside** This is exactly how Highflame is architected, and the new standard slots into it cleanly. **At the identity layer, we already speak the standard.** Highflame’s open-source identity engine, [ZeroID](https://github.com/highflame-ai/zeroid), is the MCP Authorization Server in this flow, and it runs today. It validates an ID-JAG against your corporate IdP, maps the identity to a governed Highflame principal (failing closed if it can’t), and mints the audience-restricted access token the agent actually uses. Its authorization-server metadata advertises the ID-JAG grant profile, so any compliant client discovers the flow on its own. You can run Highflame as the enterprise IdP for agents, or sit it behind Okta or Entra and add what their tokens don’t carry: how far the action is delegated from a human, and how much the agent should be trusted. Either way the token an agent presents is a first-class, governed Highflame identity, not an opaque pass. **At the runtime layer, we own what the standard leaves open.** Every tool call an admitted agent makes flows through the Highflame gateway and is checked _at the moment of the call_: not just “is this agent allowed in,” but “should this specific call, with these arguments, be allowed for this principal right now.” The gateway reads what actually moves through each request and response, and it notices when an agent starts drifting from the task it was admitted to do. This is the layer that is hard to get right, and it is where agentic security is actually won or lost. ## **One Identity, End to End** Because admission and runtime share a single identity model, the chain holds together. The corporate login feeds the ID-JAG. The ID-JAG resolves to a Highflame principal carrying the account, project, role, and trust attributes our policy engine keys on. Every downstream tool call is authorized against _those_ attributes. Revoke the user at the IdP and the whole chain, admission and runtime alike, goes dark. It is one identity, governed from SSO all the way to the individual tool call, with an audit trail that covers the whole path. That is the difference between knowing an agent was allowed in and knowing exactly what it did once it was. ## **A Tailwind, Not a Finish Line** We are glad to see Enterprise-Managed Authorization land. It went stable in mid-2026 with Okta as the first identity provider, and Anthropic’s Claude connectors already provision through it. The market is standardizing on exactly the [admission model](/learn/enterprise-managed-authorization.md) we build for. Highflame supports it today and keeps it interoperable: it validates an Okta-minted ID-JAG the same way it validates its own, for any compliant MCP client and any corporate IdP. But adopting the standard is where an enterprise’s agent-security story starts, not where it ends. Letting the agent in was never the hard part. It is everything the agent does once it is through the door, and that is the part we own. ## **Frequently asked questions** ### **What is MCP Enterprise Managed Authorization (EMA)?** An extension to the Model Context Protocol that lets a company’s identity provider decide which MCP servers an agent may connect to, brokered through corporate SSO instead of a per-server API key for each 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 and issues an ID-JAG, which the MCP client exchanges for an access token to the specific server. ### **Does EMA control what an agent can do after it connects?** No. EMA governs admission: which servers an agent is allowed to reach. It does not decide which tool calls the agent may make once connected. That runtime, per-tool-call authorization is a separate layer. ### **Does Highflame support MCP EMA?** Yes. Highflame validates an IdP-minted ID-JAG the same way it validates its own, for any compliant MCP client and corporate identity provider, and adds the per-tool-call authorization layer that EMA leaves open. * * * _Building agentic systems and trying to figure out where authorization actually has to live? [Talk to us](https://www.highflame.com/contact)._ Highflame Engineering Engineering and research on agent identity, runtime policy, and securing autonomous AI at Highflame. ▸ Continue reading - [ ![Highflame + Tailscale Aperture Now Blocks Risky AI Traffic in Real Time](/blog/highflame-tailscale-aperture-now-blocks-risky-ai-traffic-in-real-time/hero.png) ProductJun 01, 2026 #### Highflame + Tailscale Aperture Now Blocks Risky AI Traffic in Real Time ](/blog/highflame-tailscale-aperture-now-blocks-risky-ai-traffic-in-real-time.md) - [ ![The Uniformed Guard Problem: Why AI Agent Sandboxes Need Identity, Not Just Policy](/blog/the-uniformed-guard-problem-why-ai-agent-sandboxes-need-identity-not-just-policy/hero.webp) ProductMay 04, 2026 #### The Uniformed Guard Problem: Why AI Agent Sandboxes Need Identity, Not Just Policy ](/blog/the-uniformed-guard-problem-why-ai-agent-sandboxes-need-identity-not-just-policy.md) - [ ![Who Sent You? Solving the Agent Identity Crisis with Highflame ZeroID](/blog/who-sent-you-solving-the-agent-identity-crisis/hero.png) ProductApr 09, 2026 #### Who Sent You? Solving the Agent Identity Crisis with Highflame ZeroID ](/blog/who-sent-you-solving-the-agent-identity-crisis.md) ## Start securing your agents today. [Book a demo](/contact.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).