Best AI Security markBest AI Security

NOTE · 26 AUGUST 2026

What the MCP 2026-07-28 specification changes for security teams

The verdict

The 2026-07-28 revision, released on 28 July 2026, makes MCP stateless: there is no initialize handshake and no protocol session, and every request carries its own version and client details. For security teams the parts that matter are stricter authorization (clients must validate the iss parameter, credentials are bound to the issuing server, Dynamic Client Registration is deprecated), new headers that let gateways route traffic without reading bodies, and an unchanged instruction that a human should be able to deny tool calls.

The July 2026 revision is the largest change to the Model Context Protocol since it launched. Most of it is plumbing, but several parts touch identity, audit and control.

By Best AI Security editors · 26 August 2026 · 5 min read

What changed in the 2026-07-28 revision?

The MCP maintainers announced the revision on 28 July 2026 and said the protocol's Tier 1 SDKs see "close to half-a-billion downloads a month." The changelog lists these major changes:

  • Protocol-level sessions and the Mcp-Session-Id header are removed from the Streamable HTTP transport. Servers that need state across calls mint explicit handles passed as tool arguments.
  • The initialize handshake is removed. Every request carries its protocol version and client capabilities in _meta, and clients should identify themselves on each request.
  • A new server/discover call, which servers must implement, advertises supported versions, capabilities and identity.
  • Multi round-trip requests replace server-initiated requests: a tool that needs more input returns an input_required result, and the client retries with the answers.
  • Tasks move out of the core protocol into an official extension.

Source: MCP changelog, 2026-07-28 · Reviewed Sep 2026

Which changes affect authorization and identity?

Four changes tighten how MCP clients obtain and hold credentials:

  • Authorization servers should include the iss parameter in authorization responses, per RFC 9207, and MCP clients must validate a present iss against the recorded issuer before redeeming the code. The security considerations page ties this to mix-up attacks, where a malicious authorization server tries to obtain a code issued by an honest one.
  • Client credentials are bound to the authorization server that issued them. Clients must key stored credentials by issuer and must not reuse them with a different server.
  • Clients must declare an application_type during Dynamic Client Registration, which the release post says resolves localhost redirect issues for desktop and CLI applications.
  • Dynamic Client Registration is deprecated as a registration mechanism in favor of Client ID Metadata Documents. It remains available for backward compatibility.

The existing rules stay in place: MCP servers must only accept tokens issued for themselves and must not pass a client's token through to an upstream API.

Source: MCP authorization security considerations · Reviewed Sep 2026

What does statelessness mean for audit trails?

Without a session, there is no connection-level identity to lean on. The specification says clients should identify themselves in each request and servers should identify themselves in each result. The best practices page adds a new attack to watch, state handle hijacking: servers that mint a handle, such as a workflow ID, must not treat possession of it as authentication, and should bind it to the authenticated user.

For anyone building a record of agent activity, the practical effect is that identity has to be read from every request rather than inferred from a connection. The changelog also documents OpenTelemetry trace context conventions (traceparent, tracestate, baggage) in _meta, which gives teams a standard way to link an MCP call to the wider trace.

What do the new headers mean for gateways?

Streamable HTTP requests must now carry Mcp-Method and Mcp-Name headers, and a tool can mirror a parameter into an Mcp-Param header with the x-mcp-header annotation. The release post says this lets gateways, rate limiters and WAFs route and meter traffic without parsing JSON bodies. The tools page warns server developers not to mark passwords, API keys, tokens or personal data this way, because header values are visible to intermediaries.

This helps gateway-based controls for remote servers. It does not change the position of local MCP servers that talk to the agent over stdio on the same laptop: that traffic never passes a network gateway, which is why endpoint and agent-hook controls remain part of the picture. Our MCP security guide covers the gateway or endpoint question.

What stays the same for tool control?

The tools page keeps its warning: "For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations." Clients should prompt for confirmation on sensitive operations, show tool inputs to the user before calling the server, validate tool results before passing them to the model, and log tool usage for audit. Clients must treat tool annotations as untrusted unless they come from trusted servers. These are the behaviors an allow, ask or deny policy puts into practice; see our note on writing one.

What is next on the MCP roadmap?

On 22 August 2026 the maintainers published a roadmap with five priority areas. One is agent identity and enterprise security, built on DPoP and Workload Identity Federation rather than API keys. The roadmap says the Enterprise-Managed Authorization extension is now stable and names Client ID Metadata Documents as the preferred registration path.

Source: The New MCP Roadmap · Reviewed Sep 2026

What should you ask vendors now?

  • Do you support the 2026-07-28 revision, and how do you handle servers still on 2025-11-25 or earlier?
  • For a gateway product: do you use the new Mcp-Method and Mcp-Name headers, and what do you see of local stdio servers?
  • For an endpoint product: do you record which client, user and server were involved in each tool call now that there is no session?
  • Do you flag MCP servers that still rely on Dynamic Client Registration or broad scopes?

Related

Sources