The 2026-07-28 release candidate is the largest MCP revision since launch. It makes the protocol core stateless, formalizes extensions for server-rendered UIs and long-running Tasks, strengthens alignment with OAuth and OpenID Connect deployments, and requires conformance coverage for Standards-Track proposals that change observable protocol behavior. It is real maturation.
But hardening the protocol is not the same as shrinking its attack surface. Several of these changes relocate it.
Stateless, with caching
A remote server can now operate behind a round-robin load balancer, while clients may cache tools/list responses for as long as the server's ttlMs permits. That changes the persistence characteristics of tool poisoning. A poisoned tool description fetched once may continue reaching the model from a client-side or shared cache for the TTL window, without another server fetch at which it might be detected or corrected.
The relevant controls are cache scope, metadata integrity, invalidation, and revalidation. This is the surface our MCP tool-poisoning suite exercises: nested-schema injection, tool-fork fingerprinting, and encoded-payload detection (mcp_tool_poisoning_harness, MCP-014).
MCP Apps: server-controlled UI reaches the human
MCP Apps normally execute inside a sandboxed iframe, which limits direct access to the host. But sandboxing the code is not the same as establishing the integrity of what the interface communicates. A server now controls content that the user may rely on when interpreting or approving an action.
Recent research on invisible Unicode TAG-block payloads demonstrated a related fidelity gap in tool metadata: content can be absent from the human approval view while remaining present in the model's input. MCP Apps expand the need to test the same underlying invariant across interactive UI: does the action represented to the human match the data and authority delivered to the model and server? That is approval-integrity territory (AUTHZ-003).
Tasks: state that lives over time
Tasks existed experimentally in the previous specification and now move into a formal extension for long-running work. That creates durable identifiers, state transitions, deferred results, and later retrieval. Each becomes a security boundary: unauthorized task access, cross-principal task confusion, invalid state transitions, cancellation races, and result substitution before retrieval. This is A2A-006-class task-state manipulation applied to MCP Tasks.
The authorization hardening is genuine
Closer OAuth 2.1 and OpenID Connect alignment, audience validation, and RFC 9207 iss validation reduce authorization-server mix-up and token-confusion risks. The identity suite already checks OAuth discovery and scope enforcement (STD-001, AUTH-003). These controls protect who may reach a server and which authority they carry; they do not determine whether an authorized tool invocation is safe.
The most important line in the RC may be the quietest: a Standards-Track proposal that changes observable protocol behavior cannot reach Final until a matching conformance scenario exists. That makes testable behavior part of the specification lifecycle rather than an implementation afterthought.
A stateless protocol does not eliminate security-relevant state. It moves that state into caches, Tasks, applications, authorization infrastructure, and host-mediated UI. Those are the surfaces worth testing before July 28.
Source: The 2026-07-28 MCP Specification Release Candidate. Test identifiers from the open agent-security harness.
Top comments (0)