The loop is mechanical. An attacker sends a prefix of candidate tokens, times the response, reads a fast answer as a prefix match and a slow one as a wrong guess, then extends one position with a local model proposing the next candidates [5]. Attention is deterministic, so a matching prefix means the server skips the computation and answers sooner [16]. Nothing privileged is involved: ordinary API calls plus a commodity local LLM for candidate generation [6].
The delta the whole attack rests on is 13 to 31 percent, measured end to end at the HTTP client, in a study of 500 agent sessions whose average system prompt ran 10,000 tokens [3][12]. Queueing, batching and network variance land in the same measurement. KV-Cloak tells you how much that matters: deliberately injecting noise into cache-hit timing raises the number of measurements an attacker needs by four, and reconstruction still succeeds [7]. Averaging beats injected noise, and it beats jitter for the same reason. A small delta is a sampling cost.
The cost side deserves the same arithmetic. A 41 percent reduction means paying 1/0.59, about 1.7 times, with caching off; an 80 percent reduction means paying 1/0.20, exactly 5 times [1]. The stated penalty for disabling caching is 2 to 5 times per session [13]. The top of that range checks out. The floor has been rounded up.
Per-user cache partitioning is the fix that most audited providers had not deployed when the ICML paper published [10], and it answers a narrower question than a SaaS team might assume. One provider API key per platform is the standard build, every customer request flows through it, and to the provider that key is a single user with a single cache namespace [9]. Partitioning by user separates your traffic from strangers, but it does not separate your tenants from each other. If your template interpolates per-tenant tool definitions or retrieval instructions into a cached prefix, the boundary is your own routing code, and tool definitions are the part that discloses the capability set and the probable credential structure [15].
The 100 percent reconstruction rate is the strongest number in this piece, and also the narrowest: it was measured against unprotected vLLM and SGLang deployments [4], which is a configuration you choose when you self-host the two dominant open-source serving frameworks [17]. Against a commercial endpoint, what arXiv:2502.07776 reports is thinner: timing analysis of OpenAI's shared cache yielded an undisclosed architectural fact about the embedding model, inferred from latency alone on the production endpoint [11]. That is cross-tenant leakage of an architectural fact inferred from latency, not a third party's system prompt read back token by token. The audit window closed in October 2024 [2], so seven of 17 is a snapshot rather than a current inventory.
The defensible position therefore splits by deployment. If you self-host vLLM or SGLang with the cache shared across tenants, treat the prefix as extractable, because that is the exact configuration reconstructed at 100 percent [4]. If you call a commercial provider, the evidence supports shared namespaces and a measurable timing signal, not demonstrated extraction of someone else's prompt. The design constraint holds either way, since any defense that keeps the latency benefit keeps the signal [8]. OWASP already lists cache timing as an indirect delivery mechanism under LLM07:2025 [14], so anything you would not hand a competitor does not belong in a prefix you want cached.
