Split-LLM privacy checks pass even as the gradient leaks which rows are real

Split-LLM privacy checks pass even as the gradient leaks which rows are real

The paper studies a common split-LLM training setup: a Trusted Local Node (TLN) holds the private data and loss, and sends protected activations to an Untrusted Cloud Node (UCN), which runs the forward pass and returns its output. TLN then computes the gradient of its private loss and sends that gradient back to UCN so training can proceed. To test whether this arrangement is private, the researchers mixed real data rows into each batch alongside decoy rows, with the loss set up to ignore the decoys entirely. That design choice backfires: because the loss ignores the decoys, their gradient comes back as exactly zero, so the pattern of zero versus nonzero gradients tells UCN which rows in the batch were real.

The measurement protocol was fixed before the runs: a leak of known strength was injected first to confirm the detection method actually works, a shuffled-label control was run to confirm it does not report leaks that are not there, and the pass/fail threshold was set in advance. Across nine random seeds, the zero-gradient pattern identified the real rows on every single frame, 4,096 of 4,096 per run, with no misses. A separate attack that examined the contents of the frames rather than just the zero pattern recovered about one extra token per hundred over a constant-guess baseline, a gain of 0.65 to 1.50 percentage points; the shuffled-label control recovered nothing, which is what confirms the signal is a real leak rather than noise.

The same test was then repeated on a second configuration chosen to keep the model's output quality within a normal operating budget, so the leak is not confined to a degenerate setup nobody would actually deploy. On both configurations, every run passed the existing forward-channel privacy check and the model-quality check, yet failed as soon as the returned gradient was included in the evaluation, meaning the standard privacy sign-off for this kind of system had simply never looked at that channel.

The researchers show one fix: clipping and adding noise to each row of the gradient before it goes back to UCN closed this particular leak, at a cost of about 0.01 nats of held-out cross-entropy, a small hit to model quality. They are explicit that this does not make the system safe overall: five classes of attack, including ones that accumulate observations across many training steps, were never measured in this study.

Key facts

  • In this split-LLM setup, the Trusted Local Node (TLN) sends activations to the Untrusted Cloud Node (UCN), gets its output back, and returns the gradient of its own private loss, and that gradient is the untested leak.
  • Because the loss is set to ignore decoy rows, their returned gradient is exactly zero, letting the untrusted node tell real rows from decoys just by which gradients are nonzero.
  • Across nine seeds, this zero-gradient signal identified the real rows on every frame: 4,096 of 4,096 rows per run.
  • A second attack reading the frame contents added about one extra token per hundred over a constant-guess baseline (+0.65 to +1.50 percentage points), while a shuffled-label control recovered nothing, confirming the leak is genuine.
  • Clipping and noising each gradient row closed the leak for about 0.01 nats of held-out cross-entropy, but the authors say five classes of attack, including ones that accumulate signal across training steps, were never tested.

Why it matters

Privacy evaluations for split training typically check two things: what the untrusted node receives on the forward pass, and whether the trained model's output quality holds up. This case study shows a channel that exists in every such system by construction: the gradient the trusted node sends back can leak which rows in a batch were real rather than decoy, even when both of the usual checks pass cleanly. That means a system can carry a clean privacy sign-off today and still be leaking exactly the information the sign-off was meant to protect.

Who it affects

Anyone building or evaluating split-LLM or split-learning training pipelines that divide the work between a trusted party holding the data and loss and an untrusted cloud node doing the heavy computation, a common pattern when compute is rented or shared. It also affects whoever writes the privacy benchmarks and pass/fail checks for such pipelines, since the existing check in this study missed the gradient leak entirely despite the system passing it.

How to use it

The paper points to a concrete mitigation: clip and add noise to each row of the gradient before returning it to the untrusted node. That closed the specific leak measured here at a modest cost, about 0.01 nats of held-out cross-entropy. Teams running split-LLM training should extend their privacy checks to cover the returned gradient itself, not only the forward-pass activations and the final output quality.

How solid is it

The method is set up to be hard to fool: a leak of known strength was injected in advance to prove the detector can find one, a shuffled-label control was run to prove it does not report leaks that are not there, and the threshold was fixed before any run. The result held across nine seeds with a perfect 4,096-of-4,096 identification rate per run, and was reproduced on a second, quality-constrained configuration, so it does not look like an artifact of one narrow setup.

Risks and caveats

Closing this one leak does not make the system safe. The authors state plainly that five classes of attack, including ones that accumulate observations across many training steps, were never measured in this study. The frame-content attack's own advantage over the baseline is modest, about one extra token per hundred, so the larger risk the study surfaces is qualitative: a split-training system can pass its stated privacy and quality checks while a real channel goes untested.