O
OOMeta
← Back to insights

September 2026 · 7 min read

MCP’s enterprise gate is auth, not the protocol

MCP's enterprise gate is auth, not the protocol

Key definitions

EMA (Enterprise-Managed Authorisation) MCP’s enterprise-managed authorization extension, promoted to stable in July 2026: it centralizes MCP server connection authorization in the enterprise identity provider, so users sign in once and access the servers their organization has approved — replacing per-server consent prompts.

Connection-level vs action-level authorization Connection-level decides who may connect which client to which server, at what scope; action-level decides whether a specific action an agent takes after connecting is permitted. EMA covers only the former; the official announcement is explicit that it is not runtime action authorization.

MCP server pass rate Per Digital Applied’s Apr 2026 measurement of 100 production MCP servers and ~12,000 trials: median pass rate 71%, top decile 95% or better, bottom decile 38%.

You can tell a protocol is becoming real infrastructure not by its feature count but by where it blocks enterprises. In 2026, MCP is blocked at the authorization layer and the reliability layer, not the protocol itself. The Enterprise-Managed Authorisation extension went stable in July and moved “who can connect” into the identity provider — but “what an agent may do once connected” is still every organization’s own problem. And a 100-server production test put the ecosystem’s quality on the table: median pass rate 71%, worst category 47%. Being able to connect is not the same as being able to do the job.

What changed: EMA goes stable, connection auth moves into the IdP

On July 6, 2026, InfoQ reported that the MCP team promoted the Enterprise-Managed Authorisation extension to stable status: organizations control access to MCP servers centrally through their identity provider, and users sign in once to reach organization-approved servers — replacing per-server consent prompts. The flow uses the Identity Assertion JWT Authorisation Grant (ID-JAG), exchanged for an access token by the server’s authorization server. The launch announcement says Anthropic, Microsoft and Okta have adopted it; Claude/Claude Code/Cowork and VS Code support it on the client side, with Asana, Atlassian, Canva, Figma, Linear and Supabase listed among supporting servers (vendor and official statements; sources at the end).

The backdrop is that adoption has crossed the early phase: Anthropic donated MCP to the Linux Foundation’s Agentic AI Foundation in December 2025, citing 10K+ active public servers and 97M+ monthly SDK downloads; Stacklok’s 2026 software report puts 41% of surveyed software organizations in limited or broad production. One cautionary note: the widely circulated “78% enterprise production adoption” figure could not be traced to a source and was removed by Digital Applied’s verification. In ecosystem scale, trust only the numbers you can trace.

The 100-server test: the ecosystem is bimodal

Scale is one thing; quality is another. Between February and April 2026, Digital Applied ran the first ecosystem-level reliability study of MCP: 100 production servers, 12 task families, roughly 12,000 trials. Median pass rate 71%; top decile 95% or better; bottom decile just 38%. Servers do not cluster “mostly fine” — they split into a works group and a does-not-work group. The largest single failure class (38%) was schema mismatch — request/response failing validation against the server’s declared schema, the most preventable kind. Latency tails diverge just as sharply: P50 320ms, P95 1,840ms, P99 6,200ms. By category, file-system tools lead at 89% median; browser-automation tools are worst at 47%.

For agent systems this is a multiplication problem: five tools at 71% pass each succeed end-to-end only ~18% of the time. The weakest server in the chain sets the water level for the whole chain. And popularity does not proxy reliability — the most-starred server in the sample ranked 41st by pass rate. Select on pass rate and tail latency, not stars.

Our judgment: two control planes, two gates

“Who can connect” is an identity problem, and EMA putting it in the IdP is the right move: one sign-in, organization-level approval, zero-touch — it frees security teams from per-server consent prompts. But the official announcement draws the boundary clearly: EMA does not provide runtime authorization for individual actions; it does not inspect traffic after the token is issued. Connection-level authorization decides who may connect which client to which server; action-level authorization decides whether a specific action an agent takes after connecting is permitted. The former is the protocol’s job. The latter is always the organization’s job.

This separation is the default design in our own architecture: tool onboarding (skill registration, red-card review of third-party skills) and action execution (an action queue as the cross-unit bus, decision logs, unit-level authorization) are two independent control planes. A connection approval never substitutes for an action gate — a tool being approved for integration does not mean an agent may call it without limits. Enterprises adopting MCP should build gates the same way, instead of waiting for “the protocol to mature.”

One counter-intuitive point worth flagging: the more successful MCP standardization becomes, the more important server admission becomes. Lower integration cost means low-quality servers can slip into production more easily. The four reliability gates — typed schema, idempotency, explicit cancellation, quotas — are what every top-decile server in the test shared and what bottom-decile servers almost never had. That is the shortest evidence-backed checklist the ecosystem has produced so far.

Playbook: four moves for enterprises adopting MCP

1. Connection layer: evaluate EMA/IdP support

Start with Anthropic, Microsoft and Okta; replace per-server consent prompts with organization-level approval. EMA depends on both the IdP and the server supporting it — keep a fallback path for servers that do not.

2. Action layer: do not treat EMA as a runtime gate

Attach action-level authorization and audit behind every server: which tools may be called, every call logged, sensitive operations double-confirmed. Connection authorization and action authorization are two systems — you need both.

3. Admission layer: run the four gates on every production server

Typed schema, idempotency, explicit cancellation, quotas. Pass rate, P95/P99 tail latency and concurrency falloff go into the selection standard — not stars, not download counts.

4. Composition layer: armor the brittle categories

Treat browser-automation tools (median 47%) as inherently brittle: pair them with retries, fallbacks and explicit error budgets. Never wire them bare into a critical chain.

Act: answer one architecture question first

Decision question for digital transformation leads: if “who can connect” goes to the IdP and “what an agent may do” stays with you — where is your action-level gate today? Teams without an answer should keep MCP pilots limited to read/write-separated, reversible tools while building action-level audit, then scale. The day the protocol stops being the bottleneck is the day these two gates decide how far you get.

OOMeta AI

OOMeta’s agents reach external data sources and tools through MCP (exa search, browser automation), and our architecture keeps tool onboarding and action execution on two separate control planes: skills are reviewed before access, actions flow through an action queue and decision logs. The split between “can connect” and “can act” is not a paper architecture for us — it is how we run every day, and the default gate in every agent integration we design for clients.

Book a diagnosis call

References: InfoQ “AI Model Context Protocol Adds Centralised Auth for Enterprise” (Jul 6, 2026) https://www.infoq.com/news/2026/07/mcp-ema-enterprise-auth/ · MCP Blog “Enterprise-Managed Authorisation” (official announcement) https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/ · Digital Applied “100 MCP Servers Stress-Tested: Reliability Findings” (Apr 26, 2026, independent measurement) https://www.digitalapplied.com/blog/mcp-server-reliability-100-server-stress-test-study · Digital Applied “MCP Adoption Statistics 2026” (verified May 24, 2026) https://www.digitalapplied.com/blog/mcp-adoption-statistics-2026-model-context-protocol · Stacklok “State of MCP in Software 2026” (survey) https://stacklok.com/wp-content/uploads/2026/01/State-of-MCP-in-Software-2026_FINAL.pdf · Anthropic “Donating MCP to the Agentic AI Foundation” (Dec 2025, vendor-reported) https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation

FAQ

What is MCP EMA and what problem does it solve?+

EMA is MCP’s enterprise-managed authorization extension, promoted to stable in July 2026: it centralizes server access authorization in the identity provider, so users sign in once and reach organization-approved servers without per-server consent prompts. Anthropic, Microsoft and Okta have adopted it; Claude/Claude Code/Cowork and VS Code support it on the client side (per InfoQ, Jul 6, 2026).

Does EMA make MCP secure?+

No. The official announcement explicitly warns EMA is not runtime authorization for individual actions — the authorization decision ends at connection, and EMA does not inspect traffic after the token is issued. “Who can connect” and “what an agent may do” are two control planes; the action-level gate and audit trail remain the organization’s own job.

How real is MCP adoption in 2026?+

Past the early-adopter phase but far from universal production: Anthropic cites 10K+ active public servers and 97M+ monthly SDK downloads (Dec 2025); Stacklok’s 2026 software report puts 41% of surveyed software organizations in limited or broad production (29% limited + 12% broad). The previously circulated 78% production-adoption figure could not be sourced and was removed by Digital Applied’s verification.

What did the 100-server test find?+

Median pass rate 71%, top decile ≥95%, bottom decile 38%; 38% of failures were schema mismatches; P95 latency 1,840ms is 5.7x the P50 (320ms); browser-automation tools were worst (47%) and file-system tools best (89%). Five 71%-pass tools chained end-to-end succeed only ~18% of the time.

Why are the most-starred servers not necessarily reliable?+

In the measured sample, the most-starred server ranked 41st by pass rate. Stars track popularity, not reliability. Select on pass rate, P95/P99 tail latency and concurrency falloff — not on stars or download counts.

What should an enterprise do before adopting MCP?+

Build two gates. Connection layer: evaluate EMA/IdP support (Anthropic, Microsoft, Okta for starters) and replace per-server consent with organization-level approval. Action layer: attach action-level authorization and audit behind every server. Admission layer: run the four gates on every production server — typed schema, idempotency, explicit cancellation, quotas — and measure pass rate plus tail latency.