←Blog 一覧へ
◆59 分で読了

【Part 3】 How AI leaks data at every stage of its lifecycle — and what actually stops it

Hiroshi Nakagoe, CTO at CODAS & VPoE at Archetype Digital

BLOG

This is the third post in a series on privacy preservation for the GenAI era. The first two covered inference, and training on a single organization's corpus. This one covers what happens once the training data comes from more than one organization. Earlier posts in this series:

【Part 1】 How AI leaks data at every stage of its lifecycle — and what actually stops it

【Part 2】 How AI leaks data at every stage of its lifecycle — and what actually stops it

The Training Phase: A Dataset from Multiple Parties

Industry-wide problems need more data than any one firm holds: a fraud model that sees one bank's transactions, or a tumor-segmentation model that sees one hospital's scans, is worse than one trained across all of them. Several methods exist to reach that joint model without any party handing over raw records, and what separates them is what actually moves between the parties.

Federated learning keeps the data where it is and moves the model instead. A coordinator sends the current weights to each participant, each trains locally on its own records for some number of steps, and each returns only the resulting update; the coordinator averages the updates and repeats. Cross-device federated learning runs over very large numbers of unreliable clients such as phones, where any one contribution is tiny. Cross-silo federated learning runs across a handful of institutions with named legal identities, reliable connectivity and large local datasets, which is the shape nearly every enterprise case takes. A second split is by how the data is partitioned: horizontal federated learning, where the parties hold the same fields about different people, and vertical federated learning, where they hold different fields about the same people and must first establish who overlaps.

Split learning cuts the model in two rather than the dataset. The participant runs the first few layers locally and sends only the resulting activations onward; the server runs the remaining layers and returns gradients. Nothing record-shaped leaves the silo, only intermediate tensors.

Secure aggregation is a layer over federated learning rather than an alternative to it. Participants mask their updates so that the masks cancel when the updates are summed, which leaves the coordinator able to read the aggregate and nothing else.

Secure-computation training removes the plaintext altogether. Under multi-party computation the parties secret-share their data across several compute nodes that jointly evaluate the training computation, none of them holding anything readable on its own; under homomorphic encryption the updates are summed while still encrypted and only the participants can decrypt. Both buy that guarantee with very large amounts of compute and communication.

Trusted execution environments go the other way. The data does move, but only into hardware-attested enclaves that the host operating system, the hypervisor and the cloud operator cannot read, so the parties are trusting silicon and an attestation chain rather than each other.

Data clean rooms are the commercial packaging of that idea: a provider hosts the joint environment, each party keeps control of its own inputs, and the platform enforces which queries and training jobs may run against the combination and what may leave.

The baseline all of these are measured against is simply pooling the data under contract into one party's account, which is legal in some sectors and is exactly what the rest of this section exists to avoid.

The framing that matters: multi-party training moves the trust problem, it does not remove it. The landmark FeTS study — 71 institutions across six continents, 6,314 glioblastoma cases, improving tumor-boundary detection by 15% to 33% Dice — is the poster child for why this is worth doing (Pati et al.). It is also, as published, a description of plain server-side aggregation of model updates, with no differential privacy or secure aggregation implementation described. And that is the field norm, not an outlier: in a 2025 review of 107 federated-learning-in-healthcare studies, only 41 addressed privacy-preserving model updates, 95 of 107 used a centralized topology requiring a trusted central server, and only 10 involved real-world deployments (Li et al.).

Threat models

The star rating for each threat is rated by the author alone, not by any official authority. It combines the significance of the data leakage (higher where sensitive information is leaked directly), the prevalence of the attack (how standard it is), and the ease of the attack (how easily it can be carried out), on a scale of one to five where five is highest. A heading marked “not rated” weighs up a defense or presents the opposing case rather than naming a threat of its own, so a rating there would claim something the text does not.

Group A — Leakage from the update itself

Gradient inversion ★★★★☆

A gradient is a deterministic function of the inputs, so an adversary holding the model and the update can search input space for a synthetic batch whose gradient matches.

Be concrete about what the adversary holds. The model is the global one for that round, which every participant receives and the server distributes, so its architecture and weights are not secret from anybody. The update is one target client's, for that same round — this is a per-client attack aimed at whichever participant the adversary cares about, not one computation over everyone's updates together. The search is then an optimization over inputs rather than weights: start from a batch of random noise, run it forward and backward through the known model to get the gradient that noise would produce, compare that against the gradient the victim actually sent, and descend on the pixels or token embeddings to shrink the difference. Because the gradient is a deterministic function of the batch that produced it, and for small batches very nearly a one-to-one one, the synthetic batch that reproduces the observed gradient is generally the victim's real batch rather than merely something that resembles it.

Geiping et al. showed that matching gradient direction rather than magnitude makes the attack scale-invariant, reconstructing recognizable images from batches up to 8 on CIFAR-10 and from full-resolution ImageNet through ResNet-152. The raw records flow to the aggregation server, or to anyone who can read an update in transit or at rest. In a hospital consortium this is the patient scan itself, not a statistic about it.

How well gradient inversion actually works (not rated)

Be honest with readers here, because this is a live disagreement. Huang et al. found reconstruction degrades substantially with batch size and defenses, that high-resolution recovery fails completely when BatchNorm statistics are withheld, and recommended as a design rule that "a batch size smaller than 32 is not safe." A 2025–26 replication went further: Valadi et al. evaluated canonical vision architectures at contemporary resolutions and concluded that "modern, performance-optimized models consistently resist meaningful reconstruction," and that under an honest-but-curious server — one that follows the protocol faithfully and mines everything it legitimately sees, as against one that deviates from it — gradient inversion "does not constitute a critical privacy risk in production-optimized federated learning systems." Shi et al.'s taxonomy reconciles this: honest-but-curious attacks need batch sizes of about 100 or fewer, minibatch statistics, a single local step, simple architectures and IID data; malicious-server attacks scale to arbitrary batch sizes and break existing defenses.

Gradient inversion for text ★★★★☆

Two properties make language models far more exposed than vision models. The embedding-layer gradient is non-zero exactly for tokens present in the batch, directly revealing the token set; and self-attention projection gradients are rank-deficient when total token count is below the embedding dimension, turning recovery from an optimization problem into an algebraic one. FILM recovered text at ROUGE-L near 1.0 at batch size 1 and about 0.35 at batch 128, and — opposite to the vision finding — found well-trained models more vulnerable, with about 30% better recovery against a pre-trained model fine-tuned on private data (Gupta et al.). DAGER is described as the first algorithm to recover whole batches of input text exactly: ROUGE-1 above 0.99 on LLaMA-2 7B up to batch size 128, sequences up to 512 tokens, about 20 times faster than prior attacks, with decoder models more vulnerable than encoders (Petrov et al.). Everything recovered goes to the aggregation server. For a cross-silo LLM fine-tuning consortium this is the highest-severity finding in this section: the "batch size protects you" intuition from vision does not transfer, and better-trained models leak more.

Adaptive inversion ★★★☆☆

The attacks above work by search. Given one victim update, the adversary guesses a batch, computes the gradient that guess would produce, measures how far it lands from the update it observed, and adjusts the guess to close the gap — then starts over from nothing for the next victim. This attack replaces the search with a trained model, so the work is done once and every later update costs a single forward pass.

Building that model takes three steps and no access to the victim's data. First the adversary collects its own labeled examples from a similar domain: Wu et al. use the CIFAR-10 training split against vision clients and CoLA or WikiText against language ones, and show the attack still works when some of those examples come from the wrong distribution entirely. Second it runs each example through the global model to obtain the gradient that example produces, and applies to that gradient whatever perturbation the victim applies before sending — which leaves it holding a supply of pairs, each a perturbed gradient sitting next to the input that made it. Third it trains a multilayer perceptron on those pairs in the direction gradient-to-input. The result takes a victim's update and returns the batch behind it: pixels for images, and for text a probability vector over the vocabulary at each position.

The gradient distortion here is the defense, not part of the attack. Perturbing the update before sending it — taking only the sign of each coordinate, pruning all but the largest 1%, adding a little Gaussian noise — is the cheap alternative to differential privacy: garble the gradient enough that optimization-based inversion fails, without paying for a calibrated mechanism. It works only while the adversary is searching. Against a learned inverter the distortion stops being an obstacle and becomes part of the function being learned, because the attack trains on gradients that already carry it, and nothing about it is secret in the first place — which perturbation a consortium applies is a configuration choice its own members can read. Wu et al.'s Learning To Invert reports mean squared error of 0.014 under sign compression against 0.116 for prior attacks, 0.029 under gradient pruning at α = 0.99, and on text classification 63.89% token accuracy versus 1.62% for the baseline — concluding that for text even σ = 0.001 noise is insufficient. The recipient is again the server. Heuristic gradient obfuscation is not a defense; only calibrated differential privacy or cryptographic hiding is.

Membership inference against federated updates ★★★☆☆

A participant or server observing successive global snapshots can difference them to isolate other parties' contributions. The knowledge of who is in whose dataset flows to a malicious participating organization — which in a health or financial consortium is itself the sensitive fact. Melis et al.'s adversary controls one participant and observes the rest, achieving 0.99 precision with perfect recall for inferring location profiles from FourSquare data, and 0.92 precision at batch size 32 on Yelp-health.

Secure aggregation does not stop membership inference (not rated)

Secure aggregation hides individual updates but reveals the sum, and the intuition it invites is that your update is one of many and therefore buried. Two things break that intuition. The first is that the cover is not noise: what gets added to your update is other clients' updates, ordinary vectors of the same kind, not values calibrated to conceal anything. The second is dimension. An update has one coordinate per model parameter, so thousands to millions of them, and vectors drawn independently in a space that large are nearly orthogonal to one another — the other clients' updates barely overlap with the direction yours points in, so your contribution survives the sum as a component nothing else cancels. Ngo et al. put it plainly: it is “difficult to hide a local update by adding other independent local updates when the updates are of high dimension.”

That is also why a bigger model makes things worse rather than better. The server is not trying to reconstruct anything; it is answering a yes-or-no question, testing whether the aggregate it observed is more consistent with some candidate update having been in the sum or absent from it. More dimensions leave more room for that candidate to stand out. Their experiments bear it out: on ADULT, a tabular census dataset, with 60 to 90 clients, the false-negative and false-positive rates fall to 0.005 at the same time, and the attack does better still on EMNIST, a handwritten-character benchmark whose model carries far more parameters and so produces much higher-dimensional updates. Adding clients helps only marginally, because the shortfall is in the geometry rather than in how many vectors are being summed.

So membership still leaks to an honest-but-curious server that only ever sees the aggregate, and secure aggregation “provides weak privacy even for a single training round.” This is the single best citation for the point that secure aggregation is a confidentiality mechanism, not a privacy mechanism.

Property and attribute inference from updates ★★★★☆

Updates encode correlations the joint task never asked for. A gradient responds to everything in the batch that shaped the loss, not only to the attribute being predicted, so a model trained to recognize gender also carries a signal for race, and one trained to sort reviews carries a signal for who wrote them.

The method has the same shape as the learned inversion above, and needs no access to the victim's data either. The adversary is one of the participants, so it holds the global model each round and sees the updates coming back. It also holds its own examples, which it can label for whatever property it is curious about. Each round it takes the current model, computes the gradient of a batch that has the property and the gradient of a batch that does not, and keeps both as a labeled pair — across rounds that accumulates into a training set of gradients marked has-property or not. A binary classifier fitted to that set then reads the same verdict off the updates it observes from everybody else. An adversary willing to be active does better still by bolting a property-classification head onto its local copy of the model and training on a joint loss, which nudges the shared model toward representing the property more separably and makes every later round easier to read.

Melis et al. inferred "race: black" from an LFW gender classifier at AUC 1.0, doctor specialty from Yelp healthcare reviews at "perfect accuracy," and eyewear from a race classifier at AUC 0.94–0.97. The gainer is a malicious participating organization — and note this is a commercial confidentiality leak as much as a personal-data one: a bank learns its partner's demographic mix or product concentration.

Non-IID heterogeneity and the differential-privacy trade-off ★☆☆☆☆

Under non-IID partitioning, per-client update norms are larger and more variable, so a fixed clipping bound either destroys signal from atypical clients or forces more noise. Differential-privacy noise is regressive: minority silos are clipped hardest, degrading exactly the subpopulations federated learning was supposed to include. Apple's speech-recognition deployment demonstrates it: user-level (7.2, 10⁻⁹) differential privacy cost 1.3% absolute word error rate at high population scale, but (4.5, 10⁻⁹) cost 4.6% at low population scale — a 3.5-times larger accuracy penalty on the smaller population, at a tighter ε rather than the same one, so the two settings bound the effect rather than isolating it (Pelikan et al.). What is at risk is utility and fairness rather than confidentiality.

Group B — The malicious server

Imprint modules ★★★★★

The server controls the architecture and the weights it distributes, and Fowl et al. showed what an adversarial one can do with that power: insert a small linear-plus-ReLU module whose biases are the inverse-CDF quantiles of some scalar function of the data, so each bin activates for at most one sample and the corresponding gradient rows are that sample. There is nothing to reconstruct afterwards, because the records are sitting in the update in readable form.

Unpacked, that module is one fully-connected layer with a bias followed by a ReLU, placed near the input and passing its output into the real model. Every row of its weight matrix is a copy of the same vector, chosen so the layer computes one scalar summary of each input — in their worked example that row is 1/m in every position, which makes the summary the average brightness of the image. The biases are then the negated quantiles of that summary's distribution, which a server can estimate from public data of the same kind: the bias of unit i is placed where a fraction i/k of inputs fall below it. The k units are therefore nested threshold detectors, and the quantile spacing is the whole trick — it drops roughly one sample into each bin instead of clumping the batch into a handful of them.

That spacing is what turns the update into a read-out rather than a puzzle. Subtract the weight-gradient row of one bin from the row of the next, divide by the difference between the two bias gradients, and what falls out is the single input that landed between those two thresholds. No optimization, no BatchNorm statistics, no label assumptions. The signature to look for in a distributed architecture is accordingly quite specific: a wide linear layer at or near the input whose weight rows are all identical and whose biases increase monotonically, costing around 1% of the parameter count and behaving like an ordinary layer in every other respect.

On ImageNet with ResNet-18 at batch 64, an imprint block of 128 bins reconstructed most of the batch at an average PSNR of 75.75, and at 156 bins more than half the batch came back perfectly; in a one-shot industrial-scale setting with a batch of 16,384 images and about 1% extra parameters, a complete image was extracted at PSNR 161.36 — a verbatim copy around machine precision. Crucially, the attack survives secure aggregation, which degrades to secure shuffling: the records still reach the server, merely unattributed.

Trap weights ★★★★☆

Same goal as the imprint module, reached without adding anything to the architecture. Boenisch et al. leave the structure alone and choose the values of the first fully-connected layer so that it does the binning by itself. Each row is built so its negative weights are slightly larger in magnitude than its positive ones: sample the negative half from a Gaussian, then set the positive half to that half negated and scaled down by a factor below one. A unit's weighted sum then clears zero only for an unusually well-matched input, so its ReLU stays dark for most of the batch. Tune the scaling factor and many units end up firing for exactly one sample per minibatch, at which point the read-out is the division from the previous entry: that unit's weight-row gradient, divided by its bias gradient, is the sample.

The ambition is lower and the stealth is higher. This is probabilistic rather than guaranteed — the claim is that many neurons isolate a single point, not that all of them do — but nothing is added to the model, so there is no extra parameter count to notice and nothing structurally unusual for a client to find. On ImageNet at batch 100 the attack "perfectly reconstructs more than 50% of the training data points"; on IMDB sentiment analysis, more than 65%. It survives multiple local epochs, which disposes of the common argument that the many local steps of federated averaging — where each client trains for a while before sending anything, and the server averages what comes back — blur the update enough to protect the participant. Everything recovered goes to the server operator.

Breaking secure aggregation by model inconsistency ★★★★☆

Secure aggregation assumes every client is computing an update to the same model, and nothing in the protocol checks that they are. Pasquini, Francati and Ateniese turn the gap into what they call a gradient suppression attack. A ReLU unit whose pre-activation is at or below zero passes no gradient back at all, so a server that sets a layer's weights to zero and its biases to something non-positive has built a model that returns an exactly zero update for any input whatsoever. Send that model to everyone except one target and the real parameters to the target, and the protected aggregate is the target's update by itself — disaggregation with the cryptography left entirely intact.

Their own framing is the part to carry away. The attack works "independently of the number of users participating in the secure aggregation" and is "equally effective regardless of the secure aggregation protocol used," because it stems from "lack of parameter validation" rather than from any weakness in the masking. Secure aggregation without cross-client verification that everyone received the same model is security theater against an active server.

Threats to secure aggregation itself ★★★☆☆

Two further places where the protocol's own machinery hands the server leverage. Secure aggregation has to tolerate clients dropping out mid-round, and the recovery step requires the server to announce which ones dropped — so a malicious server can simply lie, declaring honest clients absent to shrink the cohort a target is hiding among. Separately, the server decides which devices take part in each round at all, which lets it steer a round toward whichever cohort it wants to observe.

Bonawitz et al. document the surrounding numbers matter-of-factly in Google's production system paper: pace steering, selection of 130% of the target device count to absorb losses, and production dropout of 6–10%. They also record a scaling limit worth knowing about. Secure aggregation's cost grows quadratically in the number of users, which caps a single instance at hundreds of clients; production handles that by running the protocol separately per aggregator and then combining those intermediate results, without additional encryption, at a master aggregator. That combination point is a real trust boundary, and partial sums cross it in the clear ("Towards Federated Learning at Scale").

Split learning and smashed-data leakage ★★★★☆

Split learning cuts the model in two. The client runs the first few layers and sends the resulting activations — the smashed data — to the server, which runs the rest and sends back the gradients the client needs in order to keep training its own half. The appeal is that raw inputs never leave the client. The catch is that the server controls the client's entire training signal.

Pasquini, Ateniese and Bernaschi's feature-space hijacking attack uses exactly that control. The server trains, on public data of the same kind, a pilot network together with that network's inverse. Then, rather than returning the gradients the joint task calls for, it returns forged ones that steer the client's layers toward reproducing the pilot network's feature space. After a setup period the client is computing a function the server already knows how to invert, so recovering an input from the smashed data is one forward pass through the inverse. They report accurate reconstruction within roughly 1,000 to 3,000 setup iterations and negligible degradation across data distributions, and they show that the NoPeek defense — which has the client add a regularizer penalizing correlation between its inputs and the activations it sends — fails, because the server can rescale the task loss until the client's privacy term counts for nothing beside it. Clients "cannot effectively detect the attack since they lack access to the complete network during training," so the inputs reach the server and nothing in the client's own view of training says so. Split learning with an untrusted server is not a privacy technology.

Vertical federated learning label leakage ★★★★☆

Vertical federated learning is the arrangement where the parties hold different columns about the same people, rather than different rows about different people — a bank and a retailer with an overlapping customer list, one contributing transaction features and the other purchase features. One party, called the active party, also holds the labels. The others are passive: they contribute features and receive gradients so their own layers can learn.

Those returned gradients give the labels away almost for free. With a softmax output and cross-entropy loss, the last layer's gradient is negative at exactly the true-label coordinate and positive at every other, so a passive party need only read the signs, with the norms sharpening the inference further (Liu et al.). The label column is usually the commercially valuable asset in the whole arrangement: who converted, who defaulted, who churned. Note that this leak runs in the opposite direction from the rest of this group, out from the active party to the passive ones.

Group C — Malicious participants

Sybil clients ★★★☆☆

several independent parties. In cross-device federated learning identities are cheap to create, and both the averaging weight and most robustness heuristics are counted per identity, so an adversary's influence grows with the number of identities it can register rather than with the amount of data it actually holds. Fung et al. measured the leverage: with 2 sybils out of 12 clients, MNIST attack success reached 96.2%, against 35.9% for the same adversary acting as one client. What is compromised is model integrity, and the compromiser is whoever can register client identities cheaply.

Model poisoning and backdoors from malicious participants ★★★★☆

Federated averaging computes a weighted mean, and a mean can be moved anywhere by a single term if that term is large enough. So a participant that wants the global model to become its own poisoned model scales its submitted update by the inverse of its averaging weight, and the average lands on exactly the model it chose. Bagdasaryan et al. call this model replacement, and it needs no repetition across rounds. They achieved almost 100% accuracy on a semantic backdoor — one triggered by a feature that occurs naturally in the input, such as a car of a particular color, so nothing has to be tampered with at inference time — on CIFAR-10 from a single attacker, and 100% backdoor accuracy on Reddit word prediction from one compromised participant out of 83,293, persisting more than 20 rounds.

A defense that looks for the resulting outlier can be evaded by spreading the attack out. The distributed backdoor attack cuts one trigger pattern into pieces and gives a piece to each of several colluding participants, so no single update looks anomalous while the global model still learns the trigger whole. Against FoolsGold — which down-weights clients whose updates point in suspiciously similar directions, on the theory that sybils collude — that decomposition is precisely the wrong thing to be watching for: on MNIST the distributed version reaches 91.55% where the centralized equivalent manages 2.91% (Xie et al.). The integrity of every decision the joint model later makes is thus at the mercy of one consortium member — in a bank anti-money-laundering consortium, a backdoor that whitelists a chosen counterparty pattern.

Robust aggregation rules are themselves breakable (not rated)

The standard answer to the previous entry is to replace the mean with a statistic an outlier cannot move. Krum picks the single update most similar to its nearest neighbors and discards everything else. Coordinate-wise median takes the median of each parameter across clients. Trimmed mean drops the largest and smallest values of each parameter before averaging what remains. Bulyan runs Krum repeatedly to select a subset, then trimmed-means that subset. All four carry Byzantine-robustness guarantees, and all four rest on assumptions federated learning violates.

Fang et al. break them by treating the rule as a constraint rather than an obstacle: craft the compromised clients' updates so as to push the global model as far as possible in the opposite direction to where it would otherwise have gone, subject to still being accepted. Against Krum that means making the crafted update the one Krum selects. Against median and trimmed mean it means placing values just outside the honest range but close enough in to survive the trim and drag the order statistic with them. With 20% of clients compromised, and an attacker who sees only its own compromised devices rather than the whole cohort, Krum's error rate on Fashion-MNIST rises from 0.16 to 0.90, trimmed mean on CH-MNIST from 0.17 to 0.69, and median on MNIST from 0.06 to 0.28. What is lost is both model integrity and the false assurance that running Krum bought anything.

The counterpoint (not rated)

Shejwalkar et al. argue the poisoning literature assumes unrealistic adversary fractions and absence of defenses, concluding "FL is highly robust in practice even when using simple, low-cost defenses." Present this as a genuine live disagreement, with the distinction that resolves it: cross-device federated learning at Google scale has natural dilution and strong client-admission controls; cross-silo consortia of 5 to 70 named institutions do not. A single malicious hospital is 1 in 71 of the round, not 1 in 83,293.

Free-riding ★☆☆☆☆

A participant that wants the joint model without spending anything on data still has to submit something that looks like an update. The cheapest convincing fake is the difference between the last two global models, which the server has already handed it: that difference is the scaled average of everybody else's previous round of work, so it points where a real update would point. Lin, Du and Liu call this the delta-weight attack, and add a variant that fixes its one tell — a recycled average is too smooth to pass as one client's work, so the advanced version adds Gaussian noise at σ = 10⁻³ to match the spread of a genuine update.

Their defense scores each update by how improbable it looks against the population of updates that round, a quantity the method calls its energy. Both variants get past it. Early in training, when the global learning rate is below 0.3, the detector misses plain delta-weight free-riders altogether, and against the advanced variant "the energy value of the free rider is completely hidden among normal clients." What leaks here is not data but value: the honest parties' data is converted into a model the free-rider obtains for nothing.

Group D — Leakage after training

The final joint model as a leakage channel ★★★★★

Every participant receives the trained model. If it memorized another party's records, each participant is handed a queryable oracle over its partners' data. This threat is unaffected by secure aggregation, multi-party computation, homomorphic encryption or enclaves, all of which protect the process rather than the output. Hu et al. had a malicious client prompt the federated global model with contextual prefixes drawn from its own data, and recovered up to 56.57% of the PII held only by victim clients in their strongest configuration against Qwen1-8B, with names, addresses and birthdays the most exposed categories. Bossy et al. injected synthetic medical records into a federated fine-tuning run and found that LoRA reduced memorization by up to a factor of ten relative to full fine-tuning, at negligible accuracy cost — a mitigation, not a cure, since their own rank ablation shows exact-match completion climbing back above 20% at rank 64 and near 50% at rank 256. Verbatim records of other consortium members thus reach every member. This is the threat most consortium legal agreements fail to address, because they focus on "data never leaves your premises."

Group E — Clean rooms

Clean rooms: differencing and query-based re-identification ★★★★☆

An aggregate-only query interface leaks individuals through arithmetic. Ask for the average salary of everyone in a department, then ask again with one extra condition that happens to exclude one person, and the difference between the two answers is that person's salary — no rule was broken, and every answer returned was an aggregate. Any predicate that separates one record from the rest will do, which is why individual-level attributes reach any external party permitted to query at all. The defenses are minimum-aggregation thresholds, cross-query difference checks and noise, and each of them is a configurable knob. Google's Ads Data Hub enforces minimum unique-user thresholds of approximately 20 users per row under noise injection, 50 under difference checks, and 10 for click-only data ("Privacy checks in Ads Data Hub"). The practitioner counterpoint is that clean-room privacy "is ultimately based on clean room contracts between partners," that providers offer configurations letting partners "dial back the threshold," and that an identity backbone persists, so re-identification pathways remain (Duball).

Clean rooms: what encryption does not hide ★★★☆☆

AWS's Cryptographic Computing for Clean Rooms encrypts sealed columns with AES-GCM and join columns with HMAC, but supports only JOIN, SELECT and some GROUP BY — no WHERE clauses and no aggregate functions. AWS itself lists what remains inferable by the counterparty: table metadata, column names and count, row count, the length of encrypted values, and row-insertion timing ("Cryptographic Computing for Clean Rooms"). And overlap size — how many of your customers are also mine — is itself commercially sensitive.

Protection methods

This section shows "practical" solutions against the above threat models. There is a gap between the literature and the shipping code, so the version and maintenance status of each framework matter. Controls that exist only as papers or abandoned research repositories are gathered later.

Choosing a framework at all

Two frameworks are maintained and production-usable, and the field behind them has thinned dramatically. Flower (pip install flwr, 1.38.0, September 2026, Apache-2.0) is the general-purpose option; note the repository moved from adap/flower to flwrlabs/flower, so older citations point at the wrong place. NVIDIA FLARE (pip install nvflare, 2.9.0, September 2026, Apache-2.0) is the more feature-complete on privacy mechanisms specifically. Both support federated LoRA fine-tuning of language models as a first-class path — Flower through its FlowerTune examples, FLARE through nvflare.client.hf, which patches Hugging Face's Trainer and SFTTrainer directly, plus NeMo federated parameter-efficient fine-tuning.

The rest of the field needs correcting in most people's reading lists. OpenFL, long the standard citation for enclave-backed federated learning, states in its own README that the project is no longer under active development and will soon be archived, and its migration documentation points users to Flower. TensorFlow Federated has not released in about two years, and Google's own FAQ says that for deployment to real devices it does not currently provide any tools and that the release is intended for experimentation using the included simulation runtime. PySyft is still actively maintained but is no longer a federated-learning framework — version 0.10 and later is a remote data science sync engine, and the legacy federated API requires pinning below 0.10. FedML has not released since February 2025 and its README is dominated by its commercial successor. Substra and FATE carry real consortium deployment heritage — MELLODDY, hospital networks — and neither has shipped in roughly two years; cite them as precedent, not as software. Two under-cited live options worth knowing: Argonne's APPFL and Scaleout's FEDn.

Secure aggregation

Pairwise Diffie-Hellman masks that cancel in the sum, with Shamir secret sharing of seeds so dropped clients' masks can be reconstructed; the server learns only the sum. Worth naming plainly, because the vocabulary hides it: this is multi-party computation. It is a special-purpose protocol that computes exactly one function — the sum of the participants' updates — and that narrowness is why it runs at production scale when general-purpose multi-party computation does not.

Exactly one maintained framework ships a masking protocol you can adopt. Flower provides SecAggWorkflow, which takes a reconstruction threshold, and SecAggPlusWorkflow, which takes a share count, with the matching secagg_mod and secaggplus_mod client modifiers. There is an adoption constraint here that nobody mentions and that will bite: those modifiers exist only in the legacy flwr.client.mod namespace. The newer flwr.clientapp.mod surface that Flower's current documentation steers you toward ships the differential-privacy and clipping modifiers and no secure-aggregation modifiers at all. Robust-aggregation strategies and differential-privacy wrappers were ported to the new API; secure aggregation was not. Adopting SecAgg+ today means staying on, or mixing in, the older surface.

NVIDIA FLARE takes a different route and offers no masking protocol: its equivalents are homomorphic aggregation and aggregation inside a confidential virtual machine, both covered below. TensorFlow Federated's SecureSumFactory and related aggregators exist as APIs, but given that the same project says it ships no tooling for real deployment, these are simulation placeholders — run them on the default backend and you get plaintext sums wearing secure-aggregation types.

Secure aggregation stops an honest-but-curious server from reading individual updates, which closes plain gradient inversion, text gradient inversion and adaptive inversion in the passive-server threat model, and it blunts per-client property inference. It does not stop membership inference against the aggregate, and it does not stop any malicious-server attack — imprint modules, trap weights and model inconsistency all defeat or bypass it. Measured costs from the original paper: communication expansion of about 1.98 times, and — the dominant cost driver — server time for 1,000 clients rising from about 4.9 seconds at 0% dropout to about 414 seconds at 30% dropout (Bonawitz et al., "Practical Secure Aggregation"). SecAgg+ replaces the complete pairwise graph with a k-regular graph at k = O(log n), so that the semi-honest variant handles a billion clients at the per-client cost the original protocol paid for a thousand (Bell et al.). One reporting note worth making: Flower's secure-aggregation documentation states no threat-model caveats at all — no discussion of dropout resilience, of malicious-server security, or of the honest-but-curious assumption. Read the absence of documented limitations as an absence of documentation, not as evidence of malicious security.

Differential privacy for federated learning

Per-user clipping plus calibrated noise, giving a formal bound on any inference about one participant. Three arrangements are possible, and what separates them is who is trusted to see an un-noised update. Under central differential privacy — global differential privacy is the same thing under another name — the server receives the raw updates, aggregates them and adds the noise itself, so every participant is trusting the coordinator with an un-noised view. Under local differential privacy each client noises its own update before it leaves, so nobody is trusted, at a utility cost that worsens as the cohort grows. Distributed differential privacy sits between the two: each client adds a share of the noise and secure aggregation hides the individual contributions, so the sum arrives noised without anyone ever holding an un-noised view of it.

Only the first two have adoptable implementations, and central differential privacy is the practical default. Flower ships four wrappers in both the legacy and current namespaces, server-side and client-side variants of fixed and adaptive clipping; the server-side pair is central differential privacy, with the coordinator clipping and noising the aggregate. LocalDpMod and Opacus 1.6.0 underneath cover the local and client-side DP-SGD path instead. That combination is genuinely adoptable today. Distributed differential privacy is the one with no adoptable implementation, and it is taken up at the end of this post.

Be precise about NVIDIA FLARE here, because its terminology invites over-reading. FLARE ships privacy filters — ExcludeVars to drop variables from a shareable, PercentilePrivacy for percentile truncation of weights, and SVTPrivacy described as differential privacy through sparse vector techniques. Its own filters documentation calls filters the primary technique for data privacy protection and then enumerates no privacy guarantee for any individual filter, with no ε or δ accounting anywhere. PercentilePrivacy in particular is a heuristic, not a calibrated mechanism. A filter named for privacy is not a privacy guarantee.

This is the only control that addresses membership inference against updates, property and attribute inference, and the final-model leakage channel — the three that survive every cryptographic measure. It bounds what the finished weights can memorize about any one participant. It does nothing against poisoning, free-riding, or the malicious-server attacks that extract data before noise is applied at the server. The founding result, DP-FedAvg, achieved (4.6, 10⁻⁹) differential privacy at 17.49% accuracy against 17.62% non-private on 763,430 Reddit users — a 0.13-point loss, at roughly 60 times the computation (McMahan et al.). Actually deployed values: Google reports Gboard language models trained with ρ-zCDP — zero-concentrated differential privacy, an accounting in which ρ replaces ε and composes more tightly over many rounds — where ρ lies between 0.2 and 2 — specifically ρ = 1.31 for US English next-word prediction, improving to ρ = 0.25 for the model that combined DP-FTRL, which adds noise correlated across rounds rather than relying on random client sampling, with secure aggregation on top of the central mechanism — and states that all next-word-prediction neural models in Gboard now carry differential-privacy guarantees (Xu et al.; Zhang et al.). Apple reports user-level (7.2, 10⁻⁹) and (4.5, 10⁻⁹) for speech recognition. These are far from the ε ≤ 1 theorists prefer, and user-level guarantees require a stable notion of "user," which cross-silo consortia often lack — is the unit the hospital or the patient?

Homomorphic encryption for aggregating updates

Clients encrypt updates under a shared key; the server adds ciphertexts; only clients decrypt. It addresses the honest-but-curious server reading individual updates — the same target as secure aggregation, without the quadratic cost and dropout fragility. It does not address the malicious-server attacks, because a malicious server controls the plaintext model it sends out, which is upstream of encryption, and it does nothing for the final-model channel.

NVIDIA FLARE is the one turnkey path and the module names are concrete: HEModelEncryptor, HEModelDecryptor, HEInTimeAccumulateWeightedAggregator and HEModelSerializeFilter under nvflare.app_opt.he, with CKKS through TenSEAL and the context loaded from the workspace — CKKS being the homomorphic-encryption scheme built for approximate arithmetic over vectors of real numbers, which is what a model update is. Older documentation uses nvflare.app_common.homomorphic_encryption.*; the app_opt.he paths are current.

The underlying libraries are in better health than their reputation suggests, and this is worth correcting explicitly. TenSEAL released 0.3.18 in September 2026 and is actively maintained. OpenFHE released in April 2026. Microsoft SEAL is not archived — version 4.4 shipped in July 2026 and its README calls it a critical security update that all users should adopt as soon as possible, which means anyone pinned below it has a live security problem rather than a dormant dependency. Zama's Concrete ML is the slowest-moving of the four at about seventeen months.

FLARE's own CKKS numbers: encryption at about 5 seconds, model size growing from 19 MB to 283 MB — about 15 times — and training-time overhead of 20% for full-model encryption or 1–15% for selected layers (Roth, Zephyr and Harouni). The distinction that decides everything: those figures are for additively homomorphic aggregation of already-computed updates, not for computing the training itself under encryption. The ICO's figure for the latter — fully homomorphic encryption being "several thousand times slower than processing plaintext" — is the one that applies to training under encryption, and as the end of this section sets out, that case has no implementation at all. Do not let a vendor quote the first number for the second use case.

Trusted execution environments

Run the joint computation inside hardware-attested enclaves so the cloud operator and other parties see only ciphertext, with attestation proving which code runs. This is the answer to coordinator and cloud-operator trust.

Google Confidential Space is the one with a published reference architecture for confidential federated learning, with the federated server inside the enclave cluster, supporting AMD SEV and SEV-SNP, Intel TDX, Arm CCA, IBM Z and NVIDIA confidential GPUs. NVIDIA FLARE's own confidential federated AI supports AMD SEV-SNP with H100 and Blackwell confidential computing, and Azure confidential computing, with Intel TDX promised in a future release.

The cost news is good: confidential H100 costs 6.85%, 4.58% and −0.13% in tokens per second for Llama-3.1-8B, Phi-3-14B and Llama-3.1-70B respectively — roughly three orders of magnitude cheaper than multi-party computation or homomorphic encryption. The limits: the ICO notes enclave scalability constraints, side-channel and timing attacks, and that "insecure or buggy code within a TEE will often not mitigate security risks"; trust moves to the silicon vendor; and an enclave does nothing about the final-model leakage channel. One further limit carries over from the previous phase — confidential training is capped at a single node, so an enclave-hosted aggregator is fine while enclave-hosted large-scale joint training is not.

Data clean rooms

A clean room is a governance product rather than a cryptographic primitive, and the two are worth keeping apart because the limits above do not transfer. A clean room is not capped at a single node, does not inherit the enclave cost overhead, and in several cases does not involve an enclave at all. What it gives you is a controlled venue — approved queries or jobs over datasets that each party keeps — and the question to ask of any given product is not how fast it is but who is inside the trust boundary.

That question splits the field. Where the platform operator is outside the boundary, the room is built on an enclave: Google Confidential Space and Azure Confidential Clean Rooms are in this group, as are the commercial offerings Decentriq, Opaque and Duality. Where the operator is inside it, the room is access control and audit over data you have nonetheless given the platform to process. Databricks Clean Rooms is explicit about this and is the clearest illustration — generally available since February 2025 on AWS and Azure, running Python notebooks natively, but built on Delta Sharing governance rather than a trusted execution environment, so it does nothing if your adversary list includes the platform operator. That is a legitimate design for a consortium whose members already trust the same cloud, and a disqualifying one for a consortium whose whole reason for existing is that they do not.

The other useful thing to say is that the SQL-only stereotype is out of date. AWS Clean Rooms is generally available and does custom modeling with incremental and distributed training, synthetic dataset generation and lookalike models, with differential-privacy controls in the product. Snowflake's Data Clean Room ML Jobs are generally available and run distributed XGBoost, LightGBM and PyTorch with built-in hyperparameter optimization and optional GPUs — any containerized Python workload, gated by template approval and content hashes.

Azure Confidential Clean Rooms deserves a correction rather than a recommendation. It is in limited preview, and Microsoft's own documentation says customers should not use the preview to process personal data or other data subject to legal or regulatory compliance requirements, that it is intended for testing, evaluation and feedback, and that it should not be used in production. It supports CSV, Parquet and JSON, Spark SQL only with machine learning by request form, and Microsoft notes it might not be able to accept all requests. Its governance design is the most rigorous of the group — every collaborator whose dataset is referenced must approve each query — which makes the preview status genuinely frustrating rather than merely academic.

Whichever side of the trust line a room sits on, it answers the clean-room operator problem only in the enclave case, and neither case touches the two clean-room threats from earlier in this post: an analyst who differences two near-identical queries still isolates individuals, and the counterparty still learns what encryption does not hide. Those are answered by query governance and minimum-aggregation thresholds, not by where the compute runs.

Robust aggregation against poisoning

Flower ships the most complete built-in set of any maintained framework, and unlike secure aggregation these were ported to the current namespace: Krum, MultiKrum, Bulyan, FedMedian and FedTrimmedAvg. Adopting them is a strategy swap. NVIDIA FLARE has no Byzantine-robust aggregator in its built-in set — its filters are privacy filters, not robustness ones — though NVIDIA has published anomaly-detection research against FLARE.

These aim at model poisoning, backdoors and sybil clients, and at nothing else in this section. Two rules that are widely cited as available are not: FLTrust and FoolsGold appear in no maintained framework and remain one-off research repositories. That is a shame, because FLTrust is the most defensible design in the literature — it bootstraps trust rather than assuming a benign majority, with the server holding a small clean root dataset, scoring each client by rectified cosine similarity to its own update and normalizing every update to the root update's norm. A root dataset of only 100 examples sufficed; under adaptive attacks with 40–60% malicious clients the global model matched FedAvg under no attack, and it tolerated up to 90% malicious clients (Cao et al.), with the honest stated limitation that it may not be robust against a poisoned root dataset. FoolsGold handled up to 99% sybils but performs poorly against lone malicious clients lacking colluding partners. The standing caveat for the whole category: these defenses degrade sharply under non-IID data, and no robust aggregation rule in the literature survives an adaptive attacker who knows the rule.

Private set intersection

Computes the overlap without either party learning non-intersecting records, which addresses the record-linkage half of the clean-room problem. This is the second special-purpose multi-party computation protocol in this section, and arguably the most mature cryptographic primitive in the entire post.

SecretFlow's PSI, Apache-2.0, split out of SPU into its own repository with published containers, implements ECDH-PSI, KKRT and both RR22 variants, plus private information retrieval. Its published benchmarks are the reason to name it: ten million against ten million records in about 17 seconds on a 32-core machine over a local network; a hundred million against a hundred million in roughly three to twenty minutes depending on protocol and hardware; and a billion against a billion in 0.62 to 3.8 hours, with wide-area results published alongside. OpenMined's PSI is solid and multi-language but has not released since June 2025 and publishes no billion-scale numbers. Google's private-join-and-compute is the reference implementation of intersection-sum with no tagged releases — research code, not a product.

One conflation to avoid: private set intersection inside AWS, Snowflake or Azure clean rooms is generally a governed join under platform isolation, not a cryptographic protocol. The two are routinely described in the same words and are not the same control.

It hides non-intersecting records but reveals the intersection size, and a malicious party can probe membership by submitting a singleton set unless the protocol is actively secure and rate-limited.

Client authentication

In cross-device settings, enrollment control is the real defense against sybil clients. Flower's SuperNode authentication is the shipping mechanism: by default it checks timestamp-based signatures to prevent impersonation and replay, and opt-in node authentication maintains a whitelist of elliptic-curve public keys for trusted nodes. Read the direction carefully, because it decides what this control can do. It is unidirectional — the server verifies clients. Nothing in it lets a client verify the server, which is the gap taken up at the end of this section.

In cross-silo consortia participants are legally identified entities, so sybils are a contractual problem rather than a cryptographic one, and the useful control is attesting the code each silo runs — which remote attestation in Confidential Space and FLARE's confidential deployments does provide.

Architectural hygiene

Cheap, underused, and drawn directly from the primary literature — but be clear which of these are framework features and which are conventions you implement yourself.

Withholding BatchNorm running statistics makes high-resolution gradient inversion fail outright, and Flower documents the FedBN pattern in its own guide. It is user-implemented rather than a built-in strategy: you filter the state dictionary on receipt and again before building the outgoing record. The published pattern matches on the substring bn in parameter names, which is silently wrong for any model whose normalization layers are named differently — a ten-line convention, not a guarantee. Treat a batch size of 32 as a floor, for the same threat. Freezing word embeddings closes the token-set channel that makes text gradient inversion so effective, at negligible utility cost when starting from a pre-trained model; there is no framework knob for it, just requires_grad = False in the client loop, and nothing validates that clients actually did it. Preferring LoRA over full fine-tuning cuts the final-model leakage channel by roughly ten times, and this is the one item here with genuine first-class support in both live frameworks — shipping only adapter deltas also shrinks the gradient-inversion surface considerably.

Hybrid layerings

These are not interchangeable, and each layer exists because the one below it leaves a specific class open. The rightmost column is the honest part: whether you can assemble the layering from maintained software today.

Layering What it closes that the base does not Adoptable today
Federated learning + secure aggregation Server reading individual updates, so passive gradient inversion Yes — Flower SecAgg+, legacy API only
Federated learning + differential privacy Membership and property inference, and memorization in the final model, with a trusted curator Yes — Flower DP wrappers plus Opacus
Federated learning + homomorphic encryption Server reading updates, without the quadratic cost and dropout fragility of secure aggregation Yes — NVIDIA FLARE with TenSEAL
Differential privacy + robust aggregation Differential privacy does not stop poisoning; robust aggregation does not stop inference Yes — Flower, both in the current namespace
Enclave-hosted aggregation + governance Coordinator and cloud-operator trust Yes — Confidential Space, FLARE confidential FL, AWS and Snowflake clean rooms
Secure aggregation + distributed differential privacy Removes the trusted-curator assumption entirely, so no party ever sees an un-noised update No — see below
Secure aggregation + parameter validation Model inconsistency, imprint modules and trap weights No — see below

The design rule to state plainly: secure aggregation, homomorphic encryption and enclaves protect the confidentiality of the process; differential privacy protects against inference from the output; robust aggregation protects integrity. A stack missing any of the three has an open class of attack — and, as the last two rows show, two of the layerings the literature recommends most confidently cannot be assembled from shipping code at all.

What has no adoptable implementation in multi-party training

This is the longest such list in the post, and the pattern running through it is worth naming: these frameworks were built to defend the server against clients, and almost nothing defends a client against the server.

Distributed differential privacy is the sharpest example of a correct implementation stranded on a dead substrate. TensorFlow Federated implements the Kairouz–Liu–Steinke distributed discrete Gaussian faithfully, as ddp_secure_aggregator with Hadamard and discrete-Fourier rotation and the supporting modular-sum factories, citing the papers directly. Its entire privacy argument rests on the modular sum being computed under real secure aggregation, and TensorFlow Federated's secure aggregation is simulated. No maintained framework has ported the mechanism to a working secure-aggregation backend. Nobody has published this exact layering in production either. The closest Google has come in Gboard is central differential privacy with secure aggregation added on top, which brought en-US next-word prediction from ρ = 1.31 to ρ = 0.25 at roughly neutral utility but leaves the server trusted with the un-noised aggregate; genuine distributed differential privacy over secure aggregation it deployed in Android's Smart Text Selection instead, where the reported guarantee was a finite ε in the hundreds. So each half is proven separately and the combination at a guarantee worth quoting is not available to anyone as software. It costs O(d log m) bits in total and matches central-model accuracy with fewer than 16 bits of precision per value (Kairouz, Liu and Steinke), and it remains the cleanest illustration in this series of the distance between a correct paper implementation and adoptable software.

No general-purpose multi-party computation framework trains a modern model at a cost anyone would pay. The distinction matters, because the two protocols above are multi-party computation and they do work: what fails is evaluating the whole training computation under secret sharing rather than one fixed function over the participants' inputs. MP-SPDZ is genuinely healthy — version 0.4.3 of July 2026, with BERT functionality added to its compiler — but that is inference scale, and it is a general-purpose framework you build against rather than a training system. CrypTen, still the most-cited multi-party-computation library in write-ups on this subject, was archived by Meta on 13 May 2025 and had already disclaimed production readiness in its own README. SecretFlow and SPU are real, with deployments in Chinese finance, and their cadence has slowed through 2026. The costs are the decisive part. Keller and Sun report 99.2% MNIST accuracy in 3.5 hours with three-party honest-majority computation, at 343 seconds and 352 GB of communication per epoch for LeNet, while dropping to the two-party semi-honest setting costs 3,741 seconds and 1,128 GB per epoch for a network far smaller than LeNet. Piranha, with GPU acceleration, ran VGG-16 on CIFAR-10 in about 33 hours with 17.2 TB of communication, and its own README states it is an academic proof-of-concept that has not received careful code review and is not ready for production use, quoting roughly 30 hours per training run on a network the size of VGG-16 and more than 270 computation-hours to replicate its figures on instances costing about $450 a day. A 2026 cross-framework benchmark found runtime differences of more than an order of magnitude between frameworks running the same protocols, and concluded that state-of-the-art frameworks are ready for widespread adoption on the workloads it tested — which were inference and analytics rather than training. Two qualifications in that paper matter here: dishonest-majority protocols run roughly one order of magnitude slower than honest-majority ones, and neural-network inference under a dishonest majority is not feasible within a realistic time frame (Harth-Kitzerow et al.). And every one of those numbers is conditional on a corruption threshold. If the three independent compute nodes are three virtual machines in one cloud region under one operator's control, the honest-majority assumption is fiction. That is the most under-examined claim in commercial pitches.

Training under homomorphic encryption does not exist as a product. The closest shipping thing is Concrete ML's encrypted training, which its own documentation limits to logistic regression at 6-bit precision, explicitly not neural networks, and which states that training does not currently support client-server deployment and is slower than training on clear data.

Client attestation of the distributed model is missing everywhere, and it is the control that would close the malicious-server group. NVIDIA FLARE's confidential federated AI comes closest: under the Azure model participants can verify that the federated server runs in a genuine confidential virtual machine. That is environment attestation, not payload attestation. A client learns that the aggregator runs in a genuine enclave with an approved container policy; it does not learn that the weight tensor it just received is the honest aggregate rather than one carrying an imprint module or trap weights. A malicious-but-attested workload inside a genuine enclave defeats it. No maintained framework implements signed model manifests, client-verifiable commitments to distributed parameters, or cross-client transcript comparison — searches return academic papers and no shipped feature. The precise claim: no maintained federated-learning framework lets a client verify that the model it received is the honest aggregate.

Parameter-consistency validation across clients is the same gap in a different guise, and equally absent. Nothing verifies that all clients received identical weights. FLARE's own documentation raises the opposite concern — that in one-to-many distribution, in-place filter mutation can make the object sent to the second recipient differ from the first — and treats it as a correctness hazard to avoid rather than a property to verify. The research literature on the topic detects malicious clients, not a malicious server distributing divergent models.

Contribution accounting has nothing maintained at all. OpenDataVal has not released since November 2023; the one Shapley-for-federated-learning package on PyPI is a single-author 0.1.0 untouched for four years; shapiq is excellent and is general-purpose feature attribution, not client-contribution accounting. No federated framework ships it. That is a commercially important hole, because consortia need contribution accounting to settle revenue and access, and the only published cryptographic answer — Cerebro's input commitments, which enforce policy before release and can identify which party injected bad data (Zheng et al.) — has no maintained distribution.

Defenses against feature-space hijacking in split learning are absent while the attack is not. Split learning itself is available, as an example in NVIDIA FLARE and as SplitRec in SecretFlow. Pasquini et al.'s attack has public code you can clone. Every defense is a 2024–2026 paper with no framework integration. The asymmetry is the story.

Federated synthetic data does not exist. Every maintained synthesizer is single-site, so each party synthesizes locally and the synthetic sets are pooled — a workflow, not a protocol, with no joint-distribution modeling. It is also the weakest option on its own merits: Stadler et al. found non-differentially-private synthetic data fails to protect outliers, with one target on the Texas dataset showing privacy gain close to zero, that which records remain vulnerable varies unpredictably across generator types, and that differentially private synthesizers' original implementations violated their own formal guarantees by learning metadata directly from the input. Utility cost was severe, with classifier accuracy falling from 72.2% on raw data to 62.0% at ε = 10, and the synthetic data suppressed the statistical signal of the protected records — destroying exactly the minority-subgroup utility a consortium usually wants.

These are taken up again later.

References

「CODAS Community」へのご参加・ご登録について

一般社団法人AIデータ主権共創機構（CODAS）では、「Privacy-First AI」基盤の構築と持続可能なAIエコシステムの発展に向け、研究者・エンジニア・法務・政策・ビジネス・市民など、立場を越えてオープンに集い、秘匿AIの未来を共に創る共創プラットフォーム「CODAS Community」のメンバーを募集しています。

■ 法人企業様のご参画

CODASの理念や取り組みにご賛同いただき、AIエコシステムの社会実装や標準づくり、共創プロジェクトを共に推進していただける法人企業様を募集しております。ご入会や連携に関するお問い合わせ・お申し込みは、下記フォームより承っております。

お問い合わせフォーム：https://codas-ai.org/contact

※件名に「会員の申込」とご明記のうえ、貴社の簡単なご紹介（事業内容等）を添えてご連絡ください。確認後、担当者よりご案内いたします。

■ 個人・一般の皆様のご参加

公式Discordおよびメールマガジンでは、勉強会・ワークショップ・ミートアップ等のイベントへの優先アクセスや、秘匿性技術・ルール標準化に関する最新の知見をお届けします。東京のリアル拠点での交流も含め、立場を問わずどなたでもご参加いただけます。

CODASについて

一般社団法人AIデータ主権共創機構（CODAS）は、「安全・安心なAI社会」の実現を目指す非営利・中立の法人です。データプライバシー技術の研究開発と、そのオープンソース化による社会実装を推進しています。データを外部に出さずにAIを高度活用できる「Privacy-First AI」基盤を「創る・使う・広げる」ことを基本理念に掲げています。

≪本件に関するお問い合わせ先≫

一般社団法人AIデータ主権共創機構（CODAS）イベント事務局 E-mail：info@codas-ai.org