The cache knows your token, not your session

FastMCP’s `ResponseCachingMiddleware` caches handler results and partitions them by the caller’s access token, so one user’s filtered view never reaches another user. Session state is a different boundary: `Context.set_state` and `get_state` are keyed by MCP session. Issue #5574 shows that the cache ignores it. In the reporter’s example, session A stores “A-secret” and recalls it, which caches the result. Session B then stores its own “B-secret”, makes the same recall call, and gets “A-secret” back. The same applies to `resources/read` and `prompts/get` handlers that read session state. Sessions that share a token share the cache, and unauthenticated callers (including STDIO) all fall into one anonymous partition.

The repro is the reporter’s own, and the issue is labelled bug, high-priority and security. A fix, PR #5576, adds the session id to the cache keys for those three calls. At the time of writing it is still open and unmerged, waiting for a maintainer to be assigned. We checked the code: FastMCP 4.1.1, released on 18 October, still builds the key from the token alone.

If a tool’s answer depends on session state, keep it out of the response cache — list those tools in the middleware’s `excluded_tools`, turn off caching for resource reads and prompt gets that read state, or skip the middleware — until the fix ships in a release.