A model update can be reversed into parts of the records behind it. The coordinator sees every one. A poisoned update looks like any other. Keeping data at home is not enough if the update travels in the clear.
A model update from one site is a function of that site's records. With enough care, parts of those records can be reconstructed from it. Keeping the data at home is not enough if the update travels in the clear.
Whoever runs the aggregation sees every update. Compromise that machine, or that operator, and every participant's contribution is exposed.
A participant can send a poisoned update. Without verification the coordinator cannot tell a bad contribution from a good one, and the global model absorbs it.
Secure aggregation masks each update so that only the sum of all of them can be recovered. The coordinator computes the combined model and learns nothing about any single site. Verification and drop-out handling keep the round honest when participants misbehave or disappear.
Three parts: the privacy of each update, the security of the round, and the trust between participants.
Only the sum is ever recoverable.
The round completes correctly or not at all.
Participants can verify, and nobody has to trust the middle.
Four phases from a federated set-up to secure rounds in production.
Participants, threat model, guarantee.
The masking and verification, specified.
Into the federated clients and coordinator.
Secure rounds, watched.
Federated learning that participants and their lawyers can accept.
What leaves each site cannot be reversed into records, even by the coordinator. The privacy argument holds all the way through the protocol.
Competitors, hospitals in different groups, agencies in different countries. Nobody needs to trust the middle or each other, only the protocol.
Bounds, verification and logging limit what a poisoned update can do and make it visible when one arrives.
| Side by side | Plain aggregation | Secure aggregation |
|---|---|---|
| What the coordinator sees | Every site's update | Only the sum |
| If the coordinator is compromised | All contributions exposed | Still only the sum |
| Trust needed | In the operator and every participant | In the protocol |
| A site that drops out | Round fails or leaks | Round completes, nothing exposed |
| Poisoned update | Absorbed unseen | Bounded, checked, logged |
It adds computation at each site for masking and some traffic for the shared secrets. For the participant counts typical of organisations, tens of sites rather than millions of devices, the overhead per round is modest and the rounds are dominated by training time. We measure it in the integration phase and report it.
No. It stops the coordinator and other participants from learning any single site's update. It does not by itself stop what the final global model can reveal, which is what differential privacy is for, and it limits rather than eliminates poisoning, which bounds and verification address. The assessment names the threats and which mechanism covers each.
The protocol is designed for it. The remaining participants hold enough of the shared secrets to cancel the missing site's mask, so the sum can still be recovered without revealing anyone's contribution. Below an agreed minimum number of participants, the round is aborted and logged.
Each update is bounded before it is masked, so a single site cannot push the global model arbitrarily far. Checks on the aggregate and on round statistics flag anomalies. Participants are authenticated every round, and a site that fails checks repeatedly can be excluded. The logs let every participant see when it happened.
We are a small team of senior specialists. We pick the right model and the right layer, and we build the least machinery that does the job. You get a call with an engineer, not a sales deck.
