MCP Protocol Rewrite — Session IDs Removed, Security Decisions Shifted to Developers
AI relevance: MCP is the dominant protocol connecting AI agents to external tools. The rewrite removes a known session hijacking risk but creates new attack surfaces by leaving authentication and authorization implementation to individual server developers.
What Changed
- MCP maintainers David Soria Parra and Den Delimarsky published the biggest protocol rewrite since launch, removing the session tracking feature that defined how AI agents authenticate to external tools.
- The old system used session IDs — a server-issued code the agent had to present on every message. If an attacker intercepted or guessed the session ID, they could impersonate the legitimate user.
- The new system removes server-issued session IDs entirely. Any server can handle any request without needing to remember who sent the last one. This closes the session hijacking risk.
- Instead, the server creates a tracking token (like an order number) that the AI agent carries forward in the conversation. The token is in plaintext, visible in the chat context.
- Security researcher Maya Pik (Backslash) noted that a malicious tool can trick the AI agent into picking up a tracking number it was never supposed to use, and the agent will comply because nothing in the system tells it not to.
- The spec requires servers to verify that tracking numbers haven't been tampered with, but does not specify how — leaving implementation details to individual server developers.
- Akamai's Maxim Zavodchik summarized: "Companies gain new features, but they lose a security check the protocol used to handle for them and now have to build it themselves."
Why It Matters
This is a classic security architecture trade-off. The old session ID system had a known vulnerability (session hijacking). The new system eliminates that specific risk but shifts the burden of implementing secure authentication, authorization, and token validation to thousands of individual MCP server developers — many of whom are not security specialists. Expect a wave of misconfigured servers and new CVEs as the ecosystem adjusts.
What To Do
- MCP server operators: Review the new spec carefully. Implement token validation with cryptographic signatures or server-side state — do not trust client-provided tracking numbers for authorization decisions.
- Security teams: Inventory all MCP servers in your environment. Verify each has been updated to handle the new token model securely. Test for token tampering and confused deputy attacks.
- Developers: Do not assume the protocol handles authentication for you. The spec explicitly leaves this to you. Implement proper token validation, scope checks, and audit logging.
- Follow the discussion: The spec is still evolving. Watch for updates and community guidance on secure implementation patterns.