What is Enterprise-Managed Authorization (EMA)?

Single sign-on solved one problem well: a person signs in once and gets into every work app. Then AI agents showed up, and they don't sign in. They ask for access.

Every time someone connects an agent like Claude or Cursor to Slack, Notion or Linear, they click through an OAuth consent screen. That app hands the agent a token, and the company's identity provider never sees it. Multiply that by every employee, every agent and every app, and you get hundreds of grants that IT never approved and can't easily revoke.

Enterprise-Managed Authorization (EMA) is the fix the industry is converging on. It moves the decision about agent access back to the place that already decides human access: the identity provider.

What is Enterprise-Managed Authorization?

Enterprise-managed authorization is a way for a company's identity provider (IdP) to decide which AI agents and apps can access which other apps on an employee's behalf. Instead of each employee approving each connection, IT approves it once in the IdP. Employees then get access through the groups and roles they already have.

The pattern goes by a few names depending on who is talking about it:

‍

If you remember one thing: ID-JAG is the token, and EMA is what you get when agents, apps and the IdP all agree to use it.

How EMA works, step by step

EMA adds one step to a normal sign-in: before an agent talks to an app, it asks the IdP for a signed permission slip, then trades that slip for a token from the app. No browser redirect to the app and no consent screen.

The employee never sees the app's consent screen: the IdP makes the call in step 3, and the app trusts the IdP's signature in step 4.

1. The employee signs in to the agent with SSO. The agent (the MCP client, such as Claude) gets an ID token from the company IdP, the same way any SSO app does.
2. The agent asks the IdP for an ID-JAG. It sends the ID token back to the IdP in an OAuth token exchange and names the app it wants to reach.
3. The IdP checks policy. Is this person in a group allowed to use this app through this agent? If not, no token is issued and the agent never gets one.
4. The agent trades the ID-JAG for an access token. It presents the ID-JAG to the app's own authorization server, which checks the signature against the IdP's public keys and issues a normal access token.
5. The agent calls the app. From here it is ordinary OAuth. Tokens can be short-lived, so access ends soon after IT removes someone in the IdP.

Here is what step 2 looks like on the wire, from the IETF draft:

  
POST /oauth2/token HTTP/1.1
Host: acme.idp.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
&requested_token_type=urn:ietf:params:oauth:token-type:id-jag
&audience=https://acme.chat.example/
&resource=https://api.chat.example/
&scope=chat.read+chat.history
&subject_token=eyJraWQiOiJzMTZ0cVNtODhwREo4VGZCXzdrSEtQ...
&subject_token_type=urn:ietf:params:oauth:token-type:id_token
  

The ID-JAG that comes back is a short-lived JWT with the header type oauth-id-jag+jwt. Decoded, an illustrative payload carries who the user is, which app it is for, and which client may use it:

  
{
  "iss": "https://acme.idp.example/",
  "sub": "U019488227",
  "aud": "https://acme.chat.example/",
  "client_id": "f53f191f9311af35",
  "jti": "9e43f81b64a33f20116179",
  "exp": 1792500300,
  "iat": 1792500000,
  "resource": "https://api.chat.example/",
  "scope": "chat.read chat.history"
}
  

Step 4 is a standard JWT bearer grant at the app:

  
POST /oauth2/token HTTP/1.1
Host: acme.chat.example
Content-Type: application/x-www-form-urlencoded

grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
&assertion=eyJhbGciOiJIUzI1NiIsI...
  

Who supports EMA today

EMA only works when all three parties support it: the IdP, the agent and the app. As of October 2026, the most complete chain runs through Okta and Claude.

‍

Support is moving monthly, so check each vendor's docs before you plan a rollout around it.

If you build an app or MCP server

The app side is the piece most teams can add today. Your authorization server needs to accept ID-JAGs: validate the signature against the IdP's keys, check the audience and expiry, and map the user to an account. WorkOS added EMA support to MCP Auth in September 2026, so MCP servers built on AuthKit can accept IdP-managed access without building that exchange themselves. Setup is in the MCP Auth docs.

What EMA changes for IT teams

The big shift is that agent access becomes part of the same lifecycle as human access. Onboarding, role changes and offboarding all happen in one place.

‍

A few practical takeaways:

• Treat agent connections like app assignments. Decide which groups may use which agent with which app, the same way you assign SaaS today.
• Shorten token lifetimes. Revocation in the IdP stops new ID-JAGs immediately, but an access token already issued lives until it expires. Short lifetimes close that gap.
• Keep a list of the apps your teams actually use with agents. EMA only covers apps that support it, so anything outside that list still runs on per-user consent or API keys.

What's still missing

EMA is early, and a few gaps matter if you plan around it today.

• IdP choice is narrow. Claude supports only Okta so far. Teams on Google Workspace, Microsoft Entra or a password manager as their main identity system mostly can't use EMA yet.
• Every app has to trust your IdP. The app's authorization server must accept ID-JAGs signed by your IdP. That means each app decides which issuers it trusts, and an app that hasn't added yours will reject the token.
• The spec is still a draft. The ID-JAG IETF draft is on version 04, and the MCP extension is opt-in for both clients and servers.
• It governs access, not actions. EMA decides whether an agent can reach an app and with which scopes. It doesn't decide whether a specific action, like deleting a channel, should need a human's approval.
• Coverage is partial. Plenty of tools agents touch, like internal APIs, databases and CLIs, sit outside EMA entirely and still run on long-lived keys.

Frequently asked questions

Is EMA the same as SSO? No. SSO signs a person in to an app. EMA lets the IdP authorize an agent to call another app on that person's behalf. EMA builds on SSO: the agent needs the ID token from an SSO sign-in to start the flow.

Is EMA the same as Cross App Access? They describe the same protocol. Cross App Access is Okta's name for it; enterprise-managed authorization is the name in the MCP extension and in Claude.

Does EMA replace OAuth? No. It is an OAuth extension. The agent still ends up with a normal OAuth access token. EMA changes who approves that token: the IdP instead of the end user.

Do employees ever see a consent screen? Not for apps IT has set up through EMA. Connectors appear already authorized when they sign in.

What happens when someone leaves the company? IT removes them in the IdP. The IdP stops issuing ID-JAGs for them right away, and any access tokens already issued stop working when they expire.

The takeaway

Agents made per-user consent unmanageable. EMA moves the decision back to the IdP, where human access is already managed. The standard is real and shipping today, but it only works end to end when your IdP, your agents and your apps all speak it.

That's the gap we're working on with WorkOS Passport, a workforce identity provider for employees and AI agents. It's in early access now at workos.com/passport.

Sources

• Identity Assertion JWT Authorization Grant, draft 04, IETF, May 2026
• Enterprise-Managed Authorization extension, Model Context Protocol
• Centrally manage authorization for MCP connectors, Anthropic, June 2026, updated August 24, 2026
• Okta brings first-class identity to AI agents with Agent SSO, Okta, August 24, 2026
• Okta expands Cross App Access ecosystem, SiliconANGLE, June 23, 2026
• Enterprise-managed authorization (EMA) for MCP Auth, WorkOS changelog, September 4, 2026