What Is Prompt Cache Poisoning
Prompt cache poisoning refers to the manipulation of caching layers that sit between an LLM application and the model itself, causing the cache to store or return a response that was not intended for the requesting user or context. Many production LLM systems cache prompts and responses to reduce latency and inference cost. A cache lookup can be exact-match, based on a literal hash of the input, or semantic, based on vector similarity between the incoming prompt and previously cached entries. When cache keys do not fully capture the context of a request, such as tenant identity, session state, or system prompt version, an attacker can craft input that intentionally collides with an existing cache entry or overwrites a shared entry with malicious content. A subsequent, unrelated request then receives a cached response that was generated for, or manipulated by, a different actor.
How It Differs From Prompt Injection
Standard prompt injection targets the model's live reasoning process, attempting to alter its behavior through the content of a single request. Prompt cache poisoning operates one layer below that: it targets a stored inference-layer artifact, the prompt-response pair sitting in cache, rather than the model itself. This distinction matters for detection and defense. Filters or guardrails that inspect live model output do not necessarily apply to a cached response served directly from a lookup, bypassing the generation step entirely. The scope also differs: a successful injection typically affects a single session, while a poisoned shared cache entry can affect every subsequent user or tenant whose request matches the poisoned key, until the entry is invalidated or expires.
Governance Implications and Where Runtime Governance Fits
Cached prompts and responses containing personal or sensitive data are subject to the same retention, access, and deletion obligations as other stored user data, even though caching sits in an infrastructure layer teams may not treat as a data store. In multi-tenant AI offerings, cache isolation guarantees are a legitimate subject for security and compliance disclosures, since a shared-cache leak constitutes a cross-customer data exposure. Incident response procedures should treat cache poisoning and cross-tenant leakage as a distinct scenario category from model-level prompt injection, since root cause, scope, and remediation differ. No dedicated regulatory or standards-body guidance specific to prompt cache poisoning currently exists; organizations should map controls to established AI security and data protection frameworks instead. Runtime governance approaches that enforce policy at inference time, including validation applied to both generated and cached responses, monitoring of tool and agent activity, and consistent audit logging, help close the gap left by defenses that only inspect live model generation.