MoE Router Telemetry Leaks Fine-Tuning Data: Attack Gains 2.7–9.4 pp in Accuracy

If you fine-tune an MoE model on private data and write routing logs "for monitoring" at the same time, those logs may become a leakage channel. In a new arXiv paper (2610.10616), the authors describe a membership inference attack that uses router telemetry. It determines whether a specific example was part of the fine-tuning dataset. Across three MoE architectures and three data domains, TPR at 1% FPR improved by 2.7 to 9.4 percentage points in each of the nine configurations. The baseline was a strong ensemble of signals from the model's output side.

How the attack works

At every layer, Mixture-of-Experts models choose which experts to activate for each token. These decisions are often logged for debugging, load analysis, and security audits. Unlike the text of a response, this data exposes the network's internal workings.

The authors combine two types of features. The first is the familiar output signals, such as the model's confidence and its loss on the example. The second is aggregated routing features. The membership classifier is trained on independently fine-tuned shadow models and then applied to the target model. This does not require access to the target's training data.

Key results from the abstract:

• 3 MoE architectures × 3 data domains = 9 configurations, and in every one the telemetry improves the attack.
• TPR gain at 1% FPR: from +2.7 to +9.4 pp over the ensemble of output signals.
• The leak persists under full fine-tuning, training with a frozen router, LoRA, and instruction tuning.
• Discrete expert choices, limited telemetry, or a single shadow model are enough.
• Noising the telemetry reduces the extra leakage only together with its accuracy.

Why the router doesn't need to memorize anything

The intuitive defense goes like this: freeze the router, and it can't memorize training examples. The mechanistic analysis shows this doesn't work. Fine-tuning writes membership information into the hidden representations. The router reads those representations and so exposes a projection of them, even when its own parameters have not changed. The leak does not require any router-specific memory.

This has an important implication for defense. It is enough that the router sees the hidden states, so targeted edits to the router will not solve anything. The fix has to target either the telemetry itself or how data gets into the weights.

The numbers deserve a caveat. The abstract gives no absolute TPR values, only the gains. Nine points at 1% FPR is noticeable, while two and a half looks modest. But this low-false-positive regime is exactly what determines whether an attack is usable for a real audit or for abuse. A consistently positive effect across all nine settings is convincing in itself.

What teams that log routing should do

Practical takeaways from the paper and their immediate implications:

• Treat routing logs as data derived from the training set. Restrict access, retention period, and export to external monitoring systems.
• Do not hand raw telemetry to customers and third-party auditors alongside model responses, especially for models fine-tuned on user or medical data.
• Reduce granularity. Aggregates instead of per-token expert choices weaken the signal. But the authors show that discrete choices are already enough, so this is a mitigation, not a guarantee.
• Noising is a trade-off. Leakage drops exactly as much as the telemetry's usefulness for debugging drops. Decide in advance how much accuracy you are willing to give up.
• Build a check into your risk assessment process. Train several shadow models on your own architecture and see how much the attack improves when routing is added. The paper shows that even one is enough.
• Consider protection at the fine-tuning level itself, for example differential privacy. This is my own conclusion, not a result of the paper, but the logic is straightforward: if the signal lives in the hidden representations, the source is what needs to be closed off.

Monitoring for MoE infrastructure, where expert logs are needed for load balancing and debugging, will have to be designed with privacy in mind.