The KV Cache is the Conversation

Most security reviews of an inference platform stop at the prompt and the response. Those are the things that look like data. The KV cache tends to be waved through as an implementation detail: a performance structure, like a page cache, not something that carries meaning.

That is wrong, and it matters for anyone who has signed a zero-data-retention clause.

What is the KV cache? When a model reads your prompt, every token it attends to produces a key and a value vector at every layer. Those vectors are the model’s working memory of the conversation so far: they are what lets token 900,000 attend to token 12. Together they are the KV cache. It is not the model weights, which are fixed and shared across every request; it is per-session state. It grows linearly with context length, and at long context it dwarfs the weights. Throw it away and the only way to get it back is to run the entire prompt through the model again.

The Cache is the Prompt, in a Different Coordinate System

Here is the property that security reviews miss: the KV cache is a lossy but invertible encoding of the text that produced it.

Lossy, because it is a projection: real numbers in a learned space, not characters. Invertible, because the projection retains more than enough structure to recover the input. The cache has to encode what the tokens were and where they sat, because that is precisely what attention needs from it. Information that would let you reconstruct the prompt is not incidental to the cache; it is its entire function.

Not a summary of it. Not statistics about it. The dialogue, recoverable.

Once that lands, the question “where does the KV cache live, and who can read it?” stops being a performance question and becomes the same class of question as “where is the plaintext?”

Two Public Attacks: Read It, and Write It

This is not hypothetical. Two published lines of work demonstrate both halves of the threat.

Reading it: Token Traphouse. Given a dump of KV cache memory, it recovers the exact tokens that produced that cache. Not an approximation, not a topic model: the tokens. This is the empirical answer to anyone arguing the cache is “just vectors.” The vectors are the prompt, and the inversion is a published, reproducible procedure.

The consequence is that every place the cache is at rest in plaintext is a place the conversation is at rest in plaintext. GPU memory. DRAM bounce buffers. Anything that got spilled to local NVMe. Anything that crossed a wire unencrypted. If your data-handling policy has a list of the places customer content may reside, the cache has almost certainly expanded that list without anyone updating the document.

Writing it: Shadow in the Cache. The write-side attack is worse, because it is silent. If an attacker can modify cached blocks, they can poison the model’s past, inserting content into the history that every subsequent turn attends to as though the user had said it.

Think about what that defeats. Prompt-injection defenses inspect the incoming prompt. It doesn’t arrive in the prompt. It arrives in the model’s memory of a conversation that already happened, and from the model’s perspective, nothing distinguishes a poisoned block from a legitimate one, because a KV block carries no provenance. It is numbers at an offset. Every turn afterward is conditioned on an injection that was never typed and appears in no request log.

Read and write. Confidentiality and integrity. Both demonstrated, against a structure most threat models do not list as an asset.

The gap: attestation stops at boot, the cache lives after it

The natural response is “we have confidential computing / measured boot / a TPM.” Those are real controls and they help. They also do not cover this, and the reason is a timing mismatch.

Measured boot attests the platform as it came up: firmware, bootloader, kernel, and, in some configurations, the initial workload. It produces evidence that the machine started in a known state. That evidence is generated once, before any inference has occurred.

The KV cache does not exist yet at that point. It is created per session, lives in DRAM and on NVMe and on the fabric for the duration, and is read and written continuously, all of it after the last measurement was taken. Nothing in a boot-time attestation says anything about what happened to a cache block written forty minutes into the machine’s uptime.

So there is a structural gap:

• Attested: the platform state at boot.
• Not attested: whether the cache was encrypted at rest; whether it outlived the turn; whether it was written to shared storage; which firmware could read it; whether a block came back unmodified.

Today, a tenant has no way to check any item on the second list. They have a contract clause and an annual audit. That is a legal control over a technical property, which means the remedy arrives long after the disclosure, if it is ever detected at all.

Where This Goes

Two directions, and they are the subject of other posts.

Make the cache ciphertext everywhere except inside the GPU. If blocks are encrypted at rest, in DRAM, and before the DMA on the wire, then compromising the storage vendor, the operator, the BMC, or a NIC yields ciphertext. The read attack needs plaintext to invert. Post 13 covers the encryption boundary in detail: where exactly the line is drawn and what enforces it.

Make retention a claim the tenant can verify per turn, not a clause they hope holds. Encryption policy, block integrity, and platform state are checked before the request proceeds, with signed evidence, and a client that refuses to send the prompt to a provider that cannot attest. Post 8 covers what that would look like as a real control.

Both are the same underlying move: treat the KV cache as what it is (customer content, at rest, in the blast radius) and apply the controls you would already apply to anything else in that category.

Three Questions Worth Asking Your Provider

You do not need any of the above to make progress this week. Ask your inference provider three questions and see how quickly they can answer:

1. Where does the KV cache for my sessions reside, in every tier, and for how long after the turn ends?
2. Is it encrypted at rest and on the wire, and who holds the keys?
3. What evidence can you give me per request that the answers to (1) and (2) held for that request?

The third is the one that separates a posture from a control. Most providers can answer the first two with a policy document. Almost nobody can currently answer the third, which is a gap worth naming now, while architectures are still being chosen.

To learn more about this topic, read the blog: Zero Data Retention as a provable SLA