Standard MCP authorization is user-scoped and interactive: every user authorizes every server, one consent flow at a time. This is fine for consumers but unworkable at enterprise scale. Onboarding becomes a checklist of consent screens, security teams can't enforce or audit policy, and work and personal identities blur together.

EMA makes your identity provider the decision-maker for MCP access. Admins define policy once: which groups get which tools, under which conditions. Users sign in with their corporate identity and every authorized MCP server connects automatically, scoped to the groups and roles they already have on day one. No per-server consent and nothing to configure.

Under the hood, EMA runs on the[ _Identity Assertion JWT Authorization Grant_](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/) _Identity Assertion JWT Authorization Grant_ (ID-JAG), an IETF OAuth draft. Instead of a consent dance between apps, the client exchanges its SSO identity at the IdP for a short-lived, signed, audience-bound assertion that names exactly who is acting on whose behalf. The MCP server's authorization server trades that assertion for a scoped access token, and the request goes through. Policy lives at the IdP. The delegation chain lives in the token. Auditors get a real answer to "who approved this, and who's accountable?"

That's the shift. Agents calling tools on behalf of users is a delegation problem, and enterprises have been solving it with bearer tokens and API keys that flatten the chain. EMA keeps the chain intact, end to end, in a standard.

And the resource side is coming online too. Okta is the first supported IdP through its Cross App Access (XAA) implementation. Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase already accept EMA on the server side, with more on the way. That's real momentum. But accepting an ID-JAG is work each server has to build, and it's early. Plenty of MCP servers, first-party and third-party alike, won't get there for a while, if at all, and the ones you don't own you can't put on a schedule.

The exchange that powers EMA has to start somewhere: a client takes the ID token it got from SSO and trades it at the IdP for an ID-JAG. EMA-aware clients like Claude, Claude Code, Cowork, and VS Code do this themselves.

Now count the clients in your organization that aren't on that list. The internal agent your team built in Q1. The CI job that calls an MCP server to file tickets. The scripts, the notebooks, the older MCP clients, the vendor tool that won't ship EMA support until next year, if ever. Every one of them holds an API key or OIDC client credential, often on a user's desktop.

That's the first gap: **the downstream resource requires an ID-JAG, and the client can't produce one.** The MCP server did the right thing. The IdP is ready. And the request still fails at the front door.

Now flip it around. Plenty of MCP servers won't accept an ID-JAG. The one your data team stood up last quarter. The third-party server on its own EMA timeline, if it has one at all. The SaaS tool that authenticates with its own token and has no reason to care about your IdP. A compliant client produces a perfectly good ID-JAG, and the server has nowhere for it to land. That's the second gap: **the client did everything right, and the server can't meet it.** Same failure, mirror image: the IdP is ready, the client did its part, and the request still dies at the door.

Two gaps, mirror images of each other, one root cause. A standard only works when both ends speak it, and your internal fleet is behind on both.

The options look grim. Retrofit the token exchange into every internal client, and stand up a compliant authorization server in front of every internal server: security-critical OAuth code, duplicated across codebases in five languages, on both ends. Or carve out exceptions so the stragglers bypass EMA, which quietly recreates the credential sprawl you adopted EMA to kill. Or wait, and let half your fleet sit unreachable behind a standard it can't speak.

This isn't a new problem. It's where API authentication stood a decade ago, when every service and client implemented its own auth and every implementation drifted. The industry's answer then is the answer now: cross-cutting security belongs at the traffic layer, not scattered through application code. Connectivity is infrastructure. It was true for APIs. It's true for tokens.

An AI gateway already sits in exactly the right place: between every client you can't change and every resource that now speaks ID-JAG. It terminates every request. It's where you already enforce authentication, rate limiting, and observability. And because it sits inline on both sides, it can stand in for whichever end is behind.

On the client side, it upgrades the credential in flight, once, for every client. The gateway accepts what the client already has (its SSO ID token), performs the ID-JAG exchange, and presents the credential the resource requires. One implementation of verification, exchange, caching, and replay handling, tested and patched in one place, instead of a copy in every client codebase. Your clients keep sending the token they've always had. Your resources get the credential they now demand. Neither side changes.

On the server side, it does the mirror image. It enforces the EMA decision at the edge, checking the caller's assertion against your IdP policy before the request reaches the server, then presents whatever credential the upstream actually requires. For a server that speaks standard OAuth, that's a token it already trusts. For one that runs its own auth, it's that server's native credential, brokered by the gateway and never handed to the agent. Either way, the server behind it never learns EMA exists. It just receives a request it already knows how to trust.

Either way, the gateway acts as a named broker, not invisible middleware. ID-JAG has a delegation model built for exactly this. The IdP explicitly authorizes the gateway as a broker for specific apps and resources, and the gateway appears in the token's actor chain. Redemption is bound to it, so an intermediary the IdP didn't authorize gets rejected. The gateway's trust is explicit in the token, not ambient in the network. Your audit trail shows the user, the client acting for them, and the broker in the middle. No holes.

There's a governance dividend, too. Because every MCP call crosses the gateway with a full delegation chain attached, the traffic layer becomes the one place you can see, meter, and control agent access across the company: which agent, which user, which tool, which scope. Speed and governance stop being a tradeoff. You get both, at the same layer.

The new id-jag-relay plugin turns Kong AI Gateway into that trusted broker. The name is the behavior: Kong acts as the ID-JAG-capable client for the ones that can't.

The client calls through Kong with its OIDC ID token. Kong validates that token locally: it checks the signature against the IdP's public keys (the JWKS Kong fetches once and caches) plus the issuer, audience, and expiry. There's no per-request call to Okta to do it. A bad signature fails closed, so the request gets a `401` and never touches the upstream. 

The network calls come next: Kong exchanges the ID token at the IdP's token endpoint for an ID-JAG that names the user, the original client app, and Kong as the actor, then redeems that assertion at the MCP server's authorization server for a scoped access token (both results cached). Kong proxies the request upstream carrying that token, spoofable identity headers stripped, and the MCP server validates exactly what it was built to validate: a standard access token from its own trusted authorization server.

Here's the full path a request takes:

Configuration is a few lines:

plugins:
  - name: id-jag-relay
    config:
      audience: https://mcp.example.com
      id_token_audiences: ["my-client-app"]
      trusted_idps:
        - issuer: https://idp.example.com
          client_id: kong-broker
          client_secret: "{vault://env/kong-broker-secret}"

Notice what's absent? The client codebase stays untouched. The resource is already done; it speaks ID-JAG. The access policy lives in the IdP, where your security team can see it. The protocol burden lives in the gateway, once, for every client in front of it.

The same gateway closes the gap on the other end, for any MCP server that isn't EMA-ready, first-party or third-party, on your network or a vendor's. On the way in, Kong enforces the EMA decision: is this user, acting through this agent, allowed to call this tool? That answer comes from your IdP policy, centrally, before the request ever reaches the server. On the way out, Kong hands the server exactly the credential it expects and keeps it away from the agent: a standard token for a server that speaks OAuth, or the server's own native credential for one that doesn't.

The server doesn't change, and you don't wait on its roadmap. The agent authenticates once, to Kong, with its EMA-scoped identity. Whatever the server wants on the far side, the two credentials only ever meet inside the gateway. From your IdP's point of view, every server behind Kong now falls under the same policy and the same audit trail.

EMA gives enterprise MCP the answers that were missing: your IdP approves the access, and the token names everyone accountable. But a standard only works when both ends speak it, and for years your fleet won't, on either end. The gateway is how the standard meets reality, the same reason API auth ended up there. It produces the ID-JAG for the clients that can't, and enforces it in front of the servers that can't, brokering the right credential on every hop and keeping the full delegation chain intact end to end.

The standard is ready. Your fleet doesn't have to be.

*Read the*[* *_*EMA extension spec*_](https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization)* *_*EMA extension spec*_*, the*[* *_*ID-JAG draft*_](https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/)* *_*ID-JAG draft*_*, or talk to us about running MCP through Kong AI Gateway.*