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.
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 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 walks the full flow.