Since the release candidate landed, I have seen MCP 2026-07-28 summarized as “MCP goes stateless.” It is a good headline. It is also wrong in a way that matters for security.

The protocol session is going away. Application state is not. Someone still has to protect that state, authorize access to it and clean it up. That someone is now, unmistakably, the server implementation.

One date check before going further: the final specification is scheduled for July 28. Today the normative text is still the release candidate locked on May 21, with beta SDKs published in late June. Teams can test it. They should still call it a draft.

What is actually being removed

Under the 2025-11-25 revision, a Streamable HTTP connection began with an initialize handshake. The server could return an Mcp-Session-Id, and later requests carried that identifier. The protocol managed a long-lived session.

The 2026-07-28 release candidate removes the initialize/initialized handshake and the protocol-level session. Protocol version, client information and capabilities move into per-request metadata. A new server/discover method lets clients fetch server capabilities when needed.

Now consider a shopping basket or a remote browser. They still need continuity. The server can return an ID and the model can send it back later as a normal tool argument. Any server instance can process the next request.

That is useful. It also means the ID is untrusted input arriving from the client. MCP is no longer carrying the continuity for you.

Server-to-client interaction changes as well. A server may ask for input only while processing a client request. Multi Round-Trip Requests return an InputRequiredResult with opaque requestState; the client collects the answer and retries the original request. Open-ended unsolicited prompts are no longer part of the core flow.

For Streamable HTTP, Mcp-Method and Mcp-Name make operations visible to gateways without parsing the JSON-RPC body. Requests also carry the protocol version. The server must reject a request when routing headers and body disagree.

The security win is real

There is no Mcp-Session-Id left to steal and replay. Security state is no longer quietly attached to one server instance. A load balancer does not need sticky routing just to satisfy MCP.

Server-initiated interaction is narrower too. A server cannot prompt a client whenever it wants; it can ask for input only while handling an active request.

Authorization is more explicit too. The revision tightens how clients validate the authorization issuer, how registered credentials stay bound to that issuer, and how OpenID Connect client types and refresh-token flows are described. These changes improve OAuth deployment. They do not make an MCP server safe by default.

These are meaningful improvements. They remove mechanics that were easy to misuse. They do not make an MCP server safe by default, and the draft does not claim otherwise.

Where I would look for bugs

Akamai's analysis describes the trade well. Session hijacking at the protocol layer shrinks. Application state, interactive interfaces and long-running work deserve more attention.

State returned by the client. Handles and requestState values cross a trust boundary every time they come back. A predictable or unsigned handle can let one workflow resume another. A handle that is not bound to a tenant can become a cross-tenant bug. Sign it or keep the state server-side, bind it to the operation and give it an expiry.

Per-request metadata. A field does not become trustworthy because it lives in _meta. Reserved MCP fields have protocol meaning. Application fields are still client input. I would not authorize anything from them without authenticated server-side context.

Routing headers. A gateway may read Mcp-Method and Mcp-Name while the application reads the JSON-RPC body. If they disagree, reject the request. Do not let two layers make two security decisions about the same operation.

MCP Apps. The sandboxed iframe is useful isolation. It is not a phishing detector, a safe renderer or a guarantee that visible data cannot leave the interface. Treat the template as third-party code, because it is.

Tasks. Work can outlive the request that created it. Without quotas, deadlines and cancellation, a cheap request can create an expensive background process. This is where reliability and security become the same problem.

My pre-release checklist

July 28 is not a forced migration. Older versions will continue to negotiate, and deprecated features have a removal window. I would still use the release candidate to check these assumptions now:

  • Treat every returned state handle and application-defined metadata field as untrusted input. Protect integrity, bind it to a tenant and operation, and enforce expiry.
  • Validate routing headers against the JSON-RPC body before authorization or dispatch.
  • Validate authorization issuer and resource audience. Keep registered credentials bound to the issuer that created them.
  • Keep secrets and personal data out of routable metadata and infrastructure logs.
  • Put concurrency limits, budgets, deadlines and cancellation on every long-running task.
  • Review MCP App templates, content security policy and data exposure before a host renders them.
  • Test version negotiation against both the release candidate and 2025-11-25. Beta SDKs do not opt every application into the new revision automatically.

One assumption deserves its own line. Sticky sessions and a shared session store are not an authorization boundary. Keep them for an older revision if you need them operationally. Do not make them carry the security model.

The boundary after the session

Four months ago I wrote about the missing identity layer for agents. The new revision makes request context more explicit and removes an entire class of session mechanics. That is real progress.

This release confirms a pattern I keep returning to. As MCP gets easier to operate, the hard questions move closer to execution. Who issued the request? Which tenant owns the state? Does this authorization cover this resource? How much work will the server allow before it says no?

The protocol defines the exchange. The implementation has to enforce the boundary.

Primary sources

Status reviewed on July 21, 2026. The final specification is scheduled for July 28, so implementation details should be checked again after publication.