MCP went stateless — security moved to your endpoint

In July we argued you should build your agent integrations on MCP because the standard was stabilizing. We stand by that. But a VentureBeat analysis published September 7 makes the bill explicit, and it is worth paying attention to: going stateless did not remove the security work. It moved it onto you. MCP stateless security is now an endpoint problem, checked on every request.

What actually happened

The 2026-07-28 spec removed the initialize handshake and the Mcp-Session-Id header. That was the point — stateless servers run behind ordinary load balancers instead of sticky-session infrastructure. What went with it was a session layer that had been doing unglamorous work: holding an authenticated context, giving you something to attach policy to, and giving your network tooling something to look at.

Three consequences, per the VentureBeat reporting:

State handles are strings. When a tool genuinely needs state, it now returns an explicit handle the model passes back as an argument. A handle sitting in a conversation is readable and writable by anything that can influence that conversation. A prompt injected through a tool response or a fetched document can lift one — and using it requires no interaction with the server that issued it.

MCP Apps render HTML. The extension lets servers ship interactive UI into sandboxed iframes inside your AI client. Stored XSS in that surface executes next to a process that has your source tree, your terminal, and every other connected server.

Nothing on the wire looks wrong. The enforcement moved from the session layer to the application layer, which means network monitoring cannot see the failure mode.

The exposure numbers are not theoretical. Censys found 12,520 internet-reachable MCP services across 8,758 IPs in an April 28 scan, most unauthenticated — and MCP does not require auth by default.

Why it matters for your business

If you are a small operator who wired an AI assistant into your inventory, your CRM, or your calendar, you probably did not write an MCP server. Someone did it for you, or you installed one. That server is now the enforcement point, and "the protocol handles it" was never true and is now not even approximately true.

The questions to put to whoever built or sold you the integration:

Is every request independently authorized? OAuth 2.1 with PKCE and audience-bound tokens, validated per request — not once at connect time, because there is no connect time.

Are handles validated against the identity that issued them? A handle should be untrusted input, checked against who is presenting it. If your server accepts any well-formed handle, a planted prompt is a working credential.

Which of our servers can render HTML? Inventory them. MCP Apps is useful; it is also a code-execution surface pointed at your dev environment.

Is anything we run reachable from the internet without auth? Twelve thousand services say this is the common case, not the edge case.

Build on the standard. Just stop assuming the standard is defending you.

Sources: VentureBeat, MCP spec blog, Censys.