MCP’s stateless 2026 spec shifts more security enforcement to every request

The Model Context Protocol’s July 28, 2026 revision was designed mainly for scale: it removed protocol-level sessions, made each request self-describing and allowed ordinary round-robin infrastructure. A September 5 security analysis from VentureBeat argues that this architecture also changes where defenders have to enforce trust. Controls that used to be associated with a connection or session increasingly have to be rechecked on every request, state handle and rendered interface.\n\nThe official MCP release notes support the architectural part of that argument. The 2026-07-28 spec retires the initialize/initialized handshake and Mcp-Session-Id header, moves state out of the protocol core and strengthens OAuth-oriented authorization. That is not a declaration that MCP is insecure; it is a change in responsibility. Applications can still keep state, but they must bind that state to authenticated identities rather than assuming a transport session is the security boundary.\n\nThe most important example is portable state handles. MCP’s own security best-practices documentation now says servers must not treat possession of a handle as authentication and should bind each handle server-side to the verified user. In an agent workflow, a handle can appear inside model context, tool output or retrieved content. If prompt injection exposes or plants a handle and a server accepts it without checking ownership, the string can become a usable credential for another user’s state. The protocol guidance explicitly recommends per-request authorization and secure, non-predictable handles to prevent that class of failure.\n\nThe same endpoint-first logic applies to authorization and UI. Current MCP security guidance requires OAuth 2.1-style protections including PKCE, exact redirect-URI validation, audience-bound tokens and rejection of dangerous authorization URL schemes. It also treats client-rendered MCP Apps and local MCP servers as surfaces that need sandboxing, consent, URL validation and content-security controls. A weak client or server can therefore turn an otherwise standard agent connection into credential theft, XSS, SSRF or local-code-execution risk.\n\nFor AiToolMap, the practical consequence is that “supports MCP” should not be treated as a security feature by itself. Products that expose powerful MCP tools should be evaluated for token audience validation, per-request authorization, handle ownership checks, local-server consent and sandboxing, and how untrusted tool content reaches the model or rendered UI. The new spec improves scalability and includes authorization hardening, but implementers still have to enforce those guarantees correctly at the endpoint.