Enterprise-Managed Authorization [What It Changes]

Enterprise-Managed Authorization is a Model Context Protocol extension that lets an organization grant AI tool access once through its own identity provider, so employees inherit the tools they are entitled to at login instead of clicking through a separate consent screen for every tool. It turns AI tool access from something each employee grants privately into something the business enables, scopes, and audits centrally.

The extension was marked stable on June 18, 2026. That date matters less than what it removes: the per-user consent click that has quietly been the reason most organizations could not say, with confidence, which AI tools their staff had connected to which systems.

TL;DR

• What happened: the Model Context Protocol project promoted its Enterprise-Managed Authorization extension to stable on June 18, 2026, as documented in the project's announcement.

• The mechanism: during single sign-on the client gets an Identity Assertion JWT Authorization Grant (ID-JAG) from the identity provider and exchanges it for an access token at the tool's authorization server. No per-tool consent screen.

• Why now: repeated consent prompts were, in the project's own framing, one of the biggest pain points in connecting tools — and a per-user authorization tax that kept most connectors switched off.

• Who shipped it: Okta as the first identity provider; Anthropic and Visual Studio Code on the client side; Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase server-side, with Slack adding support.

• The honest limit: it governs whether a tool is connected, not what the agent does once connected.

What actually changed

Before this extension, connecting an AI assistant to a work system was a personal act. An employee clicked "allow," a token was issued against their individual account, and the organization had no single place to see that it happened. Multiply that by every tool and every employee and you get a permissions estate nobody owns.

The extension inverts the default. An administrator enables a server for the organization once, and users get it automatically on first login, scoped to the groups and roles they already hold. The Model Context Protocol announcement states the payoff in three parts, verbatim: "Authorize once, inherit everywhere," "Centralized policy and audit: access decisions live in the IdP admin console, with one auditable trail across every connector," and "Removing personal/enterprise mixups: by removing the interactive account selection step, it's much easier to prevent data flowing between personal and enterprise accounts by mistake or compromise."

That third outcome is the one operators underrate. The interactive account picker — the dialog asking which Google or Slack account you meant — is where work data leaks into personal accounts. Removing the step removes the mistake.

Sources: Model Context Protocol; Okta; InfoQ.

The mechanism, in plain language

Think of it as the difference between a building where every tenant hands out their own keys and a building with a front desk.

In the old model, each tool issued its own key directly to each employee. In the new model, your identity provider signs a short-lived, purpose-scoped assertion — the ID-JAG — that says "this is Dana, she is in the paralegal group, and she is entitled to this server." The client hands that assertion to the tool's authorization server and gets back an access token. The tool never has to ask Dana anything.

Two properties matter operationally. The assertion always carries a subject claim as the stable user identifier, so the audit trail points at a person even if their email changes. And it may carry an email claim, which is how an existing account in the tool gets linked to the corporate identity rather than duplicated.

Because the grant is issued by your identity provider, revocation finally works the way people assume it already does. Deactivate the account and the entitlement stops, everywhere, without chasing individual tool consents.

Why the constraint broke now

The forcing function is volume. Identity estates have grown past the point where per-user consent is survivable.

According to Okta, 91% of organizations already use AI agents, but only 10% have a well-developed strategy to manage them — a gap between deployment and governance that consent screens cannot close. 91% of organizations use AI agents; only 10% have a management strategy.

The machine identities themselves are multiplying. According to Okta, centrally managed service accounts grew 650% year over year, while average access requests per company rose 1,140% over two years. Centrally managed service accounts grew 650% year over year. Manual approval does not scale against that slope; central entitlement does.

The security case is equally blunt. According to Help Net Security's reporting on the 2026 Verizon DBIR, third-party involvement in breaches jumped 60% year on year and now accounts for nearly half of all breaches, and only 23% of third-party organizations had fully remediated their MFA issues. Third-party involvement in breaches jumped 60% year on year. Every ad hoc tool connection is a third-party relationship that no one recorded.

Sources: Okta.

Sources: Help Net Security.

Cost sharpens the point. According to the HIPAA Journal's summary of IBM's 2025 breach research, the average US breach cost reached $10.22 million and stolen credentials were the initial access vector in 10% of breaches. Average US breach cost reached $10.22 million. Credential-scoped access is not a theoretical concern; it is a line item.

What it looks like on the ground

Consider a 40-person firm where staff use an AI assistant to pull records, draft summaries, and file documents. Today each person authorizes each tool individually. There are perhaps a dozen tools, a few dozen staff, and no central list — so when someone leaves, offboarding covers email and the core system of record, and quietly misses the AI connections nobody documented.

Under central authorization, the same firm enables the tools once against existing groups. A new paralegal inherits exactly the paralegal set at first login. A departing one loses all of it when the account is deactivated. The audit trail lives in one console, not thirteen.

The change in effort is concentrated in one place. Setup gets harder, because someone must decide which groups get which tools. Everything after setup gets easier, because the decisions are already encoded.

Sources: mechanism per Model Context Protocol; illustrative counts, not measured figures.

Who shipped it, and who has not

Support is real but partial, which is the normal shape of a stable-but-young extension. Okta was the first supported identity provider. Anthropic and Visual Studio Code implement it client-side. Asana, Atlassian, Canva, Figma, Granola, Linear and Supabase implement it server-side, with Slack among those adding it.

Read that list honestly: it is weighted toward knowledge-work and developer tooling. If your operation runs on a vertical system of record — a practice management suite, a property accounting platform, a case management system — your critical tool is probably not on it yet.

The limits nobody should skip

The most important caveat comes from the coverage rather than the marketing. According to InfoQ, the extension does not provide runtime authorization for individual actions, so organizations still need separate controls governing what an agent does inside a system once it is connected, and the protocol remains additive — organizations whose identity provider does not support it need a fallback.

That distinction is worth stating plainly, because it is where teams will over-read the news:

Sources: Model Context Protocol; InfoQ.

Teams already routing documents and approvals through US Tech Automations workflows will feel this as a connection-layer change rather than a rebuild: the workflow steps stay identical, but the credential behind each tool call stops being an individual's personal grant and becomes an entitlement the administrator issued and can withdraw.

Signal vs Speculation

What is sourced fact (as of June 2026): the extension is stable; the mechanism is an ID-JAG exchanged for an access token; Okta is the first identity provider; the named clients and servers above have shipped or are shipping support; and the extension does not govern per-action behavior.

Our read: the durable change here is auditability, not convenience. Convenience is what gets it adopted, but the reason it sticks is that it produces the artifact a business needs and has never had — one list of which AI tools are authorized against which systems, tied to the group structure the organization already maintains.

Our read: if the vendor list keeps widening at its current pace, we expect central AI tool entitlement to become a default procurement question within 12 to 24 months — the same way single sign-on support moved from a differentiator to a checkbox. The pressure will not come from IT. It will come from clients, insurers, and auditors asking a question small and mid-size firms currently cannot answer: which AI tools can reach our data, and who approved them?

Our read: the 12-to-36-month risk is a false sense of completion. Given that only 32% of organizations secure AI agents as rigorously as human employees per the Okta data cited above, we expect a wave of teams to adopt central authorization, declare the governance problem solved, and skip the per-action controls the extension explicitly does not provide. The gap between "connected safely" and "behaving safely" is where the first notable incidents will come from.

Our read: for firms under about 50 people, the practical near-term move is not adoption but inventory. If you cannot list today which tools staff have personally connected, you cannot evaluate what central authorization would replace.

What to do about it now

The work in front of most operators is preparation, not migration.

Start by writing down the connections that already exist. Ask what AI assistants staff use, what systems those assistants reach, and whose account issued the access. Most teams find at least one connection nobody knew about.

Then check your identity provider. If you do not run one, that is the prerequisite — this extension inherits your groups and roles, so it can only be as good as the group structure underneath it. If your groups are stale, central authorization will faithfully propagate stale access.

Finally, decide who owns the decision. Central authorization creates an approver role that most small organizations have never assigned. Teams that map those entitlements onto existing intake and approval steps — the same steps US Tech Automations workflows already use to route documents and trigger follow-ups — tend to find the group structure is the hard part, not the connection itself.

One sequencing note worth stating: do the inventory before you touch the identity provider. Central authorization makes it trivial to grant broad access quickly, which is precisely the risk if nobody has audited what the current sprawl actually contains. The teams that fold this into an existing onboarding and offboarding workflow — where group assignment already triggers the downstream provisioning steps US Tech Automations routes for them — get the audit benefit without re-granting yesterday's mistakes at scale.

Key Takeaways

• Enterprise-Managed Authorization lets an organization enable an AI tool once, centrally, instead of every employee granting access per tool.

• The mechanism is an ID-JAG obtained during single sign-on and exchanged for an access token at the tool's authorization server.

• It was marked stable June 18, 2026, with Okta first among identity providers and a growing client and server list.

• It governs connection, scope, and audit — not what an agent does once connected. Per-action controls remain your responsibility.

• The prerequisite is a clean identity provider with accurate groups; without that, it propagates whatever access hygiene you already have.

Frequently Asked Questions

What is Enterprise-Managed Authorization in one sentence?

It is a Model Context Protocol extension that lets an organization authorize AI tool access centrally through its identity provider, so employees inherit entitlements at login instead of approving each tool themselves.

Does this replace our existing single sign-on?

No — it depends on it. The extension rides on the single sign-on you already run, using your identity provider to issue the grant. If you do not have an identity provider, that is the prerequisite rather than something this replaces.

Can it stop an AI agent from deleting the wrong record?

No. According to InfoQ, the extension does not provide runtime authorization for individual actions, so controls over what an agent does inside a system remain separate and necessary.

Why should a 20-person business care about this?

Because the audit question arrives regardless of headcount. Small firms carry the same client-confidentiality obligations as large ones but rarely have a record of which tools staff connected — and per-user consent is exactly what prevents that record from existing.

How quickly will our vendors support it?

Unevenly. The initial server list skews toward knowledge-work and developer tools, so vertical systems of record common in legal, healthcare, and property operations are likely to lag. Ask your core vendors directly rather than assuming.

Is a stable designation the same as production-ready?

Stable means the specification is settled, not that your stack supports it. The extension is additive, so the practical gate is whether your identity provider and your specific tools have both implemented it.

Where this lands for operators

The headline is a protocol change. The operational story is smaller and more useful: for the first time, "which AI tools can reach our systems" becomes a question with an answer, held in the same console where the rest of your access lives.

If you are mapping how central entitlements would attach to the workflows you already run, our agentic workflow platform overview covers how connection, approval, and audit steps fit together in practice.

For what this means inside specific operations, see our companion analyses on what it changes for law firms, the implications for healthcare practices, and how property management teams should read it.