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 user_id (or a user-scoped session token) to the cache key, so that Cache(system_prompt_hash + user_id) is the lookup key rather than just Cache(system_prompt_hash). This ensures User B's request — even with an identical system prompt — produces a different cache key than User A's request. Option A (disable caching) eliminates the vulnerability but at complete cost of the caching benefit — it's a remediation, not a fix. Option C (request signing) is architecturally overkill and doesn't match the threat model — 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. Option D 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.