On July 28, 2026 — four days from now — the Model Context Protocol ships its largest revision since launch. The GitHub MCP Server already supports it ahead of the official release, signaling how quickly the ecosystem is moving. For healthcare security teams that have been tracking MCP as a governance concern, this update is worth reading carefully: the headline is a stateless protocol core, but the security implications run deeper than a transport refactor.
This post covers what's actually changing in the `2026-07-28` spec, what it means for the MCP security posture your organization is building, and where the new attack surface lives.
What's Actually Changing
The `2026-07-28` release is a breaking-change revision built around four major areas: a stateless protocol core, a formal extensions framework, authorization hardening, and a deprecation policy. Each has security relevance beyond the developer-experience story.Stateless core: what it removes and what that means
The most architecturally significant change is the elimination of protocol-level sessions. In the current `2025-11-25` spec, every MCP interaction begins with an `initialize` handshake that establishes a session ID. Every subsequent call carries that session ID, which pins the client to a specific server instance. Horizontal scaling required sticky routing and a shared session store — infrastructure overhead that also represented state that needed to be secured.The new spec removes the `initialize`/`initialized` handshake entirely and eliminates the `Mcp-Session-Id` header. Protocol version, client info, and capabilities that were exchanged once at session start now travel in `_meta` on every individual request. Any server instance can handle any request — no sticky routing, no shared session store required.
For security teams, this is a meaningful architectural change in both directions. On the positive side, eliminating the session store removes a stateful component that represented a target: a compromised session store could expose active client connections across the entire deployment. On the negative side, the per-request `_meta` payload now carries what was previously established once at handshake time. Every request is self-contained, which means every request is a complete trust surface. The authentication and authorization decision happens on every call rather than being established once and inherited.
The GitHub MCP Server's implementation of this change is instructive. Their three-part adaptation — removing Redis session writes from `initialize`, eliminating database reads from every call, and moving to `Mcp-Method` header inspection instead of deep packet inspection of request bodies — illustrates what the stateless migration looks like in a production deployment. The deep packet inspection point is particularly relevant: previously, the GitHub server had to read the payload of every single request to extract values needed for logging and secret scanning. The new spec puts those values in HTTP headers guaranteed to be present, which is both a performance improvement and a security improvement — header inspection is a well-understood control surface, payload inspection is not.
The new transport headers and what they enable
The stateless spec introduces required `Mcp-Method` and `Mcp-Name` headers on all Streamable HTTP requests. The spec requires that servers reject any request where the header values disagree with the body content — a tamper-detection control baked into the protocol. For security teams, this is significant: it means load balancers, API gateways, and WAFs can now route and filter MCP traffic on operation type without inspecting encrypted payloads. Blocking `tools/call` to specific tool names at the gateway layer becomes straightforward in a way it wasn't before.The new `ttlMs` and `cacheScope` fields on list and resource read results similarly give security-relevant infrastructure something to work with. `cacheScope` in particular — indicating whether a cached response is safe to share across users — is the kind of data boundary enforcement that matters in multi-tenant clinical environments.
W3C Trace Context propagation is now formally specified with fixed key names (`traceparent`, `tracestate`, `baggage`). For healthcare organizations that need audit trails of AI agent actions across distributed systems, this is the spec-level foundation for end-to-end observability of MCP tool calls. A tool call that starts in a clinical decision support agent can now produce a correlated trace through the MCP client, the MCP server, and whatever downstream systems that server calls — in a single span tree visible in an OpenTelemetry-compatible backend.
Server-to-client requests restructured
The old spec had an underspecified path for servers to request something from the client mid-call — for example, an elicitation prompt asking the user to confirm an action. In a stateless protocol, holding a Server-Sent Events stream open for this isn't viable.The new spec's Multi Round-Trip Requests mechanism replaces this cleanly. When a server needs input mid-processing, it returns an `InputRequiredResult` with the question and an opaque `requestState` token. The client presents the question, gathers the answer, and re-issues the original call with the response and the echoed token. Any server instance can handle the retry because everything needed is in the payload.
The security properties here are notable. The spec now requires that server-initiated requests may only be issued while the server is actively processing a client request — elicitations can't arrive out of context. Every user prompt traces back to something they or their agent initiated. For clinical workflows where unexpected AI prompts could be confusing or exploitable, this constraint is meaningful: an MCP server cannot interrupt a clinician with an unsolicited request.
Authorization Hardening: Building on EMA
The authorization hardening in `2026-07-28` is the direct successor to the Enterprise-Managed Authorization extension we covered when it went stable in June. EMA established centralized governance for MCP access decisions; this release tightens the OAuth and OpenID Connect plumbing underneath it.The most security-relevant addition is mandatory validation of the `iss` parameter on authorization responses per RFC 9207. This is a mitigation for authorization server mix-up attacks — a class of vulnerability where a client accepts a valid authorization response from the wrong server. In MCP's deployment pattern, where a single client connects to many servers, this attack surface is larger than in traditional single-server OAuth deployments. The spec now requires `iss` validation and signals that future versions will reject responses that omit it, so MCP-capable authorization servers should be supplying it now.
Dynamic Client Registration handling is also improved: clients now declare their OpenID Connect `application_type` during registration, avoiding the common failure mode where a desktop or CLI client gets defaulted to `"web"` by the authorization server and then rejected for using a localhost redirect URI. Clients bind registered credentials to the issuing authorization server's `issuer` and must re-register when a resource migrates between authorization servers — a control that prevents credential reuse across authorization boundaries.
For healthcare organizations that have begun evaluating MCP vendor implementations against the EMA post's checklist (OAuth 2.1 with PKCE, Resource Indicators, EMA support), this release adds `iss` validation and proper `application_type` handling to that list. Vendors who haven't shipped these controls yet have a clear implementation target.
The deprecations and what they signal
Three features are formally deprecated in this release: Roots, Sampling, and Logging.| Deprecated Feature | Replacement | Security Relevance |
|---|---|---|
| Roots | Tool parameters, resource URIs, or server config | Explicit scope definition moves to the tool layer where it's auditable |
| Sampling | Direct LLM provider API integration | Removes indirect model access path through MCP server |
| Logging | stderr (stdio) or OpenTelemetry (structured) | Aligns with standard observability infrastructure |
The Sampling deprecation is particularly relevant from a security standpoint. Sampling allowed MCP servers to make LLM calls through the client — a server could request that the client's language model process something on its behalf. This indirect model access path introduced a surface where a compromised or malicious MCP server could potentially influence the client's model in ways the user didn't initiate. Moving model access to direct LLM provider API integration eliminates this indirection. Vendors running MCP servers with Sampling implementations should be on your migration watchlist — they're operating a deprecated pattern with a security-relevant removal timeline.
The formal deprecation policy itself is worth noting: features enter a twelve-month minimum window between deprecation and the earliest possible removal. Healthcare security teams building MCP governance programs now have a predictable evolution timeline to plan against.
Extensions as a Security Governance Concern
The formal Extensions framework in `2026-07-28` deserves attention beyond the two official extensions it ships with. Extensions are now identified by reverse-DNS IDs, negotiated through capability maps, and versioned independently of the core spec. This is how MCP capabilities will evolve going forward — new features ship as extensions first, and the core spec stays stable.For security governance, this creates a new assessment requirement: when evaluating an MCP server, you now need to assess not just its core spec compliance but which extensions it implements and whether those extensions are official (in the spec's Extensions Track) or bespoke. An MCP server implementing an unofficial, non-standard extension is running code that hasn't been through the SEP review process and may not have the security review that official extensions receive.
MCP Apps — the server-rendered UI extension — is the higher-risk of the two official extensions from a healthcare security standpoint. The extension lets MCP servers deliver interactive HTML interfaces that hosts render in a sandboxed iframe. The spec requires that UI templates be declared ahead of time so hosts can prefetch, cache, and security-review them before execution, and all UI-initiated actions go through the same JSON-RPC audit path as direct tool calls. But "sandboxed iframe" security depends entirely on how the host implements the sandbox. Healthcare organizations evaluating MCP-connected tools that implement MCP Apps should be asking vendors specifically: how is the iframe sandbox configured, what CSP directives are applied, and how are UI-initiated actions logged relative to direct tool calls?
What This Means for Healthcare
The `2026-07-28` spec changes the threat model for MCP deployments in ways healthcare security programs need to account for — both the improvements and the new surface area.Update your MCP vendor assessment checklist
The EMA post established an initial checklist: OAuth 2.1 with PKCE, Resource Indicators (RFC 8707), EMA support. This release extends it. Add `iss` parameter validation on authorization responses (RFC 9207), proper `application_type` declaration during Dynamic Client Registration, and — if the vendor implements MCP Apps — sandbox and CSP configuration for rendered UIs. Vendors who are still running Roots or Sampling implementations are operating against a deprecation clock; flag those for migration timelines in your assessments.Gateway and WAF configuration is now viable
The new `Mcp-Method` and `Mcp-Name` headers, combined with the server-side requirement to reject requests where headers and body disagree, make operation-level filtering at the gateway layer practical for the first time. Healthcare organizations running MCP servers behind API gateways should be building rule sets around these headers — blocking specific tool names, rate-limiting by operation type, and alerting on header/body disagreements that may signal tampering.Observability infrastructure needs updating before July 28
The formal W3C Trace Context specification and the OpenTelemetry replacement for the deprecated Logging feature both point the same direction: MCP audit trails should be flowing into your OpenTelemetry infrastructure, not bespoke logging implementations. If your current MCP observability relies on the deprecated Logging feature or on payload inspection for tracing, the migration path is clear and the twelve-month deprecation window gives you time — but the planning should start now, not when the feature is removed.The stateless migration creates a transition window
The tier 1 SDKs have all shipped backward-compatible beta support, which means the ecosystem is in a mixed state: some clients and servers are running `2026-07-28`, others are still on `2025-11-25`, and implementations need to handle both. The GitHub MCP Server's wrapper approach — making both SSE streams and the new Multi Round-Trip mechanism work simultaneously — is the pattern to look for from your vendors. During this transition window, MCP implementations in your environment are handling two protocol versions with different session and authentication models. That's a security assessment point: how does each vendor handle version negotiation, and what happens when an older client connects to a new server or vice versa?The Bigger Picture
The MCP spec has moved faster than most security governance frameworks can track. The authorization model has evolved substantially in under eighteen months — OAuth 2.1 as the foundation in early 2025, Resource Indicators in mid-2025, Client ID Metadata Documents in November, EMA in June 2026, and now `iss` validation and application type hardening in July. Organizations building MCP governance programs are chasing a moving target, and that's before accounting for the extensions ecosystem where new capabilities can ship on their own timelines.The formal deprecation policy introduced in this release is a meaningful improvement for governance planning. A twelve-month minimum window between deprecation and removal means healthcare security programs can align MCP vendor assessments with annual review cycles rather than scrambling to respond to point releases. The conformance test suite requirement — a Standards Track SEP can't reach Final status without matching conformance tests — gives assessors a testable standard to hold vendors to.
The stateless architecture that ships July 28 is the foundation the spec maintainers describe as designed to hold for a long time. For healthcare security programs, that's actually useful: the transport security model is stabilizing just as the extension and authorization layers are maturing. The right moment to build a durable MCP security program is not after the next breaking change — it's now.
This is entry #4 in the MCP Security series. For related coverage, see MCP Gets Its Enterprise Authorization Layer — What the EMA Extension Means for Healthcare AI Governance.