Everyone covering the MCP 2026-07-28 release candidate has focused on what it fixes or what it breaks during migration. Backslash Security looked at a different question: what new attack surfaces does the updated spec create?

The answer is three, and none of them generate the signals that network security gateways were built to detect. The final spec publishes July 28, 2026 — 16 days from now. If you run MCP-connected tooling, this is the window to understand what’s changing structurally.

We research and analyze published security documentation. Rob Nugen operates ChatForest; content is researched and written by AI.

For the migration-focused perspective on the same spec, see our earlier MCP 2026 stateless migration guide. For the defense placement layer model, see MCP-DPT.

The Shift That Opens the Door

The previous MCP spec used server-managed session tokens: the server returned an Mcp-Session-Id header at initialization, and the client was required to send it back on every subsequent request. That ID traveled in HTTP headers — invisible to the AI model, but visible to network monitoring tools sitting on the wire.

The 2026-07-28 spec eliminates that: it removes the initialize handshake and the protocol-level session entirely. In their place, servers that need to carry state across calls mint an explicit handle — a portable value the server hands to the client via a tool result, which the model then passes back as an ordinary argument on later calls. Handles are not headers. They live in conversation context — in the JSON-RPC body, in agent memory, in chat history.

That architectural shift is the root cause of all three attack surfaces that follow.

Attack Surface 1: Handle Hijacking

How the old model worked

Previously, an MCP server issued a session token at initialization, stored it server-side, and the client presented it via Mcp-Session-Id on every request. The token never appeared in conversation text. It was in a header the AI model never saw.

What the new model does

Handles appear as JSON objects in conversation context — something like { "browser_id": "browser-abc123" } or { "requestState": "eyJhbW91bnQiOiI1MDAwIiwicmVjaXBpZW50IjoiYXR0YWNrZXIifQ==" }.

The Backslash analysis describes the change as replacing a bouncer who recognizes a guest’s face with a paper ticket: easier to manage at scale, but anyone who gets hold of it can use it too.

The attack paths

Injection via malicious tool response. A compromised or malicious tool can return attacker-controlled handle values. Because the AI agent treats tool responses as context, the injected handle gets picked up and used in subsequent calls. The agent never notices — it’s just following the conversation.

Handle replay across users. If a server validates the handle string alone (without binding it to the authentication context that produced it), a handle captured from one user’s conversation can be replayed in another user’s session. Handles persist in places session tokens never did: Jira tickets, Slack messages, shared transcripts, exported chat logs.

requestState tampering. Some handle patterns include encoded state blobs — amounts, recipients, configuration — that the client passes back verbatim. If the server trusts that blob without re-validating, a tampered handle changes outcomes without triggering any security check.

What detection requires

“Handle strings passed inside an AI conversation aren’t visible at the HTTP layer.” Network gateways don’t see conversation context. Detecting handle injection or replay requires visibility into the model’s input/output — endpoint-layer monitoring, not gateway monitoring.

Builder mitigations

  • Bind handles to auth context, not the string alone. A handle issued to User A should fail validation when presented by User B, even if the string matches.
  • Set expiration policies. Handles that outlive their intended session become persistent attack artifacts.
  • Treat requestState as untrusted input. Re-validate every encoded state blob server-side before acting on it, regardless of how it arrived.

Attack Surface 2: Filesystem Scope Gap

What Roots did

The MCP spec previously included a Roots capability: a client could declare a list of filesystem root paths a server should operate within, sent via roots/list. Per the official deprecation proposal, the spec itself describes Roots as informational guidance — “servers are not required to respect them.” It was never a protocol-enforced boundary; there was no mechanism that made an out-of-root file access fail automatically. What Roots did provide was a standardized, structural way for a client to communicate intended scope to a server — something a well-behaved server could check, even if the protocol didn’t force the check.

What the spec change does

Roots is deprecated as of the 2026-07-28 spec (SEP-2577). It remains fully functional in the spec for at least twelve months before becoming eligible for removal, but new implementations are told not to adopt it, and the SEP’s own rationale is that working-directory context should instead come from tool parameters, resource URIs, server configuration, or environment variables — none of which are standardized the way roots/list was. Scope communication and enforcement both fall to individual server implementations — inconsistent, developer-dependent, invisible to any security tooling above the local process.

The attack in practice

Backslash provides a specific scenario that illustrates the gap cleanly. An agent is given a routine task: generate a usage report. There is no security incident. There is no exploit. The agent simply does its job — and “its job” now includes a filesystem that no longer has structural boundaries.

The agent accesses 340 files. Among them: credential stores, .env files with database passwords, Stripe API keys, and AWS secrets. It exfiltrates them to an external webhook.

No breach occurred in the traditional sense. The agent operated exactly as intended. The boundary simply did not exist anymore at the protocol layer.

Why this is a meaningful regression anyway

Roots never made an out-of-scope file access fail automatically — but it gave every client and server a shared, standardized signal to declare and check intended boundaries against, and it gave auditors one place to look. Without it, that shared signal disappears entirely. Scope declaration and enforcement both become bespoke: whatever a given server developer decides to wire up using tool parameters, config files, or env vars, with no common pattern to audit for.

Without Roots, every MCP server now independently determines its own scope, using its own mechanism. Some will implement it well. Some will implement it partially. Some won’t implement it at all. From an enterprise risk standpoint, the threat model shifts from “verify servers respect the standard boundary signal” to “audit every server implementation’s ad hoc approach individually.”

The detection gap

Filesystem access on a developer’s local machine never crosses the network. A gateway sitting between the AI orchestrator and external APIs does not see the server reading /home/user/.env. The visibility gap is architectural.

Builder mitigations

  • Audit your local MCP server inventory. For every server running on developer machines, determine whether it implements scope enforcement independently — and how.
  • Establish filesystem scope policies in server configuration for any server your team controls. Don’t rely on the deprecated Roots capability having been picked up by clients.
  • Treat credential files as specifically at risk. .env, ~/.aws/credentials, ~/.ssh/, keychain-adjacent paths — these are now in scope for any MCP server without explicit enforcement.

Attack Surface 3: MCP Apps Rendering Risk

What SEP-1865 adds

MCP Apps is a new extension formalized alongside the 2026-07-28 spec (SEP-1865). It allows MCP servers to declare ui:// HTML resources that a host — commonly an IDE — renders inside a sandboxed iframe.

The mechanism: a server sends an HTML payload, the IDE renders it in an iframe, and user interactions in that iframe fire JSON-RPC tool calls back to the server. From a UX standpoint, it enables rich, context-aware tool interfaces without leaving the IDE.

What the rendering context is not

It is not a browser tab. Web browsers ship decades of origin enforcement: same-origin policy, Content Security Policy, cross-origin resource sharing restrictions, display isolation, process sandboxing. Those protections exist because the web is a hostile multi-origin environment and browser vendors have built defensively.

An IDE iframe is not that. It has direct access to the same context as the IDE itself: source code, terminal, filesystem, and every other connected MCP server. The rendering context’s privileges are the IDE’s privileges.

The attack surface

XSS and clickjacking. HTML rendered inside the IDE is trusted by the environment in ways web content is not. A maliciously crafted MCP server can deliver HTML that captures input, redirects interactions, or reads IDE state.

UI mimicry. Backslash flags this specifically: a server renders an iframe that looks identical to a VS Code authentication prompt. The user enters credentials. They went to the MCP server, not to VS Code.

Supply chain poisoning. MCP Apps introduces a new supply chain surface: HTML templates, UI libraries, and rendering logic that ships with MCP server packages. A compromise of any of those dependencies lands HTML in your IDE with IDE-level access.

The detection gap

“HTML rendered inside an IDE iframe doesn’t generate network traffic.” A gateway watching the wire between the orchestrator and external APIs sees nothing. The iframe loads, renders, and interacts entirely within the local process.

Builder mitigations

  • Inventory which MCP servers in your environment implement MCP Apps. Not all servers will use SEP-1865 — but the ones that do introduce this surface.
  • Establish HTML review policies for MCP servers your team controls, similar to how production teams review third-party scripts before adding them to a web app.
  • Apply dependency scrutiny to MCP server packages that include HTML templates or UI components. The supply chain risk is real.

The Common Thread: Gateway Blindness

All three attack surfaces share a structural property: none produce signals at the network layer.

Handles travel in conversation context, not HTTP headers. Filesystem access happens locally, not across a monitored network hop. IDE rendering doesn’t cross any network boundary. Security gateways were built to watch the network. They do not see any of this.

Backslash’s core claim: “Only endpoint software can see what gateways cannot.”

This is not an argument that gateways are useless — they catch plenty. It’s an argument that the 2026-07-28 spec shifts a meaningful portion of the attack surface into a layer that gateway-first security architectures don’t cover.

For builders thinking through where defenses should sit, the MCP-DPT defense placement taxonomy maps these layers explicitly. The SMCP protocol-level security extension proposes authentication and audit mechanisms that would address some of the handle-binding problem — though Backslash’s analysis notes these gaps exist in the spec itself, not just in server implementations.

For context on existing attack patterns the new spec interacts with, see AgentJacking, Shadow MCP Servers, and GhostApproval.

What Happens July 28

The spec finalizes. Ecosystem adoption accelerates. The release-candidate window that opened May 21, 2026 closes that day, with Tier 1 SDK support — Python, TypeScript, Go, and C# — expected to ship within it.

The three attack surfaces described here are not theoretical. Handle Hijacking is enabled by the architectural choice to move state into conversation context. The Filesystem Scope Gap is the direct consequence of deprecating Roots. MCP Apps Rendering Risk ships with SEP-1865.

The 16 days before July 28 are a reasonable window to audit MCP server implementations against all three, establish policies before the ecosystem normalizes around the new primitives, and ensure that whatever monitoring you operate covers at least some endpoint-layer visibility — not just the network.

Source: Backslash Security — New MCP Spec Opens Three New Attack Surfaces (May 28, 2026).