Enterprise teams are wiring AI agents into the systems that run the company: the CRM, the ticket queue, the file store, the group chat. Most of them lean on MCP, the Model Context Protocol, as the wire. And on June 18, 2026, MCP got a piece it had been missing. Anthropic, Okta, and a handful of server vendors shipped enterprise-managed authorization, EMA for short, and marked the profile stable as of that date. The pitch writes itself. At last, a way for a company to centrally decide which AI agents connect to which MCP servers, through its own login system, without spraying consent screens at every employee.

It’s a real fix for a real pain.

It’s also the answer to exactly one question, and enterprise MCP auth quietly holds three. Who let the agent in. What can it touch, and as whom. Whose name is on what it did. EMA owns the first one cleanly. It says almost nothing about the other two, and that gap is the reason we are still building the layer that covers the second.

What enterprise-managed authorization means for MCP

EMA is a way for an enterprise identity provider to authorize an AI client to reach an MCP server, so the connection is approved once by an admin instead of clicked through by every user. The mechanism underneath is the Identity Assertion JWT Authorization Grant, or ID-JAG, an OAuth Working Group draft from Aaron Parecki, Karl McGuinness, and Brian Campbell. When a user signs in to the AI client through the company IdP, the client can ask the IdP for a short-lived assertion that names a specific target. The IdP checks admin policy and issues the grant. The client redeems it at the MCP server’s authorization server through OAuth 2.0 token exchange (RFC 8693), gets back a scoped access token, and only then calls the server. The scope is pinned to a named resource through RFC 8707 resource indicators, so that token opens one server and nothing else. Plumbing, basically, but plumbing with an admin’s name on the valve.

Okta’s Cross App Access (XAA) was the first identity provider to ship this, and Okta’s own tutorial walks through the four-step flow for a sample app. The MCP profile lists early adopters on both sides: AI clients like Claude, Claude Code, and VS Code, and servers from Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase, with Slack named as adding support.

The pain it kills is concrete. No more per-user OAuth prompt for every server. No more shadow connections an admin never sees. One place to set policy, and a trail of which agent reached which server. For admission, this is the right design, and it is built on plumbing we already respect.

Three questions hide inside “can the agent connect?”

One step back, because the word “authorization” is carrying two jobs here and EMA picks up only one. The mistake is treating “can the agent connect?” as the whole security question. It’s one of three, and they live at different doors. Picture EMA as the bouncer at the front entrance, checking the agent’s ID against a guest list the admin wrote. Useful work. It says nothing about which filing cabinets the agent opens once it is inside, or whose signature ends up on the paperwork.

So here are the three, named plainly. Admission: who let the agent in? Action: what can it touch, and acting as whom? Accountability: whose name is on the result?

Each one is a separate boundary with its own failure mode. Admission failures let the wrong agent in. Action failures let an admitted agent reach too much, or act as a faceless robot instead of a person. Accountability failures mean that when something goes wrong, the log reads “the bot did it” and nobody can say which human it was acting for.

EMA is built for the first door. The next two are where a workflow platform earns its keep, and where the interesting design work sits today.

Question one: who let the agent in?

Admission is the question EMA answers, and it answers it well. The control sits with an admin in the identity provider, the approval happens once instead of per user, and the access token the agent ends up holding is scoped and short-lived. For a company already standardizing on Okta or Entra ID, EMA is close to a no-brainer, a clean upgrade over the old world of every employee clicking through consent for every tool.

This door is also the one we already speak the language of. When we put Tallyfy’s own MCP server behind OAuth 2.1, with dynamic client registration and the standard discovery documents (RFC 9728 for protected-resource metadata, RFC 8414 for the authorization server), we were building on the same primitives EMA extends. That matters for a simple reason: EMA is not a rebuild for a server that already does standards-based OAuth.

It is a natural next step.

We are standards-friendly on admission and intend to support EMA-style flows as they settle, without committing to a date we cannot yet promise. The front door, we are happy to let your IdP run.

Question two: what can the agent touch, and as whom?

Action is the question EMA does not answer, and it is the one operations teams ask first: “Tallyfy AI needs my Slack token.” Admission got the agent through the front door of our MCP server. Now the agent wants to post to your Slack, read your Gmail, drop a file in your Drive, on your behalf. That is a different door, a back door out to apps your IdP may not broker at all, and EMA is quiet about it by design.

In conversations we’ve had with security-minded ops teams, the worry lands on one scene: an agent that posts a status summary to Slack at 6am, before anyone is awake to wave it through. Nobody is signed in, yet the action still lands in a real account. EMA’s flow assumes a person is signed in right now, so take that person away and the front-door grant has nothing to stand on.

The receipts are clear. One explainer from WorkOS is blunt about the boundary: the model “is designed for a ‘shared enterprise IdP, different app domains’ situation,” and “the IdP shouldn’t mint an ID-JAG to obtain access tokens for resources it controls itself.” The cross app access work that Aaron Parecki has led, published at oauth.net, describes an enterprise IdP managing “the connection between two applications,” not a SaaS vendor obtaining a user’s third-party credential to act while that user is offline. Different problem. Different door.

That back door is the layer we are building as Tallyfy Vault, coming soon and not shipped today, so treat this as direction rather than a feature we are selling you this morning. The safe mechanics are easy to state. Each person connects an app once, through that app’s normal sign-in. The grant is stored encrypted, per user, scoped to exactly what that person is allowed to do. After that the AI acts using their access, never seeing the raw secret.

A short-lived token gets vended on demand, the long-lived refresh credential never leaves the layer, your organization holds the key, and access dies in one move when you revoke it. The agent asks the layer to act. The layer acts as the user.

The snag is which door each layer guards. Here is the split, side by side.

Read the bottom row twice. The two layers do not overlap. One controls who gets in. The other controls what happens after.

Question three: whose name is on it?

Accountability is the question that surfaces the morning after something breaks: whose name is on the action the agent took? This is where the shared service account, the fastest thing most teams cobble together, falls apart. One set of credentials, broad permissions, used by every script and every bot. It works right up until you need to know who did what, and then the answer is a shrug, because everything happened as the same anonymous robot.

Per-user action fixes accountability as a side effect. When the AI acts as the actual person, through their own scoped grant, the audit trail names a human, the permissions match what that human could already do, and revoking one person does not break everyone else. The action lands in the app’s own log under a real identity, and it also lands in Tallyfy’s activity log, which records who ran what and when across a process. Accountability stops being a policy you hope people follow and becomes a property of how the thing is wired. That is the part we have already shipped, and it is the reason we route AI through the Tallyfy MCP server rather than letting a model freelance with raw API calls.

Watch the half that never gets standardized

Admission is the half that was always going to get standardized, because it is the half that lives between two parties who already share an identity provider. That is tractable. Write a token-exchange profile, get the IdP vendors to agree, and you are most of the way there. The other half, action across the long tail of apps a person uses, with no shared IdP and often no live session, is messier, and messy problems, turns out, resist clean standards.

We said EMA answers one question. That undersells it a little. On admission, EMA does more than answer, it closes a hole that was already being exploited. Obsidian Security documented a one-click account takeover class in remote MCP servers, where the servers failed to bind OAuth state to a user session, so a crafted link could hand an attacker someone’s authorization code. Square’s MCP server was among those affected before vendors shipped fixes later in 2025. Admin-brokered admission is part of how the ecosystem is hardening that door, and the MCP spec’s own security update followed on November 25, 2025.

So we are glad someone owns this half. EMA is doing real work at the front door, and we want it to.

Does an enterprise IdP make a credential vault unnecessary? Not for the apps that matter. The reason is mechanical, not marketing. ID-JAG assumes a confidential client and a shared IdP across different app domains, and WorkOS notes the IdP should not mint a grant for resources it controls itself. A SaaS vendor acting in your Slack or your Gmail, on your behalf, while you are asleep, sits outside every one of those assumptions.

We waffle on exactly how far this could converge. Could the two layers merge in some far-future world where every app you touch is an XAA resource under one corporate IdP and nothing ever runs unattended? In theory. Not for the real surface of work today, where plenty of people have no IdP at all and half the useful actions happen async.

So where does Tallyfy stand? After turning this over as a team, we keep landing in the same place: across all three doors. Standards-friendly on admission, ready to meet EMA as it settles. Building the action layer, Vault, with per-user grants the AI never sees in the raw. Accountability already shipped, in an audit trail that names a human.

The front door can belong to your IdP. The back door and the logbook are ours to get right. When you want AI acting in your real apps without anyone handing it a master key, start free.

Related questions

Does EMA for MCP replace per-user credential storage?

No. EMA, through ID-JAG and Okta Cross App Access, governs how an AI client is authorized to connect to an MCP server, brokered by a shared enterprise identity provider. It does not obtain or store a user’s credentials for third-party apps like Slack or Gmail. WorkOS spells this out directly: the model is built for a shared IdP across different app domains, and the IdP should not mint a grant for resources it controls itself. Getting an AI safe, scoped access to act inside your other apps, as you, is a separate layer. At Tallyfy that layer is Vault, which is coming soon.

Do you need an enterprise identity provider to use EMA?

Yes. The whole flow depends on a company identity provider such as Okta, Entra ID, or Auth0 issuing the ID-JAG assertion and enforcing admin policy. Teams without a central IdP, which is a large share of real-world users, cannot use EMA at all. A per-user credential layer has no such requirement, because each person connects each app through that app’s own sign-in.

Can an AI agent act in your apps when nobody is signed in?

Not through EMA. Okta’s own walk-through of Cross App Access depends on a live user SSO session, so the agent acts only while you are signed in. Unattended and async work, the kind a workflow platform runs on a schedule or in response to an event, needs a stored per-user grant that vends a short-lived token on demand without a live session. That is exactly the gap a credential vault is built to cover.