Source-linked AI summary
Auditing Prompt Caching in Language Model APIs
Chenchen Gu, Xiang Lisa Li, Rohith Kuditipudi, Percy Liang, Tatsunori Hashimoto
TL;DR
Prompt caching creates timing differences that may expose users’ prompts when caches are shared, motivating transparent policy audits. The paper develops statistical tests for caching and sharing scope, finding global sharing across seven providers and architectural evidence about OpenAI’s embedding model. Practical prompt extraction remains unsuccessful because exact-prefix attacks require extremely accurate token detection and repeated measurements can contaminate the cache.
Problem
Prompt caching creates data-dependent timing differences that can enable side-channel inference of other users’ prompts when caches are shared.
Method
The paper audits APIs by comparing timing distributions from cache-hit and cache-miss procedures using statistical hypothesis testing.
Results
The audits detected caching in 8 of 17 providers and global cache sharing in 7, while prefix-cache timing indicated that OpenAI’s text-embedding-3-small is decoder-only.
Takeaways & Limitations
Global cache sharing across multiple APIs can leak privacy and proprietary information through timing differences.
Takeaways & Limitations
Practical prompt extraction was not achieved because one incorrect token breaks exact prefix matching, while attacker measurements can themselves create cache hits.
Abstract
from arXiv · showhide
Prompt caching in large language models (LLMs) results in data-dependent timing variations: cached prompts are processed faster than non-cached prompts. These timing differences introduce the risk of side-channel timing attacks. For example, if the cache is shared across users, an attacker could identify cached prompts from fast API response times to learn information about other users' prompts. Because prompt caching may cause privacy leakage, transparency around the caching policies of API providers is important. To this end, we develop and conduct statistical audits to detect prompt caching in real-world LLM API providers. We detect global cache sharing across users in seven API providers, including OpenAI, resulting in potential privacy leakage about users' prompts. Timing variations due to prompt caching can also result in leakage of information about model architecture. Namely, we find evidence that OpenAI's embedding model is a decoder-only Transformer, which was previously not publicly known.
1. Introduction
Prompt caching speeds requests sharing cached prefixes, creating timing side channels that can expose other users’ prompts and model architecture. The paper audits real-world APIs statistically, finding widespread global sharing and evidence that OpenAI’s text-embedding-3-small is decoder-only.
- Cached prompts are processed faster than non-cached prompts, so attackers can identify likely cache hits from API response times.If caches are shared across users, a cached prompt implies that another user recently sent that prompt or a shared prefix.
- Providers’ caching policies matter because announcements may omit whether sharing is per-user, per-organization, or global.The audit addresses this transparency gap with statistical hypothesis tests that provide valid p-values and false-positive guarantees.
- 8 of 17 API providers cached prompts, and 7 exhibited global cache sharing, enabling potential inference of other users’ prompts from timing differences.The audits were conducted in September and October 2024.
- Prefix-cache timing reveals architecture because differing suffixes can share a cache only in autoregressive decoder-only Transformers.The authors find evidence that OpenAI’s text-embedding-3-small is decoder-only, which was previously not publicly known.
- After disclosure, at least five providers made changes such as disabling global cache sharing across organizations or updating documentation.The authors disclosed results in October 2024 and allowed providers at least 60 days before public release.
2. Preliminaries and Assumptions
Prompt caching reuses attention KV caches for matching prefixes, reducing time to first token, while cache-sharing scope determines the potential privacy leakage. The preliminaries define the timing model, assumptions, and per-user, per-organization, and global sharing levels.
- 2.1. Prompt Caching: Prompt caching stores attention KV caches and reuses them for matching prefixes, making cache hits faster in time to first token.In decoder-only Transformers, matching-prefix reuse preserves model behavior even when suffixes differ.
- 2.1. Prompt Caching: The audit assumes cache hits follow prefix matches and have faster TTFT than cache misses after accounting for prompt length.A sufficiently long prefix shared with a cached prompt can produce a cache hit.
- 2.2. Timing and Cache Assumptions: The setup allows arbitrary prompts and TTFT measurement through one-token outputs, using either client-side or server-side timing.APIs may use multiple servers with separate caches and may route requests randomly or intentionally.
- 2.3. Levels of Cache Sharing and Privacy Leakage: Per-user caching creates no privacy leakage from other users, whereas per-organization caching carries limited intra-organization risk.Organization owners can mitigate the latter by controlling membership.
- 2.3. Levels of Cache Sharing and Privacy Leakage: Global caching shares prompts across all API users and therefore creates the highest potential privacy risk, including across organizations.An attacker could potentially learn information about any other user’s prompts.
3. An Audit to Detect Prompt Caching
The audit compares timing distributions from procedures designed to produce cache hits and misses, testing whether they differ under each cache-sharing level. It combines hypothesis testing with controlled random prompts, prefix matches, and KS statistics.
- 3.1. Audit Formulation: Statistical Hypothesis Testing: The audit tests whether an API caches prompts at a specified sharing level, with H0 of no caching and H1 of caching.The null hypothesis permits no stored information from a victim prompt to affect a future attacker timing measurement.
- 3.1. Audit Formulation: Statistical Hypothesis Testing: The hit procedure has one user cache a prompt and another send a prefix-sharing prompt, while the miss procedure sends a random prompt.The users are chosen as far apart as possible within the tested sharing level.
- 3.1. Audit Formulation: Statistical Hypothesis Testing: Under no caching, hit and miss TTFT distributions are identical; under caching, hit times are expected to be faster and distributions differ.The audit therefore tests whether Dhit = Dmiss versus Dhit ≠ Dmiss.
- 3.2. Audit Implementation Details: The implementation varies PROMPTLENGTH, PREFIXFRACTION, NUMVICTIMREQUESTS, and NUMSAMPLES to control prompt construction and sampling.The prompt distribution uses random upper- and lowercase English letters separated by spaces, producing fixed-length token sequences for common BPE tokenizers.
- 3.2. Audit Implementation Details: Random prompts make accidental cache-prefix matches negligible, with probability below 10^-25 for shared prefixes of at least 15 tokens.This makes the random-prompt procedure an accurate measure of cache-miss times.
- 3.2. Audit Implementation Details: The hit implementation caches a prompt NUMVICTIMREQUESTS times, then tests a prompt sharing PREFIXFRACTION × PROMPTLENGTH tokens; PREFIXFRACTION = 1 tests exact matches.Values below 1 test matching prefixes with different suffixes.
- 3.2. Audit Implementation Details: The statistical test collects randomized timing samples and applies a one-sided two-sample KS test for faster cache-hit times.The KS statistic is the maximum difference between empirical cumulative distribution functions.
4. Auditing Real-World APIs
The audit tests real-world APIs for prompt caching and cache-sharing scope using statistical comparisons of cache-hit and cache-miss timings. Across 17 providers, caching and global sharing were detected broadly enough to create potential timing-based privacy leakage, while audit sensitivity depended on prompt configuration.
- 4.1. Audit Setup and Configuration: The audit compares response-time distributions from procedures attempting cache hits and cache misses, testing whether they differ statistically.The procedure varies user identity and matching-prefix conditions to test increasingly broad cache-sharing levels.
- 4.2. Audit Results: The audit reports average precision for distinguishing cache-hit times at the highest detected sharing level, separately for client-side and server-side timing.Selected precision-recall curves show near-perfect precision up to moderate recall, while Table 2 records APIs where caching was not detected.
- 4.2. Audit Results: 8 of 17 API providers showed prompt caching, including 7 with global cache sharing that could expose whether another user sent a prefix-sharing prompt.The audit used real-world providers and assessed per-user, per-organization, and global sharing.
- 4.2. Audit Results: Cache-hit and cache-miss timing distributions were clearly distinguishable, with cache hits tending to be faster, and all available timing methods were significant where caching was detected.Most detected APIs needed only one victim request; OpenAI and Azure text-embedding-3-small required 25, possibly because requests were distributed across separate server caches.
- 4.2. Audit Results: The audit found documented per-organization sharing for Anthropic Claude 3 Haiku and OpenAI GPT-4o mini, while global sharing in OpenAI text-embedding-3-small was patched after disclosure.The documented per-organization behavior was not treated as a security vulnerability.
- 4.3. Ablations: Average precision decreases toward random chance when prompt length or matching-prefix fraction becomes small, while model size shows no clear relationship with average precision.These ablations indicate that detection depends more strongly on prompt and prefix length than on model size.
5. Leakage of Architecture Information
Prompt-prefix caching can reveal whether a model uses a decoder-only Transformer, because only such models support cache hits when prefixes match but suffixes differ. Audits of OpenAI’s text-embedding-3-small provide evidence of this architecture and expose small embedding differences during cache hits.
- Architecture evidence: Prefix caching across differing suffixes is possible in decoder-only Transformers because each token attends only to preceding tokens, unlike encoder or encoder-decoder architectures.Thus, detecting this behavior rules out a bidirectional encoder architecture.
- Ablations: Figure 5 shows that decreasing prompt length or matching-prefix length reduces average precision to random chance, while caching remains detectable across model sizes without a clear size relationship.The ablations use PROMPTLENGTH, PREFIXFRACTION, and model size as factors affecting average precision.
- Why architecture leakage matters: Embedding models may use either encoder or decoder architectures, making architecture leakage potentially equivalent to leakage of proprietary intellectual property.
- Architecture evidence: OpenAI’s text-embedding-3-small caches prompts with identical prefixes but different suffixes, indicating a decoder-only Transformer architecture under the Transformer-based assumption.The returned embedding changes when the suffix changes, so caching does not simply return a cached embedding output; OpenAI had not previously disclosed the embedding model’s architecture.
- Embedding behavior: Repeated cache-hit embeddings differ slightly from normal embeddings by approximately 10^-4 to 10^-5 in each coordinate.This behavior occurs across different random prompts and is consistent with limited floating-point precision in the cache.
6. Mitigations
The paper recommends per-user caching to prevent cross-user privacy leakage and disclosure of cache-sharing policies so users can understand how their data is handled. Disabling caching is the strongest mitigation for architecture leakage, while providers may choose their risk tolerance for intellectual-property exposure.
- Privacy mitigation: Per-user caching prevents attackers from producing cache hits on prompts sent by other users while retaining many performance benefits because long matching prefixes across users are unlikely.
- Transparency: Providers should disclose their cache-sharing policies so users can understand who could learn information about their data and make informed API-use decisions.Organizations could use separate organizations for different employee groups when cache sharing is per-organization.
- Architecture mitigation: Disabling prompt caching is the strongest mitigation for architecture leakage, whereas per-user caching avoids privacy leakage but may still expose provider intellectual property.The appropriate level of risk is left to the provider.
7. Related Work
Prior work studies prompt-caching timing attacks, caching-based inference optimizations, and other language-model API leakages. This paper differs by auditing real APIs with statistical guarantees, identifying cache-sharing levels, and extracting architecture information.
- Prompt caching: Prompt-caching research develops KV-cache reuse methods to improve latency and throughput for shared prompt prefixes, while this paper does not assume a particular caching implementation.The audited APIs’ technical caching mechanisms are not known.
- Prompt caching: Other caching approaches retrieve responses for semantically similar prompts or reuse KV caches without exact prefix matches, but this paper does not study them.The audit could be adapted to detect these methods, which may also be vulnerable to timing attacks.
- Cache timing attacks: Computer-security research has used cache timing differences to extract secrets and private web information from cache hits and misses.
- Attacks on language model APIs: Prior language-model API attacks exploit logits, logprobs, packet sizes, and speculative decoding to recover model or response information.
- Positioning: Compared with Song et al. (2024) and Zheng et al. (2024b), this work provides practical statistical audits of real APIs, identifies cache-sharing levels, and extracts architecture information.
8. Conclusion
The paper finds that prompt caching in LLM APIs can leak private and proprietary information through timing differences. Its statistical audits of real-world APIs detect global cache sharing, motivating continued security and privacy evaluation of deployed machine-learning systems.
- Prompt caching in LLM APIs can leak private and proprietary information through timing differences.
- Rigorous statistical audits of real-world APIs found that multiple APIs were performing global cache sharing.
- The findings motivate continued security and privacy audits of deployed machine-learning systems to support robustness and trustworthiness.
Impact Statement
The authors disclosed detected prompt-caching results to providers before public release, and report that providers implemented mitigations. They frame auditing and transparency as ways to improve trust and informed decisions about LLM API data handling.
- At least five providers made changes after responsible disclosure, including disabling global cache sharing across organizations and updating documentation.The authors gave providers 60 days to address vulnerabilities, although the actual interval was longer.
- The audits are intended to improve transparency about caching policies and user-data handling, helping users make more informed decisions about LLM APIs.
Conflicts of Interest
The paper discloses that one author is a Together AI co-founder, while stating that the work was conducted independently in his Stanford capacity. The authors report that all providers, including Together, were audited using the same procedure and that the other authors had no provider conflicts.
- One author is a co-founder of Together AI, but the work was conducted in his Stanford capacity and its methods, audited providers, and results were not shared with Together before release.
- Together AI was audited using the same procedure as all other providers.
- The other authors had no conflicts of interest with the audited providers when the work was conducted.
C. Ablation Effects on Audit p-values
Ablation results show that audit evidence weakens as prompt or prefix-match lengths decrease, while caching remains detectable across model sizes without a clear size–p-value relationship.
- Caching was detected across all model sizes, with no clear relationship between model size and audit p-values.Each ablation test used NUMSAMPLES = 250.
- As prompt length or prefix-match length decreases, audit p-values grow larger.The reported pattern is consistent with decreases in average precision corresponding to increases in p-values.
D. Embeddings and Response Times from the OpenAI text-embedding-3-small API
Repeated requests to OpenAI’s text-embedding-3-small show response-time and embedding patterns associated with cache misses, cache hits, and alternate outputs. Across the broader audit analysis, cache-hit timing can be distinguished with near-perfect precision at moderate recall, while ablations show weaker evidence for shorter prompts or prefixes.
- Most normal-time responses return the same “normal” embedding, while noticeably faster responses return a slightly different embedding associated with cache hits.Most, but not always all, fast responses share the same cache-hit embedding.
- Some responses, especially noticeably slower ones, return alternate embeddings that differ from both the normal and cache-hit embeddings.Several different alternate embeddings appear across the repeated requests.
- Cache hits can be detected with near perfect precision up to moderate recall scores in APIs where the audits detected caching.The cache-hit procedure attempts, but cannot guarantee, cache hits, so some apparent cache-hit samples may actually be misses and reduce recall.
- Tables 3–6 report p-values for same-prompt, same-prefix, per-organization, and global-cache-sharing audit levels.
- Audit p-values grow as prompt length or prefix-match length decreases, while caching is detected across all model sizes without a clear model-size relationship.The ablation tests use NUMSAMPLES = 250.