A production AI system processes sensitive user financial data through Claude. Security team discovers that user data submitted in one session has appeared in Claude's responses to a different user's session during testing. The architect claims this is impossible because each API call is stateless. Upon investigation, they find that the platform's server-side prompt caching implementation stores assembled prompts (including user data) in a shared Redis cache keyed only by system prompt hash — not by user ID. This causes a cache collision where User B's request matches User A's cached prompt. What is the correct fix?

The vulnerability is a cache key collision caused by not including user identity in the key. The fix is to add a user identifier or a user-scoped session token to the cache key, so the lookup key becomes Cache(system_prompt_hash + user_id) rather than Cache(system_prompt_hash). This ensures a second user's request — even with an identical system prompt — produces a different cache key than the first user's request. The disable-caching approach eliminates the vulnerability but at the complete cost of the caching benefit; it is a remediation, not a fix. The request-signing approach is architecturally overkill and does not match the threat model, because the issue is cache key design, not request authentication. Note that Anthropic's native prompt caching caches the static prefix of prompts, not user-specific content; properly implemented, it would never cache user data in a shared manner. The switch-to-native-cache_control approach is partially correct in spirit but misrepresents Anthropic's cache_control: it caches prompt prefixes at the API level, which still requires the application to correctly separate user data from cacheable static content.