The 2026-07-28 MCP spec deleted sessions. With it went principal binding - the one guarantee your state keys, rate limiters, and redaction rules were quietly leaning on. Your server did not change. Its threat model did.
When the protocol removed sessions, it stopped answering one critical question: ๐๐ ๐กโ๐๐ ๐ ๐๐๐๐ข๐๐ ๐ก๐ ๐๐๐๐๐๐ ๐ก๐ ๐กโ๐ ๐ ๐๐๐ ๐๐ข๐กโ๐๐๐ก๐๐๐๐ก๐๐ ๐๐๐ก๐๐? That question - principal binding - was load-bearing underneath four separate security controls in a typical server.
State lookup keyed on caller-supplied identifiers. Rate limiters counted per conversation. Response filters decided once who was asking. Authorization checked scopes at connection start, not per request. None of these controls announced their dependency on session-level guarantees. On 2026-07-28, those guarantees evaporated.
The result: controls keep returning plausible answers computed from nothing. Nothing broke loudly because nothing wired security to the absence of a protocol feature. A control that depends on a withdrawn guarantee does not fail - it fails silently.
Two vulnerabilities emerge here. First, ๐๐๐๐๐ ๐๐๐๐ ๐๐ ๐๐๐๐๐๐๐๐๐ - your Redis keys built from caller-supplied conversation IDs are now reachable by anyone who can guess or observe another caller's identifier. Second, ๐๐๐๐๐ ๐๐๐ ๐๐๐๐๐ ๐๐๐๐๐ ๐๐๐๐๐ - the spec required it since 2025-06-18, and most servers are not doing it. Add a third: ๐๐๐๐๐๐๐บ๐๐๐๐๐ ๐๐๐ ๐๐๐๐๐๐ ๐๐๐๐๐ that leak sensitive data through response field filtering.
Read the full article for the corrected state manager, token validation patterns, and how to prevent data exfiltration through response filtering.
https://ranjankumar.in/designing-secure-mcp-servers-preventing-context-injection-n-data-exfiltration
Follow for practitioner-focused AI systems security.
MCPSecurity #AIEngineering #ModelContextProtocol #PrincipalBinding #TokenValidation #SecureAI #DataExfiltration
Top comments (0)