Answer-Only Disclosure: Private-Context LLM Assistance over Web APIs with a Leakage Ledger

Liang Yuan; Xiaohu Du; Ruikun Luo; Jinze Wang; Mashud Rana; Kaibin Wang; Jiangwen Zhou; Bo Li

cs.CROct 28, 2026

Answer-Only Disclosure: Private-Context LLM Assistance over Web APIs with a Leakage Ledger

Authors: Liang Yuan, Xiaohu Du, Ruikun Luo, Jinze Wang, Mashud Rana, Kaibin Wang, Jiangwen Zhou, Bo Li,

Organizations: Australian Catholic University North Sydney, NSW, Australia · Ant Group China · University of Macau Macau, China · Swinburne University of Technology Melbourne, VIC, Australia ·

Abstract

Web assistants increasingly answer questions about a user's private documents by pairing a small on-device model with a cloud LLM behind a Web API. In collaborative decoding, the document stays on the client, and the cloud receives only a public view that the user approves, such as the question alone, but the two models exchange messages while the answer is generated. We show that the message transcript can disclose private content that neither the public view nor the answer contains. In a planted-secret audit, speculative decoding with private drafts did not include the secret code in its answers, yet sent the code to the cloud in rejected drafts. We present ADLER, a decoding protocol for streaming LLM APIs in which every message to the cloud depends only on the public view and the answer the user sees, regardless of how the client combines the two models or how the cloud behaves. A client-side leakage ledger then bounds how much the answer itself reveals relative to a public reference process built from the cloud's replies. In the audit, no ADLER configuration exposed the secret beyond the answer. On GSM8K math problems with numerical values masked in the cloud's input, ADLER with an unlimited leakage budget raises the exact-match accuracy of a 0.5B client from 0.41 to 0.83 and of a 1.5B client from 0.67 to 0.85 under lenient answer parsing, close to the 0.92 achieved by uploading the full problem. It also exceeds a zero-leakage program baseline (0.69) by 0.14 and 0.16, respectively. In this baseline, the cloud writes a program that the client runs offline using the private numbers. The ledger records the disclosure charge associated with this gain; budgets of 16 nats or less leave accuracy near the cloud-only baseline on GSM8K.

Figures & tables

Figure 1. Messages exchanged while answering a question about a private document

X

, top to bottom; the cloud’s initial input is the public view

V

. (a) Speculative decoding with private drafts leaks the secret through a rejected draft. (b) ADLER sends only prefixes of the answer, and a client-side ledger caps what the answer reveals. Two message timelines between a client and a cloud API. Left: after the question, the client sends a draft containing the account balance from a private bank statement; the cloud rejects it, and the user sees a clean answer, but the cloud has received the balance. Right: the cloud streams its own next words, and the client sends back only the answer so far when it picks a different word (Yes instead of It), so the cloud receives only a prefix of the final answer and never the balance; a ledger shows the budget spent.

Figure 2. One round of ADLER. The cloud sees only the public view

V

and prefixes of the answer; the private context

X

, local scores, weights and rejected tokens never leave the client. Two lanes separated by a dashed privacy boundary. Top: the cloud API, which sees only the public view and answer prefixes. Bottom: four client steps, public reference, local evidence, ledger and tilt, sample and check, with a stream arrow down from the cloud and a restart arrow carrying the answer prefix back up.

Figure 3. Test F1 (GSM8K: strict exact match) against mean nats spent per answer (0.5B local, 7B cloud). Both curves start at the restricted cloud; the zero-leakage post-edit and (GSM8K only) program baselines sit at 0 nats. Dashed: local-only; dotted: full upload.

	2WikiMQA / question		2WikiMQA / BM25		MuSiQue / question		MuSiQue / BM25
	Score	Nats	Score	Nats	Score	Nats	Score	Nats
Restricted cloud	0.262	–	0.343	–	0.097	–	0.218	–
Local only	0.221	–	0.221	–	0.150	–	0.150	–
Full upload	0.428	–	0.428	–	0.354	–	0.354	–
Private-draft SD	0.266	–	–	–	0.104	–	–	–
ADLER $\beta{=}4$	0.261	2.6	0.328	2.4	0.121	3.7	0.232	3.3

Table 1. Multi-hop QA test results (0.5B local, 7B cloud): F1 and mean nats spent per answer. Local-only and full upload ignore

V

and repeat across views; private-draft SD uses the question-only view. Bottom: paired differences, ∗ if the 95% interval excludes zero. Bold: ADLER best among methods keeping

X

local.

	0.5B local			1.5B local
Method	Strict	Lenient	Nats	Strict	Lenient	Nats
Restricted cloud	0.012	0.024	–	0.012	0.024	–
Local only	0.106	0.410	–	0.083	0.670	–
Post-edit	0.136	0.357	–	0.210	0.578	–
Program	0.691	0.691	–	0.691	0.691	–
ADLER $\beta{=}16$	0.012	0.024	16	0.024	0.036	16

Table 2. GSM8K with private numbers (300 test problems): strict (primary) and lenient exact match and mean nats spent per answer, for both local models. Bold: ADLER best among methods keeping

X

local.

Method	Answer	Beyond	Beyond	F1	Bound
	Asks for code		Other
Restricted cloud	0.00	0.00	0.00	0.25	$10^{-6}$
Local only	0.98	0.00	0.00	0.30	$10^{-6}$
Full upload	1.00	1.00	1.00	0.51	–
Private-draft SD	0.00	0.10	0.00	0.27	–
ADLER $\beta{=}4$	0.00	0.00	0.00	0.25	0.34

Table 3. Planted-secret audit (96 documents, 48 per question type). Answer : rate of the 6-digit code in the answer (local-only sends nothing to the cloud). Beyond : rate at which the full code reaches the cloud other than in the answer (uploaded context or drafts), an exposure indicator, not an information measure. F1: utility on the other questions. Bound: Theorem 4.4 (iii) on guessing the code (

10^{-6}

: blind guess).

Factor	Setting	Strict	Lenient	Nats	Req.	Down kB	F1	Nats
		GSM8K / masked numbers					Multi-hop QA
Control	selected	0.75	0.81	71	52	216	0.229	17.1
Score	$a=0.5$	0.07 (-0.69*)	0.08 (-0.73*)	13	61	253	–	–
Score	$a=1$	0.66 (-0.09*)	0.73 (-0.07*)	57	54	224	0.25 (+0.02)	5.2
Score	$a=3$	0.67 (-0.08*)	0.78 (-0.02)	108	56	231	–	–
Score	$a=4$	0.62 (-0.13*)	0.72 (-0.09*)	153	60	249	–	–

Table 4. One-factor ablations (0.5B local, 7B cloud, a single run). Each row changes one setting of the frozen configuration (GSM8K:

a{=}2,b{=}0

; QA:

a{=}0,b{=}\frac{3}{4}

; full reference,

c{=}50

K{=}64

L{=}8

\beta{=}\infty

). Cells: level (paired difference from the control, * if its 95% interval excludes zero); QA pools the four panels of Table 1 .

Figure 4. Ledger spend per answer for ADLER at

\beta=\infty

(0.5B local). Histograms of nats spent per answer, concentrated around 70 on GSM8K and heavy-tailed near zero on QA.

Figure 5. GSM8K ablations (0.5B local, a single run): exact match and, dotted on the right axis, mean nats spent per answer. (a) Varying the evidence weight

a

(

a=2

is the frozen choice). (b) Varying the per-answer budget

\beta

(

\beta=0

is the restricted cloud). Left: accuracy peaks at evidence weight 2 while spend keeps rising. Right: accuracy is near zero up to 32 nats, about 0.5 at 64 nats and 0.75 without a budget.

Appendix figures & tables6 assets

Supplementary material from the paper’s appendix.

Appendix

	2WikiMQA / question		2WikiMQA / BM25		MuSiQue / question		MuSiQue / BM25
	Score	Nats	Score	Nats	Score	Nats	Score	Nats
Restricted cloud	0.262	–	0.343	–	0.097	–	0.218	–
Local only	0.348	–	0.348	–	0.185	–	0.185	–
Full upload	0.428	–	0.428	–	0.354	–	0.354	–
Private-draft SD	0.259	–	–	–	0.115	–	–	–
ADLER $\beta{=}4$	0.272	2.5	0.329	2.1	0.133	3.6	0.219	2.8

Appendix

Table 5. Multi-hop QA test results with the second model pair (1.5B local, 7B cloud, three seeds): F1 and mean nats spent per answer. Local-only and full upload ignore

V

and repeat across views; private-draft SD uses the question-only view. Bottom: paired differences, ∗ if the 95% interval excludes zero. Bold: ADLER best among methods keeping

X

local.

Design	Cloud receives beyond $V$	Trips	Bound
Private-draft SD (SpecSteer, AsymSpec ( Lv et al., 2026 ; Liang et al., 2026 ) )	every draft, rejected ones too	per block	none
Logit upload ( Zhang et al., 2024 ) ; CoVeil cloud-side ( Zhang et al., 2026 )	local signals at every step	per token	none
CoVeil edge-side ( Zhang et al., 2026 )	the answer	per token	none
DP-Fusion ( Thareja et al., 2026 )	single party: the model reads $X$	–	Rényi, on the output
Post-edit (HaS ( Chen et al., 2023b ) )	nothing	one	zero leakage
Program (PAL ( Gao et al., 2023 ) )	nothing	one	zero, if run offline

Appendix

Table 6. What the cloud receives in related designs. Trips: cloud round trips per answer. Bound: formal guarantee on what the cloud learns about

X

Method	Strict	Lenient	Nats	Req.
Restricted cloud	0.012	0.024	–	59
Local only	0.106	0.410	–	–
Full upload	0.870	0.918	–	37
Private-draft SD	0.013	0.032	–	–
ADLER $\beta{=}4$	0.013	0.026	4	59
ADLER $\beta{=}16$	0.012	0.024	16	59

Appendix

Table 7. GSM8K with private numbers (0.5B local, 7B cloud, 300 test problems, three seeds). Strict: official #### parser (primary). Lenient: re-score of the same outputs. Req.: requests made by our harness, which runs every cloud call through restart streaming; a deployed cloud-only call or program needs one (Table 8 ). Bottom: paired differences; ∗ marks a 95% interval that excludes zero. Bold: ADLER best among methods keeping

X

local.

QA
		kB		Round trip (ms)
Design	Req.	Up	Down	20	100	200
Plain call, restricted	1.0	4.8	$<$ 0.1	0.02	0.10	0.20
Plain call, full upload	1.0	48.1	$<$ 0.1	0.06	0.14	0.24
One token per request ( $L{=}1$ )	10.7	54.1	5.5	0.26	1.12	2.19
ADLER ( $L{=}8$ )	3.7	17.3	15.0	0.10	0.40	0.77

Appendix

Table 8. Trace-based network cost per answer (0.5B local,

\beta=\infty

): cloud requests, upload and download kB, and communication time in seconds at three round-trip times over a 10 Mbit/s link (Appendix C ): modelled, not measured, with a compact binary encoding and sequential transfer; compute excluded. Plain calls and the program are single cloud-only API requests.

L=1

has the message pattern of edge-side fusion ( Zhang et al., 2026 ) , here with top-

K

replies.

L=16

was run on GSM8K only.

Figure 6. Validation scores of the score selection for the five declared

(a,b)

candidates and the endpoints (a single run; 50 GSM8K training problems, 50 questions each from the 2WikiMQA and MuSiQue validation splits). Red: the frozen choice. GSM8K uses the strict parser, which also explains the low local-only scores.

Figure 7. F1 gain over the restricted cloud by public view (0.5B local, 7B cloud). $*$ : the 95% question-bootstrap interval excludes zero. Heatmap of F1 differences from the restricted cloud for six fusion methods across four public views of 2WikiMQA and MuSiQue.

Privacy Leakage in Language Models

Privacy leakage in language models concerns how models expose training data, infer sensitive traits, or transmit private context through outputs and internal channels.

See all 284 papers

Stealing Reasoning Traces from Proprietary LLM APIs
Aug 10, 2026Alexander Panfilov, David Schmotz, Ilia Shumailov +5Model Extraction Attacks Adversarial Attacks
MATS Research · ELLIS Institute Tübingen · Max Planck Institute for Intelligent Systems +4
PrivDrift: Auditing User-Secret Leakage Under Topic Drift in Active LLM Conversations
Sep 24, 2026Luciano MaldonadoLLM Auditing Privacy Leakage in Language Models
West Virginia University, Morgantown, WV, USA.
InferPriv: Evaluating Inferential Privacy Leakage in LLM Assistants
Oct 25, 2026Pengrun Huang, Yiwei Fu, Luoxi Meng +1Privacy Leakage in Language Models Privacy Protection for LLM Agents
UC San Diego · University of Illinois Urbana-Champaign

Aug 10, 2026J/K move · Enter open · S save

Stealing Reasoning Traces from Proprietary LLM APIs

Alexander Panfilov, David Schmotz, Ilia Shumailov, Luca Beurer-Kellner+4

MATS Research · ELLIS Institute Tübingen · Max Planck Institute for Intelligent Systems+4

Model Extraction Attacks Adversarial Attacks Adversarial Attacks on LLMs Privacy Leakage in Language Models LLM Security Prompt Injection Attacks on LLMs

Open paper AskPDF arXiv

Leading large language model providers now conceal their models' step-by-step reasoning, or chain-of-thought, to protect intellectual property and limit information leakage. Rather than storing these traces server-side, providers return them to the client as blocks of encrypted text, which the client passes back with each subsequent request. Building on prior research, we identify an architectural vulnerability: these encrypted blocks are fully compatible and interchangeable across different sessions, users, and models within a provider's ecosystem. We exploit this compatibility to develop a scalable decryption jailbreak. By injecting an encrypted reasoning trace from a given model into a weaker, and less safeguarded model from the same provider, we force it to decode and output the trace verbatim in plaintext, without ever jailbreaking the more capable model directly. This vulnerability enables four distinct attack vectors. First, it circumvents anti-distillation mechanisms, allowing adversaries to extract a proprietary model's reasoning, as we demonstrate across Anthropic, OpenAI, and Google. Second, it allows for large-scale private data extraction. Developers frequently share session logs publicly, unaware of contents of the encrypted blocks. By decoding 315,320 reasoning blocks scraped from public repositories, we recovered 367 Personally Identifiable Information (PII) artifacts and 182 credentials. Third, it inadvertently reveals hazardous information hidden within the reasoning process, even in cases where the model's final, visible output safely rejects a malicious request. Fourth, attackers can leverage this flaw to execute invisible prompt injections, embedding malicious payloads entirely within encrypted blocks to poison public agentic rollouts. Following responsible disclosure, we propose concrete cryptographic and system-level mitigations to secure client-side reasoning.

Abstract

Privacy Leakage in Language Models

Explore similar work

Stealing Reasoning Traces from Proprietary LLM APIs

PrivDrift: Auditing User-Secret Leakage Under Topic Drift in Active LLM Conversations

InferPriv: Evaluating Inferential Privacy Leakage in LLM Assistants