MCP Enterprise-Managed Authorization, explained

In June 2026 the Model Context Protocol stabilized an extension called Enterprise-Managed Authorization. It is the most consequential thing to happen to enterprise MCP so far, and it is worth understanding precisely, including the boundary of what it covers.

The problem it solves

Without it, authorizing an MCP server is a personal act. Each employee visits each server, goes through a consent screen, and grants access under their own account.

That is fine for one person and one server. Multiply it.

Fifty employees and eight internal servers is four hundred individual authorizations, created at different times, by different people, with nobody holding the list. Nothing in that arrangement is visible to IT. Nothing in it is on a leaver checklist. When somebody leaves, their access to eight servers persists until each server is separately cleaned up, by somebody who knows those eight servers exist.

This is the same failure as unmanaged SaaS accounts before single sign-on was normal, arriving again in a new category. The industry already knows what the answer looks like: the identity provider is the authority, and access is provisioned rather than requested.

How it works

The mechanism is an identity assertion grant, built on RFC 8693 token exchange rather than on anything new.

During sign-on, the client takes the user's identity token from the organization's provider and exchanges it for a grant scoped to one specific target server. It presents that grant to the server's authorization server, which issues an access token. The user clicks nothing.

Two properties are worth drawing out.

The grant is per target. It is not a general-purpose credential that opens everything. The exchange happens once per server, and the identity provider decides, per server, whether this user is entitled to it. That decision is made in the place where entitlement decisions are already made and already reviewed.

Nothing new was invented. It composes existing pieces: an identity token you already have, a token exchange your provider already implements, an authorization server the MCP specification already required. That is why adoption arrived quickly rather than over several years, and it is a good sign about how the extension will age.

What Enterprise-Managed Authorization changes for you

Onboarding stops being a list of instructions. A new hire signs in and has the servers their group entitles them to. No document telling them which eight to authorize, and no long tail of people who did six of the eight.

Offboarding becomes one action. Disable the account in the identity provider and the exchange stops producing grants. The access does not need to be chased across servers, because it was never granted at a server in the first place.

Group membership becomes the control surface. Adding somebody to a group in your provider gives them a set of servers. This puts MCP access into the same review your provider already gets, which for most organizations is the only access review that reliably happens.

Audit gains a real subject. The access token traces back to an identity assertion for a named person, so server-side logs have a subject that means something outside the server.

For anybody running their own MCP servers, this is the single biggest reduction in operational burden the specification has delivered. It is worth adopting.

What it does not do

The extension governs access to a server. It does not govern what happens inside one.

That distinction is the whole of the remaining problem, so it is worth making concrete.

Say you run an MCP server in front of your helpdesk. It exposes twelve tools: read a ticket, search tickets, reply, change status, reassign, merge, delete, and so on. The extension can ensure that only people in the support group reach that server at all. Good.

It has no opinion about the fact that your support agents should be able to read and reply, your support leads should additionally be able to merge and reassign, and nobody except two named people should be able to delete. All twelve tools are behind one server boundary, and the extension operates at that boundary.

So the questions it leaves open are:

• Which tools inside this server may this person call?
• May they call this tool with these arguments, on this account, when the app has several connected?
• What happened, per call, and under whose access?

Those are the same questions you would ask about any system, and they are not an oversight in the extension. They are out of its scope on purpose: a general specification cannot know what your tools mean. The answers have to come from the server, from something in front of it, or from the platform hosting it.

The practical consequence is a shape worth predicting. Because the extension makes server-level access cheap to provision, the cheapest way to express a finer-grained policy becomes more servers. One server per team, per environment, per sensitivity level, each one a subset of tools, each provisioned to a different group.

That works. It is also how you end up operating thirty servers whose only difference is which tools they expose, with the actual policy distributed across your identity provider's group memberships and thirty separate deployments. The identity provider ends up holding a policy it cannot read, because a group name is not a statement about tools.

Where this leaves a gateway

The honest version, since we sell one.

The extension genuinely narrows the case for a gateway whose main job is aggregation and central provisioning. If you were planning to buy one so that employees would stop authorizing eight servers each, your identity provider may now do that part, and you should check before buying anything.

What it does not narrow is the case for a layer that resolves policy per call. If two people in the same group should see different tool lists, or if an operation should be restricted without deploying a second server, you need something that evaluates the person and the operation at the moment of the call. The extension hands over a valid token for a target; the per-call question starts after that.

Our own position sits deliberately on the inside of that boundary. The endpoint is one address. Who you are decides which tools you are advertised, which operations you may run, and which connected account each one reaches, evaluated per call rather than baked into which server you were provisioned. The two compose well: the extension can decide that somebody reaches the endpoint at all, and the per-call resolution decides what they find when they do.

Two notes for accuracy, since this is a post about a specification.

Server-level provisioning and per-call authorization are different clocks. A grant revoked in your identity provider stops new exchanges at once. A change to what somebody may call inside a system is a policy change, and in our case propagates in about two minutes. Different mechanisms, different guarantees, and worth knowing which you are relying on during an incident.

The extension does not make a server safe. It authenticates and entitles the caller. What the server then does with a tool call, and whether that tool call was a good idea, is unchanged. Our MCP endpoint, for one, carries no defense against instructions embedded in content a tool returns, and cannot, because a server never sees the user's prompt to compare against. Authorization and judgment are separate problems and it is worth not letting a strong answer to one imply an answer to the other.

The migration nobody mentions

If you already have employees who authorized servers individually, adopting the extension does not retire those authorizations. It changes how new access is obtained. The old grants keep working, because they are valid grants.

That leaves a period where access to a given server exists through two mechanisms, one of which your identity provider knows about and one of which it does not. The second one is invisible in exactly the way the extension was adopted to fix.

Three things worth doing in that window.

Inventory before you migrate, not after. Each server's own authorization records are the only place the existing grants are visible. Pull them while you still have a reason to look, because after the migration everyone will assume the provider is authoritative and nobody will check the servers again.

Decide whether old grants expire or are revoked. Letting them age out is less disruptive and leaves an unbounded tail. Revoking them forces everyone through the new path at a known date and generates a week of support questions. The second is usually right, and it is much easier if you pick the date in advance rather than discovering the tail during an audit.

Check that your provider's group model can express what the servers do. This is where migrations stall. Server-level entitlement is coarse, so the mapping from "who should have this" to "which group" is only as good as your groups. If your provider's groups are organizational rather than functional, you may find there is no group that means the thing you need to grant.

None of this is difficult. It is the kind of work that goes badly when it is discovered halfway through rather than planned, which is the only reason to mention it.

What to do about it

If you run your own MCP servers: adopt it. It removes the per-server consent problem, which is the one that scales worst, and it costs you a provider configuration rather than a rewrite.

If you are evaluating platforms: ask where each one sits relative to the boundary. Does it provision access to servers, resolve policy per call, or both? All three answers are legitimate, and they solve different halves.

If you are mid-decision: nothing you have already worked out is wasted. Which teams need which systems, and which operations inside them, is the same analysis before and after. The extension changes how a person is admitted, not what they should find.

The per-call half of this is written up in resolving policy per call, and the credential questions underneath it in OAuth or API keys for agents. If you are weighing the roll-your-own path against buying, MCP gateways compared covers where the line falls.