The Model Context Protocol's (MCP)'s largest revision since its initial launch shipped on July 28. By the end of the first day, all four Tier 1 SDKs were already speaking the new version, and Cloudflare's Agents SDK had support in place from day zero, with customers such as Sentry and Linear picking it up right away, meaning the surface this article describes is already live in production. A new 12-month deprecation policy keeps the changes in place through at least mid-2027. Most of the coverage has focused on what improvements have been made: A stateless core that scales on ordinary HTTP, OAuth-native authorization, and server-rendered UIs via MCP Apps.
For the past two years, I have been building agent systems that connect to enterprise tools through MCP. The obvious interpretation of the new spec is that it is a scaling upgrade. However, the more important story is that there has been a substantial shift in where security obligations fall. The new spec shifts enforcement from the protocol to your endpoints and developers. If your security architecture does not evolve alongside this change, you will inherit attack surfaces your network-layer tools can't see.
To date, MCP security coverage has focused on permissive servers, missing authentication, and tool poisoning, and the scale behind it is not small. Each month, MCP's Tier 1 SDKs clear close to half a billion downloads, and the TypeScript and Python SDKs have each passed a billion in total. A Censys scan in late April found 12,520 MCP services exposed to the public internet, on a protocol that requires no authentication by default. OX Security reported that a single design flaw in the STDIO transport put as many as 200,000 servers at risk.
In May, the NSA's Artificial Intelligence Security Center published its own MCP guidance, warning that adoption has outpaced the protocol's security model. This is a different problem. The July 28 spec changes the reason those risks compound: The session is no longer the unit of control. Each request is treated as an independent unit, state moves into portable handles, and MCP Apps offload UI rendering to the AI client. Same family of failures, but a different control plane under them.
For platform teams, this is an exercise in scaling. It's also a pivot in security. Here's what has changed, and what you need to do about it.
What actually changed (and why security teams should care)
MCP is now stateless at the protocol level. The Mcp-Session-Id header and the initialize/initialized handshakes that linked clients to specific server instances have been removed. The protocol version, client information, and client capabilities are conveyed inline within each request, allowing any server instance to process any request.
While this showcases solid engineering design, it also entails a shift in terms of security considerations. Here is what changed and what it means for your defense.
Spec change | What it enables | Where security now lives |
Stateless core (sessions removed) | Round-robin load balancing, autoscaling | Per-request enforcement at the gateway, every call must be inspected, not just the session start |
Portable state handles | State passed explicitly between tool calls | Handle validation at the endpoint, a handle planted or read via prompt injection is a valid credential |
MCP Apps (server-rendered HTML) | Interactive UIs inside the AI client | The endpoint/IDE, stored XSS now lives in AI-rendered HTML inside a sandboxed iframe |
OAuth-native authorization | Standard identity flows | Audience-bound token validation, tokens minted for one server must not replay against another |
Tasks extension | Long-running async work | Scope enforcement, without sessions, task ownership must be bound to identity, not connection |
The three new attack surfaces
Backslash and Akamai have each mapped where the new spec opens the attack surface, and Microsoft's tool-poisoning research shows why that shift bites once agents move from reading to acting. Three new attack vectors emerge, all of them on the endpoint.
1. Stored XSS in MCP Apps: MCP Apps lets a server ship interactive HTML that the host renders in a sandboxed iframe. This brings a classic web vulnerability into the AI ecosystem. An attacker stores malicious HTML or JavaScript through an MCP tool; when an agent or another user views it, the script runs inside the app's interface. The sandbox limits full takeover, but the client is layered above source code, terminals, filesystems, and every other connected MCP server.
2. Handle hijacking: Instead of sessions, portable handles are used, but a handle is merely a string within the conversation, and anyone able to insert or read that string can exploit it. A prompt-injection payload in a Jira ticket or a tool response can hand an attacker a valid handle without ever touching the server. The new spec enables handle hijacking; prompt injection is the method. What you need is per-request handle validation, not hygiene at the conversation layer.
3. The network's enforcement gaps remain invisible: State has moved out of the transport and into the application, so the security work that used to happen at the session layer now has to happen deliberately, on the endpoint. These threats begin on the other side of the boundary where network visibility terminates.
What to do, in priority order
The platform migration and the security transition are the same work, just from different angles. Below is my thought process. I have ordered everything by risk, not dates.
We'll start with exposure of MCP Apps: Identify which MCP servers your teams use that can render HTML UI to a client or IDE. Set a policy regarding the review of HTML that is rendered, just like you would review a third-party script that gets sent to a production website. If you don't know which servers can render UI, you can't govern it.
Move enforcement to the request level: If decisions based on session state were made by your MCP gateway, that is a broken design. It needs to be set up to inspect and enforce at every single call. Adopt the hardened authorization model: OAuth 2.1 with PKCE, per-client consent, strict redirect-URI matching, and audience-bound tokens (meaning a token issued for one server cannot be used on another). Put an identity-aware gateway in front of every server and reject any call without a valid, audience-bound token.
Handles are considered untrusted input: Validate that the identity presenting a handle is the one it was issued to. Implement conversation-layer hygiene that removes or flags instruction-like content in tool outputs and retrieved documents, because that is where planted handles arrive.
Instrument the endpoint: An identity-aware gateway enforces the request, but it lacks knowledge of the MCP Apps rendering, local server operations, or execution in the IDE. That needs a different tool. Build endpoint visibility for the host process, local MCP servers, and client rendering. If your stack is fully network-based, this is the gap the new spec opens.
Unit tests will not identify what breaks here: A spec change looks fine in unit tests and will fail in a live agent loop. Run your migrated servers against real models driving real workflows. Look out for state that leaks across server instances, handles reused across scopes, and unexpected UI content.
Plan for the deprecations: Roots, sampling, and logging are deprecated with this spec, and so is the legacy HTTP+SSE transport, which for most platform teams forces migration work. The 12-month clock started on July 28, and as a result the removal comes no earlier than mid-2027. Start planning that transition now. Deprecation windows always seem long, and then they feel quite short.
The strategic point
The MCP maintainers made a conscious decision: The protocol does not enforce security for you. That can be justified. For enterprise-scale agents, a stateless protocol on commodity infrastructure is the right choice. But "the protocol doesn't enforce security" means "you do," at the endpoint, on every request, every handle, every rendered UI.
Companies that consider this a migration will deliver the new spec with the same security posture they had for the stateful protocol, and that posture is misaligned with the current threat surface. On the other hand, companies that treat this as a security transition, moving enforcement to the request level, putting controls at the endpoint, and governing MCP Apps before they proliferate, will be the ones whose agent deployments outlast contact with a genuine attacker.
The spec has evolved. So the real question is: Will your security architecture keep pace?
Nik Kale is a principal engineer specializing in enterprise AI platforms and security.
Welcome to the VentureBeat community!
Our guest posting program is where technical experts share insights and provide neutral, non-vested deep dives on AI, data infrastructure, cybersecurity and other cutting-edge technologies shaping the future of enterprise.
Read more from our guest post program — and check out our guidelines if you’re interested in contributing an article of your own!