Shared AI serving leaks through the clock, and the fix is selective isolation, not total separation

The leak is in the optimisation

In a preprint, researchers describe a problem that comes with one of the most common ways to make LLM serving cheaper. Automatic prefix caching reuses work when prompts share an opening sequence, so a second request that hits the cache answers faster than one that does not. In a multi-tenant system, the authors report, that timing difference is itself information: it can reveal whether another tenant has used a similar prefix, and by extension something about that tenant's data. The point is not that sharing is careless. It is that the performance feature and the leak are the same mechanism, and a defence that ignores timing will miss it. m:…6050

The same pattern appears one layer down, in hardware. In a preprint, the authors of SparseBleed show that sparsity optimisations, which skip work on zero values to run faster, leave timing signatures that vary with the input. From a single query, they report, an attacker can infer attributes of the data being processed, without access to gradients, logits or model weights, and the attack generalises across Intel AVX2, AVX-512 and AMX instructions and NVIDIA Ampere Tensor Cores. The defence they test is padding, which masks the timing signal at a reported average cost of 7.24% in performance, while turning sparsity off entirely can cost up to twice the latency on NVIDIA Sparse Tensor Cores. Every option here is a trade, and the trade is measured in time. m:…1831

Isolation that costs too much gets switched off

The preprint on prefix caching proposes a middle path. Rather than isolating every user completely, which throws away the benefit of the cache, CacheSolidarity monitors cache reuse and isolates prefixes selectively. The authors report up to 70% higher cache reuse and 30% lower inference latency than existing user-isolation defences. Those figures are the authors' own results in a preprint, not an independent audit, but the design lesson stands on its own: a defence that preserves most of the optimisation has a better chance of staying switched on than one that makes the service slow. m:…6050

On-device deployment tells a similar story about defences that look sufficient. In a preprint, researchers examine trusted execution environments used to protect model weights on a device, and find that unilateral obfuscation, which transforms matrices in one dimension, can be undone through what they call the Solution Determinacy Property, which lets an attacker uniquely determine the secret. Existing methods named in the paper, GroupCover and ArrowCloak, are reduced to negligible protection under this attack in the authors' tests. Their replacement, BiShield-TEE, obfuscates input and output dimensions jointly and is reported to restore security to full-shielding black-box baseline levels while improving inference efficiency over prior unilateral methods. The practical point is that a shielding method needs to be tested against the attack that fits its maths, not just against a generic adversary. m:…1763

Privacy has to be judged across the whole workflow

A fourth preprint moves the same question from a single model to a chain of agents. Multi-agent systems often check each disclosure in isolation, the authors argue, and so miss what happens when information propagates downstream to an agent that should not have received it. Their framework, Task-Graph Contextual Integrity, models the workflow as a task graph and enforces privacy policy across the chain, and they release a 144-case benchmark, MAPLE-Bench, across four scenarios to test it. In their results, the method reduces the mean unauthorised disclosure count by 85.8 to 94.1% relative to a local-history baseline, while retaining 93.6 to 96.1% of that baseline's task accuracy. The numbers are the authors' own, in a preprint, but the direction matters for anyone running agents over sensitive data: a disclosure that looks safe at one step can become unsafe three steps later. m:…5383

Read together, these preprints change the question an operator should ask before turning on a shared serving feature. It is not whether tenants are logically separated, or whether weights are nominally shielded, or whether each agent in a chain follows its own policy. It is whether the timing, the hardware behaviour and the downstream propagation have been measured. A cache, a sparsity optimisation and a task graph are all places where information moves for a reason, and each one needs a defence aimed at that exact movement. The cheapest defence is the one that survives contact with the performance budget, because a defence that gets disabled for speed protects nobody. m:…6050 m:…1831 m:…5383