The July 2026 MCP specification overhaul fixes longstanding protocol vulnerabilities. It also introduces five new attack surfaces that shift security responsibility from the protocol to the implementer. This guide maps what changed, what it means, and what evidence your organization should be producing.
Who this is for: MCP server implementers, platform security engineers, compliance teams governing AI tool integrations, and assessors evaluating MCP deployment security. Assumes familiarity with the Model Context Protocol and its role in AI agent architectures.
CRITICAL ASSESSOR NOTICE: SWT3 witness anchors record that a governance event occurred and capture its computational factors. They do not replace assessor judgment. The assessor must independently verify that the substance of each control implementation meets the requirements of the applicable framework. Anchors provide the evidence trail; the assessor determines whether that evidence is sufficient.
The MCP 2026-07-28 release candidate represents the most significant overhaul of the Model Context Protocol since its introduction. The specification establishes a 12-month deprecation window for legacy protocol versions, meaning organizations have until July 2027 to migrate.
The major architectural changes:
| Feature | Previous Spec | 2026-07-28 |
|---|---|---|
| Protocol Core | Stateful, session-based | Stateless, client-managed state |
| Authentication | Implementation-defined | OAuth 2.1 mandatory |
| Extensibility | Custom capabilities | Formal Extensions framework |
| Long-running tasks | Blocking calls | Tasks (async, resumable) |
| Web integration | Not specified | MCP Apps (web-rendered AI content) |
| Server-initiated prompts | Allowed | Removed |
| Deprecation policy | None | 12-month rolling window |
These are meaningful improvements. The move to OAuth 2.1, the removal of server-initiated prompts, and the formal deprecation policy all address real security concerns that the community identified in production deployments. But every architectural change introduces new surfaces, and this specification is no exception.
Credit where it is due. The 2026-07-28 specification addresses several vulnerabilities that had been actively exploited or identified in security research:
Organizations still running legacy MCP implementations should migrate. The vulnerabilities addressed by the new spec are well-documented and actively targeted.
The architectural changes that fix legacy vulnerabilities also create new surfaces. This is not a design flaw; it is an inherent trade-off in protocol evolution. The important thing is that organizations understand where the new risks lie and produce evidence that they are managing them.
The move from server-managed sessions to client-managed state means that state objects now travel with the request. If a client's state object can be intercepted, modified, or replayed, an attacker can hijack an active workflow, inject context into a conversation, or access data from a different session.
The previous spec kept state on the server, where it was protected by the server's security boundary. The new spec delegates state management to the client, which may have a weaker security posture than the server.
_meta Object InjectionThe new spec introduces the _meta object as a standard extensibility point for attaching metadata to any MCP message. This creates a new injection vector: an attacker who can insert arbitrary key-value pairs into the _meta field may be able to escalate privileges, bypass policy checks, or inject instructions that downstream processors treat as authoritative metadata.
Because _meta is designed to be open-ended, there is no built-in schema validation. The boundary between "metadata" and "control data" depends entirely on how each implementer processes the field.
MCP messages can carry both HTTP headers (for transport-layer routing and authentication) and JSON-RPC body content (for application-layer semantics). When these two layers disagree, security controls can be bypassed. For example, authentication tokens in headers might grant one level of access while the JSON-RPC body requests a different resource, or sensitive data mapped into HTTP headers for routing purposes becomes visible to intermediary proxies.
MCP Apps allow servers to deliver web-rendered content to clients. This is a powerful feature for building rich AI-powered interfaces, but it introduces classic web security risks into the AI agent ecosystem. A malicious or compromised MCP server can deliver content containing scripts that exfiltrate data, display deceptive interfaces for credential harvesting, or manipulate the user's view of AI-generated outputs.
Because MCP Apps render within the context of the AI agent's interface, users may extend higher trust to this content than they would to an arbitrary web page.
The formal Extensions framework allows third-party capabilities to be loaded into MCP servers. Extensions inherit the trust context of the server that loads them. A trusted MCP server that loads an untrusted extension effectively grants that extension the server's credentials, network access, and data visibility.
This is analogous to the browser extension trust model, where a trusted browser that loads a malicious extension exposes the user's entire browsing context. The MCP specification does not define an isolation boundary between server and extension.
Each new attack surface corresponds to one or more SWT3 procedures that record evidence of controls operating.
The MCP procedure set covers tool registration (MCP.1), tool invocation witnessing (MCP.2), resource access attestation (MCP.3), prompt governance (MCP.4), and transport security (MCP.5). Together, these produce evidence that the MCP deployment's core operations are governed.
Maps to: All five attack surfaces. MCP.2 (tool invocation) is particularly relevant for Extensions (Surface 5), and MCP.5 (transport) for header/body mismatches (Surface 3).
Verify that the organization produces MCP procedure attestations for the new spec's features specifically, not only for legacy capabilities. Extensions and MCP Apps are new attack surfaces that require new evidence.
Records that a tool was invoked, what parameters were passed, and what result was returned. For MCP deployments, this witnesses every tool call passing through the protocol, creating a forensic trail that can reconstruct activity in the event of a compromise.
Maps to: State Object Hijacking (Surface 1) and Extension Trust Boundaries (Surface 5). A hijacked state object or malicious extension will produce tool invocations that appear in the witness trail.
Verify that tool witnessing captures the source of each invocation (client vs. extension) so that anomalous patterns originating from extensions can be distinguished from legitimate client requests.
Records that input and output guardrails were evaluated for a given interaction. For MCP Apps (Surface 4), guardrail attestation witnesses that content rendering passed through safety checks before being displayed to the user.
Maps to: MCP Apps XSS (Surface 4) and _meta Injection (Surface 2). Guardrail attestation demonstrates that content was evaluated before rendering and that metadata fields were validated before processing.
For MCP Apps specifically, verify that the guardrail attestation covers rendered content, not only text responses. XSS payloads embedded in rich content will bypass text-only guardrails.
Records security-relevant events including authentication failures, authorization denials, anomalous access patterns, and policy violations. For the new MCP spec, this captures OAuth 2.1 token events, header/body mismatch detections, and extension loading events.
Maps to: HTTP Header/Body Mismatch (Surface 3) and Extension Trust Boundaries (Surface 5).
Verify that security event witnessing includes extension lifecycle events (load, unload, error) and OAuth token lifecycle events (grant, refresh, revoke). These are new event types specific to the 2026-07-28 spec.
The 12-month deprecation window (expiring July 2027) gives organizations time to migrate, but governance planning should begin now. Key considerations:
_meta validation. Define a schema or allowlist for the _meta fields your implementation accepts. Reject or log unexpected keys rather than passing them through silently.The migration period itself is a governance event. Organizations should produce witness evidence documenting the migration timeline, the configuration changes applied, and the validation performed after each change. An assessor reviewing a post-migration deployment will want to see evidence that the migration was governed, not just that it was completed.