MCP’s next specification — your agent needs receipts

Q: What does Enterprise-Managed Authorization do for MCP?

Enterprise-Managed Authorization makes the enterprise identity provider the policy decision point for MCP connections. It replaces repeated server-by-server consent prompts with an identity assertion grant, enabling centralized onboarding, policy enforcement, auditing, and revocation while preserving standard per-user OAuth for consumer and individual use.

Q: What changes when MCP becomes stateless?

Stateless MCP removes the initialization handshake and Mcp-Session-Id, allowing every request to be routed independently. Servers no longer need sticky routing or shared session infrastructure for protocol state. The specification also adds Mcp-Method and Mcp-Name HTTP headers and provides official conformance tests for implementations.

Q: Does Enterprise-Managed Authorization control individual MCP tool calls?

Enterprise-Managed Authorization controls whether an MCP connection may exist, not what an agent may do after connecting. Runtime authorization must separately evaluate tools, arguments, tenants, downstream credentials, approval requirements, replay resistance, policy availability, and composed workflows that combine individually permitted actions into a dangerous sequence.

MCP centralizes enterprise login and drops session state, but the real security problem starts when authenticated agents begin using tools.

The sixth OAuth consent screen is where security becomes theater. Somewhere in enterprise IT, an employee is clicking “Allow” again while a security engineer updates a spreadsheet nobody trusts. I’ve shipped enough integrations to know how this movie ends. Everyone calls the friction “security,” users invent a workaround, and six months later the permissions require carbon dating. MCP’s next specification tackles enterprise agent authentication complexity by centralizing identity and removing protocol state. Both changes matter. They also make it dangerously easy to assume that an agent connecting correctly should be allowed to do whatever it attempts next.

Enterprise-Managed Authorization, or EMA, centralizes who may connect. The MCP 2026-07-28 specification makes those connections easier to scale by removing sessions and the old initialization handshake. Companies can give thousands of employees access to agents operating across dozens of systems without running a browser-consent obstacle course.

I like both changes. I would ship both.

Then I would ask what happens when an authenticated agent exports 40,000 customer records, modifies production, or combines three harmless-looking tools into a workflow that ruins everybody’s Tuesday.

Identity gets the agent through the front door. The security fight has already moved further inside.

Consent screens collapse at company scale

Every integration looks manageable when five early adopters connect manually. Then sales asks for 500 seats, IT asks how offboarding works, and the architecture begins smoking gently in the corner.

I’ve watched this pattern across 20 years of building products at Ad Astrum. With ALYT, our US home-automation platform, the happy-path connection was rarely the hard part. Pain lived at the seams: who owned the device, which account controlled it, what happened when credentials changed, and how the cloud behaved when reality ignored our diagrams.

OAuth consent screens have the same deceptive charm. They are visible, so they feel responsible. After the fifth identical prompt, users click through with the thoughtful attention I bring to the cookie banner on a regional Italian newspaper.

Scalekit uses the example of a company where every employee needs access to five or six internal MCP servers. Under standard MCP OAuth, every new hire gets five or six browser flows, account selectors, and opportunities to connect a personal identity where a corporate one belongs.

That flow makes sense when I connect my own Claude client to my own Figma or GitHub account. I am the user, I own the data, and I should approve the relationship.

Across a company, the consent screen becomes an authorization tax. Offboarding requires cleanup across separate servers. Audit records live in different places. Nobody can answer which identity is connected where without opening three admin consoles and calling Dave, who left in March.

Jordan Selig described the scale problem in Microsoft’s Apps on Azure Blog on July 16, 2026:

This time, the protocol change is about a different kind of scale: how an enterprise connects hundreds or thousands of employees to MCP servers without making every person authorize every server one at a time.

EMA became a stable MCP extension on June 18, 2026. Standard per-user OAuth remains the default for consumer and individual use. Servers explicitly advertise EMA support for enterprise deployments.

That restraint is sensible. Personal consent still has a legitimate job, and forcing corporate identity machinery onto every hobby project would be extremely enterprise software of us.

EMA gives the organization one accountable authority. A corporate identity provider can apply employment status, existing groups, device requirements, and conditional-access policy from one control plane. When somebody leaves, access can disappear across EMA-connected servers instead of triggering a scavenger hunt.

Selig put it plainly in the same Microsoft post:

Enterprise-Managed Authorization (EMA) is now a stable MCP extension. It makes the organization's identity provider the policy decision point, replaces repeated server-by-server browser prompts with an identity assertion grant, and gives security teams a central place to grant and revoke access.

Finally. Security teams needed central accountability. Nobody needed another blue “Allow” button.

EMA moves the authorization decision upstream

Calling EMA “SSO for agents” undersells the architecture. Single sign-on describes what the employee sees. Underneath, the enterprise identity provider decides which user and MCP client may reach a particular resource.

The employee signs into an MCP client such as Claude or VS Code through the corporate identity provider using OIDC or SAML. When the client requests access to an MCP server, the IdP evaluates the user, requested scopes, destination resource, client application, and relevant enterprise policy.

If the request passes, the IdP issues a short-lived Identity Assertion JWT Authorization Grant. Mercifully, everybody calls it an ID-JAG.

The client presents that assertion to the MCP server’s authorization server, which exchanges it for a normal resource access token. EMA layers RFC 8693 token exchange and the RFC 7523 JWT bearer grant onto the enterprise login. No exotic new token religion required.

Selig explained the wire-level requirement in Microsoft’s July 16 piece:

The full EMA flow additionally requires the enterprise identity provider to issue an Identity Assertion JWT Authorization Grant, or ID-JAG, and the MCP authorization server to exchange it. Same goal, related building blocks, different wire protocol.

Each ID-JAG is audience-bound to a specific destination. There is no reusable enterprise master token wandering between servers like a hotel key that opens every room. Once the IdP issues the assertion, it leaves the data path and does not inspect subsequent MCP traffic.

That detail matters when vendors claim EMA support because users saw no consent screen. Microsoft’s sample shows the distinction.

Its Azure implementation exposes a user_impersonation scope and preauthorizes Visual Studio Code and Azure CLI. Azure App Service Authentication validates the token signature, issuer, audience, and lifetime before a request reaches the Python application. It also limits accepted client IDs and leaves only / and /health public.

That is useful, centrally governed OAuth. Full EMA also requires Entra to issue an ID-JAG through RFC 8693 and a receiving authorization server to perform the RFC 7523 assertion exchange.

The browser experience can look identical while the wire protocol provides different guarantees. A Fiat Panda and a Ferrari 296 GTB can both get me to dinner; I still want to know what is under the hood.

Microsoft’s local interoperability lab validates the ID-JAG signature plus claims including issuer, audience, client ID, resource, scopes, expiration, and a single-use jti. It deliberately tests wrong issuers, scope escalation, expired assertions, and replay attempts.

Those negative tests matter more than the cheerful demo where every token behaves itself.

Okta calls its implementation Cross App Access, or XAA. XAA covers the identity-provider side, while EMA describes the MCP client and server handoff. Both use the ID-JAG credential, giving implementers one concrete format to validate instead of two marketing departments’ interpretations of trust.

Stateless MCP removes an expensive pile of plumbing

Tomorrow, July 28, 2026, MCP’s new specification becomes final. Its biggest architectural change removes the initialize handshake and Mcp-Session-Id, so every request can be routed independently.

GitHub announced support ahead of the release:

The MCP protocol is going stateless on 28th July 2026, and the GitHub MCP Server supports the latest spec ahead of the official release.

I have an embarrassing confession. Earlier in my career, I underestimated how quickly “we’ll keep a little session state” turns into sticky routing, shared stores, recovery logic, and a 3 a.m. debate about why replica three believes a client does not exist.

Building ALYT, EON for Germany’s largest energy provider, and Life Control for Megafon cured me of that optimism. Hidden state behaves beautifully in architecture diagrams. Production traffic has other hobbies.

Under the previous MCP model, the initialization handshake created a session identifier that later requests had to carry. At scale, this could pin clients to particular server instances or require shared session infrastructure.

GitHub’s migration makes the payoff concrete. The GitHub MCP Server removed Redis writes during initialization and Redis reads on every call. An entire class of latency and failure disappears from the request path.

The new specification also introduces Mcp-Method and Mcp-Name HTTP headers. GitHub previously inspected request payloads before its SDK handled them because it needed fields for logging and secret scanning. It can now obtain those routing fields from guaranteed headers.

Official MCP conformance tests give SDKs and bespoke implementations a shared verification target. GitHub uses the official Go SDK. Tier-one SDKs preserved backward compatibility and shipped beta support ahead of the release.

Migration should feel boring. Protocol work has succeeded when nobody needs a war room.

The scale waiting on the other side is already absurd. A cloud-gateway paper submitted to arXiv on July 17 by Mingxin Li and 29 co-authors reports access to more than 3,000 tools. Its hybrid retrieval system achieved 98% Top-15 recall while cutting tool-selection time by 8.9 times and token use by 23.8 times.

Three thousand tools is an operating environment.

Once MCP servers can scale behind ordinary routing and inherit corporate identity without repeated consent flows, an approved connector can spread across an organization fast. A deployment that once required custom session plumbing and six browser detours starts looking like an admin toggle.

That speed is fantastic until the policy model is wrong.

A sleek digital interface displaying receipt management tools, emphasizing efficiency in tracking expenses for agents.

Image alt text: How MCP enterprise agent authentication uses an IdP and ID-JAG while runtime authorization remains separate.

Headers help routers. They do not prove intent

Stateless MCP will tempt teams to put Mcp-Method and Mcp-Name into an ordinary L7 proxy and declare security solved. Routing information belongs in headers. Trust requires evidence from the request body too.

Agentgateway published a wonderfully blunt demonstration on July 21. A request advertises Mcp-Name: echo in its header while the JSON-RPC body invokes printEnv. A header-only gateway sees an approved tool and forwards the request. The backend runs the dangerous one.

An MCP-aware implementation compares the header with the body and rejects the mismatch before the request reaches the server. The reserved JSON-RPC HeaderMismatch error uses code -32020.

Headers are conference name tags. They help me find the right room and maybe the buffet. I still want more evidence before accepting that the person wearing “CFO” can wire $400,000.

The specification requires implementations processing the body to verify that its values match the corresponding HTTP headers. A gateway making policy decisions from headers alone has duplicated the security-sensitive truth and chosen to trust the easier copy.

Bold.

Identity metadata creates a related trap. Specification PR #3002 makes clientInfo optional and moves serverInfo into response metadata. Both are self-reported fields intended for display, logging, and debugging. The PR explicitly warns against using them for authorization or other security decisions.

I can write clientInfo: definitely-the-real-finance-agent into a request. The confidence of the introduction adds no cryptographic weight.

OAuth hardening matters even more for agents speaking to multiple authorization servers. The MCP C# SDK’s v2.0.0-rc.1 rejects authorization-server metadata that fails to advertise PKCE S256 instead of politely assuming compliance. The same release implements RFC 9207 issuer validation and tightens Dynamic Client Registration behavior.

WorkOS’s analysis of CVE-2026-59208 shows why issuer binding deserves this fuss. In n8n’s token-exchange flaw, a correctly signed token from the wrong issuer could map to a same-named user in another issuer’s namespace.

Signature validation alone accepted a key from the trusted pool. Secure validation must bind that key to the expected issuer, then keep the subject inside the correct tenant namespace. Multi-server agents multiply the issuers and token exchanges involved, so sloppy assumptions compound quickly.

The dangerous work starts after login

EMA decides whether a connection may exist. Scalekit explicitly says it does not provide runtime authorization for individual tool calls.

The IdP issues the ID-JAG and exits. It never watches an agent call read_customer, then export_csv, then send_email. This separation keeps the identity provider from becoming an expensive surveillance proxy for every tool invocation. It also leaves the centralized login with no opinion about the action sequence.

Scalekit’s technical walkthrough states the boundary clearly:

The IdP's involvement stops the instant it hands over the ID-JAG. It never inspects the actual MCP traffic that follows — meaning it has no visibility into, and no say over, any individual tool call an agent makes after the connection is live.

This is where “SSO for agents” pitches make me itchy. An authenticated employee may have legitimate access to Salesforce, GitHub, and AWS. Their agent can still perform a wildly inappropriate action inside each system or compose permitted actions into something nobody intended.

AWS supplied a timely example on July 23. CVE-2026-16584 affected AWS API MCP Server versions >= 0.2.13 and < 1.3.47.

The server offered an optional security policy that could deny or gate specific AWS operations. If policy initialization failed during startup, the process could continue running while skipping the configured per-request checks for its entire lifetime. AWS fixed the issue in version 1.3.47.

IAM permissions remained active.

That detail prevented a much worse outcome. It also proves why MCP-specific runtime controls need foundational access restrictions underneath them. The agent’s downstream AWS credentials should already have least privilege. A supplemental policy engine cannot be the sole barrier between a model and aws iam delete-role.

My enterprise MCP stack would start with narrow downstream credentials. Tokens would be short-lived and audience-bound. Tool discovery would expose only the tools available to that caller. Runtime policy would evaluate the arguments and target tenant, with human approval before irreversible operations.

Replay resistance belongs there too. So does fail-closed startup behavior. If the policy engine cannot load, the agent gets zero tools and somebody gets paged. Continuing without enforcement is the security equivalent of my espresso machine failing to detect water and deciding steam is close enough.

Tool composition is harder. A customer lookup can be fine. CSV export may be legitimate for a finance role. Email is obviously useful. In sequence, those tools can become a tidy little data-exfiltration pipeline.

Arun Ravindran and Saurabh Deochake tested that problem in ToolGuardian, a July 23 arXiv paper. They evaluated 16 MCP-style tools, including eight malicious variants, across 20 runtime scenarios. Their declarative policy approach reached a deny-class F1 of 0.86 and 88% accuracy in pre-admission vetting.

The ablations tell the useful part. Performance degraded when they removed compositional and conformance rules. Policies that inspect each tool in isolation miss risks created by the workflow.

Another July 23 paper, from M. Llambí-Morillas and D. Fernández-Fernández, separates identity binding, authorization-request binding, policy binding, and runtime execution binding. Their proposed Cryptographically Verifiable Agent Authorization model is early research, complete with a Groth16 zk-SNARK proof of concept, but the decomposition is sound.

A login proves far less than an agent platform needs. I want evidence tying a principal to the exact request, applicable policy, and execution context. Otherwise the audit trail can identify who owned the credentials while staying vague about why the action was allowed.

That is attribution after impact. Legal will appreciate it, I suppose.

“Supports MCP” has one year left as a sales pitch

EMA adoption already includes Anthropic across Claude, Claude Code, and Cowork. VS Code supports it directly in the IDE, and Okta shipped the IdP side through Cross App Access.

Server support includes Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase. Slack has been reported as in progress. MCP compatibility is moving from differentiator to checkbox with impressive speed.

By July 2027, asking “Does it support MCP?” will sound like asking a SaaS vendor whether it has an API. I am putting a date on that because vague predictions are horoscopes for product managers.

Enterprise buyers will move on to harder questions. Which human principal initiated the action? Which model executed it? What tool and arguments were used? Which policy allowed the request? Which downstream credential touched the customer’s data?

They will also demand proof that denials work. I would test policy startup failure, replay attempts, cross-tenant tokens, scope escalation, header-body mismatches, and composed tool chains end to end before putting “enterprise secure” anywhere near a sales deck.

Static scanners will not rescue lazy teams. The MCPZoo project, published by Pei Chen and eight co-authors on July 13, contains 64,611 unique MCP servers, with more than 37,288 available for dynamic analysis. Existing scanners labeled 96.89% of servers risky.

Manual validation found that fewer than half of sampled alerts were true positives.

Anybody selling a green compliance badge from repository scanning should sit with those numbers for a minute. Runtime behavior needs runtime testing when tools can modify production systems or move data between tenants.

I would ship EMA tomorrow because centralized onboarding and revocation solve expensive, boring problems. I would also welcome stateless MCP because it removes infrastructure I would rather never operate again.

Then I would require every sensitive action to produce a receipt containing the principal, agent, tool arguments, policy decision, downstream identity, and observed result. Reversibility belongs on that receipt too. delete_customer deserves a different approval path from read_customer.

One login for every connector feels magical. Magic is lovely at dinner.

By July 2027, the enterprise agent platforms worth buying will compete on receipts. The rest will authenticate the incident report.

Frequently asked questions

What does Enterprise-Managed Authorization do for MCP?