Enterprise-Managed Authorization

What It Is

Enterprise-Managed Authorization, abbreviated EMA, is the extension to Model Context Protocol that Anthropic and Okta stabilized on June 18, 2026. It lets an enterprise admin authorize a connector once through the company’s identity provider and have every employee inherit the access the next time they open Claude. The user does not see an OAuth grant screen. The user does not click “Allow.” The connector simply appears, scoped by whichever group the employee belongs to inside the identity provider.

The mechanism is a JWT exchange called Identity Assertion JWT Authorization Grant, paired with Okta’s Cross App Access protocol. The identity provider issues a signed claim that proves who the user is. The MCP server accepts that claim and returns its own access token. No redirect through a per-server consent flow. No user-by-user permission grant. The launch list of MCP servers that support EMA on day one is Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase. Slack is staged next.

How It Actually Works

A typical OAuth grant has three steps: the user opens an app, the app sends the user to the identity provider, the user clicks “Allow.” EMA collapses the second and third steps into a single admin decision made months earlier. When the user opens Claude for the first time, Claude calls the identity provider with a request for that user’s connector access. The identity provider mints an Identity Assertion JWT carrying the user’s verified identity. Claude hands that JWT to each MCP server in turn. Each server validates the JWT against the public key on file, checks the user’s group membership against its own scoping rules, and returns an access token. The user sees the connectors appear in their sidebar. The user does not see any of the cryptographic handoff.

Why It Matters Right Now

Until June 18, every connector that a Claude user wanted to authorize was a separate OAuth grant. A 2,000-person company turning on seven connectors meant fourteen thousand OAuth flows, each one a small audit risk and a larger compliance question for the security team. Ramp ran the flagship EMA rollout on launch day: 2,000 employees provisioned through Okta with no individual consent prompts. Hubspot and Webflow followed. The era of clicking through to authorize an AI tool inside a regulated company is closing.

The shift matters now because the same window is producing parallel protocols at every other lab. Microsoft Scout already routes its MCP servers through Entra. Google is reportedly building a Workspace-native equivalent. The standard is being set in the next quarter. Whoever wires the most connectors first sets the default for how the agent economy actually integrates with the apps employees use.

How TWO Uses It

The temptation with EMA is to read it as a productivity win. Friction goes down, time-to-value goes up, IT teams move on to the next ticket. That reading misses what is actually shifting under the hood. EMA moves the consent decision out of the user’s hands and into the admin’s decision tree. Whatever the admin authorizes, the user inherits. That is fine for tools the operator genuinely wants connected. It is a low-grade exposure for tools the operator does not know are connected.

We use EMA the way we use a domain-wide service account: with a checklist, written down, of every connector we intend to be on. We do not use EMA to mean “all the connectors on the launch list, by default.” If a connector reaches your team without your knowledge, you cannot reason about what the agent can do on your behalf. The audit is the discipline. The seal is the act of pressing the discipline onto the org.

A Concrete Operator Scenario

A finance lead at a 400-person company gets a Slack ping that Claude now has the team’s Supabase tables as context. She did not approve the connection. She did not see an OAuth screen. The IT team turned on EMA on Tuesday, added the Supabase connector to the launch list, and walked away. Her question, the right question, is not “should we have done this?” The right question is “what else got turned on with it, and who is reading the audit log for the JWT exchanges this week?”

That is the operator-decision EMA makes urgent. The decision used to be granular and per-user. It is now structural and per-policy. The work is to write the policy down before the policy gets written for you by whatever was on the launch list. The right shape for that policy is a quarterly review: which connectors are enabled, which IdP groups inherit them, which audit events the security team has agreed to alert on. Without that review, EMA is just SSO with sharper consequences.

Related Concepts

• Model Context Protocol is the open protocol EMA extends.
• Non-Human Identity is the broader category EMA fits inside.
• AI Agent is the thing the connector is granting permission to.