MCP's Biggest Spec Update Moves Security Enforcement to Your Endpoints, Not the Protocol

The Model Context Protocol shipped its biggest revision since launch on July 28. All four Tier 1 SDKs supported the new version within a day, Cloudflare's Agents SDK had it live from day zero, and customers like Sentry and Linear picked it up immediately. A new 12-month deprecation policy keeps the old behavior around through at least mid-2027, but make no mistake: the surface this piece describes is already running in production.

Most of the coverage so far has celebrated the wins. A stateless core that scales on ordinary HTTP. OAuth-native authorization. Server-rendered UIs through MCP Apps. All solid engineering. I've spent the last two years building agent systems that connect to enterprise tools through MCP, and the framing I keep coming back to isn't "scaling upgrade." It's a redistribution of security obligations, and it lands squarely on you.

The scale here isn't trivial. MCP's Tier 1 SDKs clear close to half a billion downloads a month, with the TypeScript and Python SDKs each past a billion downloads total. A Censys scan in late April found 12,520 MCP services exposed to the public internet, a protocol that requires no authentication by default. OX Security found 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 flatly outpaced the protocol's security model.

That's the backdrop. The July 28 spec doesn't fix any of it. It changes why those risks compound. The session used to be the unit of control. Now every request stands alone, state moves into portable handles, and MCP Apps hand UI rendering off to the AI client. Same failure modes as before, but a different control plane sitting underneath them.

What Actually Changed in the Spec

For platform teams this reads like a scaling exercise. It's also a pivot in where security lives. Break it down piece by piece:

• Stateless core. The Mcp-Session-Id header and the initialize/initialized handshake are gone. Protocol version, client info, and capabilities now travel inline with every request, so any server instance can handle any call. Great for round-robin load balancing and autoscaling. It also means enforcement has to happen at every single request, not just at session start.
• Portable state handles. State passes explicitly between tool calls now. That sounds clean until you realize a handle is just a string sitting in the conversation. Anyone who can plant or read that string, say through a prompt-injection payload buried in a Jira ticket, walks away with a valid credential without ever touching the server.
• MCP Apps. Servers can now ship interactive HTML that the client renders in a sandboxed iframe. That's a classic web vulnerability, stored XSS, newly imported into the AI stack. An attacker stores malicious HTML or JavaScript through a tool call, and it executes the moment someone views it. The sandbox limits full takeover, but the client sits above your source code, terminals, filesystems, and every other connected MCP server.
• OAuth-native authorization. Standard identity flows are good news, but only if tokens are audience-bound. A token minted for one server must never replay against another.
• Tasks extension. Long-running async work needs scope enforcement now bound to identity rather than connection, since there's no session to anchor it to anymore.

Backslash and Akamai have both mapped where this opens new attack surface, and Microsoft's tool-poisoning research shows why it matters more once agents move from reading data to acting on it. Three vectors stand out, and all three live on the endpoint: stored XSS through MCP Apps, handle hijacking via prompt injection, and enforcement gaps that sit past where your network visibility ends. None of these show up in a packet capture.

Key Takeaways

If you're running MCP servers in production, here's the order I'd tackle this in, ranked by risk rather than convenience.

Start with MCP Apps exposure. Find every server your teams use that can render HTML into a client or IDE, and put a review policy around that HTML the same way you'd review a third-party script headed to production. You can't govern what you haven't inventoried.

Push enforcement down to the request level. If your MCP gateway was making decisions based on session state, that design is now broken. It needs to inspect and enforce on every call: OAuth 2.1 with PKCE, per-client consent, strict redirect-URI matching, audience-bound tokens. Put an identity-aware gateway in front of every server and reject anything without a valid token bound to that specific audience.

Treat handles as untrusted input. Validate that whoever presents a handle is actually who it was issued to. Build conversation-layer hygiene that flags or strips instruction-like content out of tool outputs and retrieved documents, since that's exactly where planted handles show up.

Instrument the endpoint separately. A gateway enforces the request but has no visibility into MCP Apps rendering, local server behavior, or what's happening inside the IDE. That's a different tool entirely. If your security stack is purely network-based, this is precisely the blind spot the new spec creates.

Test against real workflows, not unit tests. A migrated spec will pass unit tests cleanly and still fail in a live agent loop. Run it against real models doing real work, and watch for state leaking across server instances, handles reused outside their intended scope, and UI content you didn't expect.

Plan for the deprecations now. Roots, sampling, logging, and the legacy HTTP+SSE transport are all deprecated, which forces migration work for most platform teams. The 12-month clock started July 28, so removal comes no earlier than mid-2027. That sounds like a long runway. It never feels that way once you're inside it.

The MCP maintainers made a deliberate call here: the protocol won't enforce security for you. That's defensible, a stateless protocol on commodity infrastructure is the right architectural choice for enterprise-scale agents. But "the protocol doesn't enforce security" translates directly into "you do," at the endpoint, on every request, every handle, every rendered UI.

Teams that treat this purely as a migration will ship the new spec with their old, stateful-protocol security posture intact, and that posture won't match the threat surface they're actually running. Teams that treat it as a security transition, moving enforcement to the request level, instrumenting the endpoint, governing MCP Apps before they spread, are the ones whose agent deployments will still be standing after a real attacker shows up.