The Model Context Protocol project has published the 2026-07-28 release candidate, a breaking revision that changes how remote servers handle sessions, authorization, long-running work, and user interfaces. The official announcement says the final specification is scheduled for July 28, 2026. This brief focuses on the security work operators should verify before treating the new version as a routine compatibility update.
What the official release candidate changes
The maintainers describe a stateless protocol core. The earlier Streamable HTTP design used an initialization handshake and an Mcp-Session-Id header; the proposed 2026-07-28 flow removes that protocol-level session and carries request context in the message metadata. The announcement also adds operation headers for routing, cache metadata for list and resource results, and documented W3C Trace Context propagation.
Stateless transport is not the same as stateless business logic. An application that needs continuity must carry an explicit handle, such as a job or basket identifier, and protect it like any other authorization-sensitive input. Removing hidden transport state can make deployments easier to scale, but it also means teams must re-check where identity, tenancy, replay resistance, and authorization context actually live.
Authorization hardening is the operational priority
The release announcement highlights several authorization changes intended to align MCP deployments more closely with OAuth and OpenID Connect. It calls out validation of the iss parameter in authorization responses, application-type declarations during dynamic registration, binding registered credentials to the issuing authorization server, refresh-token guidance, and clearer discovery behavior.
The current MCP authorization documentation remains the implementation reference for the published specification and requires protected-resource metadata discovery for HTTP servers. It also requires clients to support both OAuth authorization-server metadata and OpenID Connect discovery. Operators should not infer that a client is protected merely because it can obtain a token: issuer, audience, redirect URI, state, scope, and authorization-server selection still need explicit validation.
Review the boundary, not only the handshake
The protocol security guidance identifies token passthrough as an anti-pattern and says an MCP server must not accept tokens that were not explicitly issued for that server. It also documents confused-deputy risks in OAuth proxy designs, SSRF risks during metadata discovery, session hijacking, local-server compromise, and scope overreach.
Those controls remain relevant after protocol sessions disappear. A deployment review should map the authenticated principal and resource audience for every request, determine how explicit application handles are bound to users or tenants, and confirm that a retry or task continuation cannot be replayed across identities. Gateways should validate the new operation headers against the request body rather than trusting either representation alone.
MCP Apps and Tasks add new review surfaces
The release candidate makes MCP Apps a first-class extension for server-rendered interfaces in a sandboxed iframe. The announcement says tool-declared UI templates can be reviewed and cached before execution, and UI actions use the same JSON-RPC and consent path as direct tool calls. That is a useful security shape, but it does not remove the need to review iframe isolation, origin policy, content security policy, resource loading, and the privileges available to each UI action.
Tasks also move from an experimental core feature into an extension with a stateless lifecycle. Servers may return a task handle and clients drive retrieval, updates, and cancellation. Teams should define ownership, expiry, authorization, and cancellation semantics for those handles before enabling long-running operations. A task identifier is not, by itself, proof that the caller is entitled to observe or cancel the underlying work.
Tool schemas and observability deserve regression tests
The proposed release expands tool schemas to JSON Schema 2020-12, including composition and references, while warning implementations to bound schema depth and validation time and not automatically dereference external URLs. That creates a concrete defensive test list: constrain parser resources, reject unexpected external fetches, validate both input and output, and preserve clear limits around structured content.
The release also documents trace context propagation and deprecates stderr logging for stdio transports in favor of structured observability. Security teams should test that traces do not carry secrets, that tool calls remain attributable across gateways and downstream services, and that deprecation does not silently remove the evidence needed for incident response.
Operator checklist before migration
- Pin the version. Record which clients, SDKs, servers, gateways, and extensions implement the release candidate or final specification; do not mix incompatible assumptions about sessions and headers.
- Rebuild the identity map. Document issuer, audience, scopes, redirect URIs, explicit task or application handles, and tenant binding for each protected operation.
- Test failure paths. Exercise mismatched headers, invalid issuers, stale handles, unauthorized task reads, cancellation by another principal, oversized schemas, and discovery responses that point outside approved network boundaries.
- Review UI and extension trust. Treat MCP Apps and third-party extensions as separate code and content supply-chain surfaces with their own approval, isolation, and update controls.
- Preserve evidence. Confirm that authentication, consent, tool invocation, task state, gateway routing, and downstream calls remain correlated without exposing credentials in traces.
Assessment and uncertainty
This is a standards-change brief, not a vulnerability disclosure. The primary announcement is a release-candidate document published by the MCP maintainers, and the final specification date stated there is a schedule claim from that source. MCPwatch has not independently tested an implementation, certified an SDK, or confirmed that a particular vendor deployment is compatible. Operators should use the final specification and their selected SDK’s release notes when they become available.