MCP Authorization Best Practices: What EMA Solves and Leaves

Enterprise-Managed Authorization (EMA) for MCP went stable on June 18, 2026, and the messaging around it sounds like a clean fix: no more per-user OAuth prompts, centralized IdP governance, zero-touch provisioning. But the reality is more complicated. EMA solves the connection problem — who gets through the front door — while leaving the harder runtime authorization problem entirely to you. Understanding that boundary is the difference between a deployment that looks secure on paper and one that actually governs what agents do with your data.

EMA Solves Connection Governance, Not Runtime Decisions

The standard MCP authorization model was designed for consumer scenarios where individuals manually approve each server connection. At enterprise scale, that model collapses: every employee authorizing every server individually creates ticket queues, no central audit trail, and no way to prevent personal accounts from touching work tools. EMA fixes this by making your identity provider the authoritative decision-maker for MCP server access. Admins define policy once, users authenticate through existing corporate SSO, and approved servers connect automatically on first login.

Under the hood, EMA uses the Identity Assertion JWT Authorization Grant (ID-JAG) flow — the client obtains an IdP-issued JWT during single sign-on and exchanges it for an MCP server access token. Deprovisioning a user in the central IdP immediately revokes their access to all downstream tools. That’s a genuine improvement over the credential sprawl that defined early enterprise MCP deployments.

But here’s the critical limitation: the IdP never sees MCP traffic and cannot make runtime, context-aware decisions about specific tool calls. EMA governs the initial connection and, through scopes, the coarse set of actions possible at issuance. What it can’t do is evaluate whether a specific tool call — say, deleting a production database record — should proceed in a specific context. That runtime per-action authorization lives in the data path and remains entirely your responsibility to implement.

The Governance Gap: Connection vs. Action-Level Control

This is what I call the governance gap pattern: MCP enterprise adoption is hitting a capability inversion where the protocol just delivered centralized connection authorization at the exact moment enterprises are discovering that the harder security problem is runtime, context-aware authorization in the agent data path. EMA’s “authorize once, inherit everywhere” model replaces individual user consent failures — narrow blast radius, high friction — with IdP group membership over-provisioning — broad blast radius, zero friction. Over-permissioning becomes the default state.

Consider what this means practically. An engineer in your Okta “engineering” group might inherit access to a Linear MCP server, a Supabase MCP server, and an internal deployment tool. EMA gets them connected to all three instantly. But when that engineer’s agent decides to run a destructive database migration, EMA has no opinion. The authorization layer that determines which data enters an agent’s context window — and what actions that agent can take with it — is effectively the boundary you need to govern. EMA only secures the door to the building, not what happens inside each room.

For teams evaluating how to structure this runtime layer, our breakdown of MCP authentication security best practices covers the broader threat model, including public MCP servers running with no authentication at all.

The Stateless Spec Shifts Security Responsibility to You

The MCP 2026-07-28 specification, due July 28, 2026, makes the protocol stateless — removing the Mcp-Session-Id header and the protocol-managed session layer entirely. This eliminates session hijacking vectors and prevents unsolicited server-initiated prompts. The tradeoff: the spec introduces client-held tracking identifiers and state objects that servers cannot blindly trust. If a server uses predictable IDs or fails to validate integrity, attackers can hijack active workflows or trigger cross-tenant actions.

The new _meta object lets clients attach custom metadata to MCP messages, which introduces risks of malicious injection and data leakage via headers. Security decisions the protocol used to enforce now fall to developers and platform operators building on it. This is the same pattern as EMA: the spec solves the structural problem (sessions, consent flows) while pushing implementation complexity onto you.

Practical Authorization Controls You Should Implement Now

EMA is a starting point, not a complete security posture. Security teams should treat each MCP server as a governed API and enforce these controls:

• Inspect full tool manifests and schemas before approval. Review every tool name, parameter schema, and output format. High-risk servers — mail, finance, source control — should be separated from general-purpose groups unless a gateway enforces policy between them.
• Enforce OAuth 2.1 with PKCE, strict redirect URIs, short token lifetimes, and audience checks. MCP servers are OAuth 2.1 resource servers and must use RFC 8707 resource indicators to bind tokens to a specific server audience, preventing credential reuse across services.
• Use action-level access control in MCP gateways. This governs what agents can do within applications, distinguishing gateway policy from traditional IAM. If you’re evaluating gateway options, our comparison of open-source vs managed MCP gateways covers the operational tradeoffs.
• Require IdP-only connections to keep work and personal accounts separated, per Claude’s announcement. Admins can shorten token lifetimes without impacting productivity because IdP checks are frictionless.
• Split servers by blast radius. One server holding mailbox, database, and ticketing scopes creates an enormous attack surface. Separate them so a stolen token doesn’t inherit everything.

For a deeper dive into how EMA works in practice — including the specific ID-JAG flow and where its authority stops — see our MCP enterprise authorization example.

The Okta Lock-In Problem

EMA’s vendor-neutral positioning — MCP is a Linux Foundation project with broad industry adoption — collides with implementation reality. At launch, Okta is the only fully supported identity provider, using its Cross App Access protocol. Microsoft Entra ID, Google Workspace, and Ping Identity remain in beta with waitlists. EMA requires Dynamic Client Registration and specific OAuth 2.1 features that most existing OAuth providers don’t support. If your organization runs Entra ID or Google Workspace, you’re looking at months before production-ready support arrives.

This creates an early lock-in risk: teams that standardize on EMA now are standardizing on Okta. Evaluate whether that aligns with your identity roadmap before committing.

Comparison: EMA vs. Per-User OAuth vs. Gateway Policy

Approach	What It Governs	Friction	Runtime Context-Awareness	IdP Lock-In Risk
Per-User OAuth	Individual server connections	High (per-server consent)	None	None
EMA	Org-wide connection provisioning	Zero (auto-inherit)	None	High (Okta-only at launch)
MCP Gateway Policy	Per-action tool calls within apps	Medium (policy config)	Yes (action-level)	Varies by vendor

Treat Authorization as Context Engineering

The most important shift in thinking: MCP authorization should be treated as a context-engineering boundary that determines which data enters an agent’s context window, not merely a security login wall. Every token scope, every tool manifest, every gateway policy decision shapes what the model can see and do. EMA gets you to the front door efficiently. What happens next — which rooms the agent enters, which actions it takes, which data it exfiltrates — is a runtime problem that the protocol explicitly cedes to implementers.

Enterprises that treat EMA as the finish line will have solved visibility but not actual agent governance. The teams that get this right are building the policy layer now, before their agents have broad enough access to cause real damage.