Short answer: if you run a Checkout or Catalog MCP server, the protocol just changed how it tracks who’s who mid-session — and security researchers say getting that wrong now carries a specific, checkout-relevant cost: one shopper’s agent seeing or acting on another shopper’s cart.

What shipped on July 28

The 2026-07-28 MCP Specification — the largest revision of the Model Context Protocol since launch, covered here ahead of its release — finalized on schedule, unchanged from the release candidate locked May 21. Its headline change is a stateless core: MCP drops the initialize handshake and the Mcp-Session-Id header entirely, so a server no longer keeps server-side session state tying a request to who sent it. Instead, per the official changelog, the client now carries its own protocol version, identity and negotiated capabilities inside a _meta object on every request, and a server can hand back opaque tracking IDs and state objects the client passes back to resume a workflow later (Model Context Protocol Blog, “The 2026-07-28 Specification”).

Operationally this is a real win — a remote MCP server can now sit behind a plain load balancer instead of needing sticky sessions and a shared session store. Security researchers at Akamai flag what it trades away.

The risk: IDs the server has to stop trusting

Because tracking IDs and state objects now originate from the client rather than a server-held session, Akamai’s analysis says a server that doesn’t treat them as adversarial input opens itself to three concrete failure modes: workflow hijacking, cross-agent data exposure, and unauthorized cross-tenant actions — a predictable or guessable ID lets one caller step into another’s in-progress session (Akamai, “The New MCP Specification: What Security Teams Must Prepare For”; reported by SecurityWeek, “New Enterprise-Ready MCP Specification Brings New Security Challenges”). For a Catalog or Checkout MCP server specifically, “cross-tenant action” is not an abstract category — it’s the difference between an agent reading its own shopper’s cart and reading (or altering) someone else’s.

A second, separate risk comes from the same spec change: the new SEP-2243-mandated method/name headers on every streamable-HTTP request introduce their own attack surface — protocol-confusion (“desync”) attacks and data leakage through the new header fields, on top of the session-ID problem (SecurityWeek).

What Akamai recommends

None of this means statelessness was the wrong call — it means the security boundary moved from the protocol to the implementation. Akamai’s guidance for anyone operating an MCP server converges on a short list:

  • High-entropy, unguessable tracking IDs and state objects, with short expirations rather than long-lived reusable tokens.
  • Server-side tenant isolation: bind every request to a verified identity and derive tenant/account context on the server, instead of trusting a tenant identifier the client supplies in the request.
  • Least-privilege scoping: start every session with minimal permissions and require step-up authorization before a higher-risk action — like placing an order — is allowed to execute.

Who actually has to act on this

As covered here when the release candidate locked, most merchants don’t operate MCP servers by hand — Shopify runs Catalog and Checkout MCP endpoints on stores’ behalf, and platform-managed implementations carry their own upgrade burden. This finding sharpens who’s exposed: it’s whoever wrote or hosts a custom MCP server for agentic commerce — a bespoke checkout integration, a headless-commerce build, an agency-built agent endpoint — who now needs to check that tracking IDs and state handles are random, short-lived and bound to a verified caller before treating “we support MCP” as done.

Spec compliance and security are two different checks. A Checkout MCP server can implement every SEP in the July 28 spec correctly and still leak one shopper’s session to another’s agent if its tracking-ID generation is weak — which is exactly the kind of gap that sits underneath the transaction layer AgentReady’s scan is built to surface, not just whether a store’s MCP endpoint exists.

Sources