Google puts federated learning inside TEEs so outsiders can verify the privacy math

Google Research said Friday it shipped a next-generation federated learning system that runs training inside Trusted Execution Environments so device data stays encrypted except inside attested code, with access policies published to a public transparency log — and Gboard is already using it for English and Japanese next-word prediction.

Federated learning was sold as “your phone keeps the data” while the server still had to be trusted for the aggregation. Google is now putting the training loop inside attested TEEs and publishing the access policy to a public log — and shipping it on Gboard — so auditors can check what code was allowed to touch the uploads instead of taking Google’s word for it.

On Friday, 2 October 2026, Google Research announced a new federated learning system that uses Trusted Execution Environments so an outsider can check the privacy guarantees. The post is titled “Toward provably private learning from federated data.” The byline is Katharine Daly, software engineer, and Daniel Ramage, research director. The page dates the post October 2, 2026. It does not print an hour. Federated learning is a way to train a shared model from examples that start on many phones, instead of pooling a raw copy in one database. A Trusted Execution Environment, shortened to TEE, is a locked area of a chip. Code inside it can prove what it is. The chip is supposed to stop outsiders from reading that memory or changing the program. Those lines are Google Research’s.

What the older system already powered. In 2017, the post says, Google introduced federated learning and used it for next-word prediction and Smart Compose on Gboard, reply suggestions in Google Messages, and Smart Text Selection in Android. Gboard is the keyboard on Android phones. The post says the work follows four privacy principles: collect less, anonymize what you do collect, tell people what is happening and give them a choice, and make the protections something an outsider can check. Years of work on anonymization, it says, produced strong differential privacy for models that actually ship. Differential privacy means the result that leaves the system has noise in it, so one person’s examples are hard to pick back out. Those lines are Google Research’s.

What the new system is for. Google says this generation uses TEEs to make the anonymization verifiable and auditable from outside. Logic that runs in a TEE is remotely attestable: a third party can check which code is running. The TEE also provides confidentiality, so its internal state is not supposed to be observed, and integrity, so the program is not supposed to be disrupted. The post says those protections hold subject to the limits of current-generation TEEs. Google says it is taking properties that one machine can offer and building them into a full training system, with stronger privacy guarantees and improved accuracy. Gboard, it says, has already adopted the system and is seeing substantially faster compute than the previous one. Those lines are Google Research’s.

How a phone sends an example. The device encrypts the training example locally and uploads it, tagged with an access policy. That policy is the set of TEE computations allowed to process the data, and those computations are supposed to release only anonymized results. The phone will not participate unless the policy has been published to a public transparency log. Google names that log Rekor. An auditor can read the log and see the full set of server-side workloads a device might be joining. Those lines are Google Research’s.

Who is allowed to unlock the upload. A Key Management System holds the decryption keys. Google says it is a cluster of TEEs that keep one shared record. It releases a key only to a server-side TEE workload that matches the computations in the access policy. A program that is not on that list does not get the key. Those lines are Google Research’s.

What the people running the job can see. Google says only metrics and differentially private model weights are visible to workload operators. A model weight is a number the model learned. Differentially private, here, means noise was added before that number left the locked room. The encrypted training data can be decrypted and processed only inside TEEs running the Python training programs named in the access policy, and only for a limited time after the upload. Those lines are Google Research’s. The post does not print how many hours that window lasts.

Where Gboard is using it. Gboard has deployed the system to launch English and Japanese next-word prediction models, with stronger privacy guarantees and improved accuracy, and with substantially faster compute than the previous federated learning system. Those lines are Google Research’s. The post does not print a percentage-point gain for accuracy.

Why a round no longer waits on the phone. In the past, training these models could take one to two months each. Progress was limited by whether a phone was available, by the compute on the phone, and by several training jobs competing for the same phones. The new design collects the uploads first, then trains on the server, so the time of day a phone is plugged in no longer sets the pace. Bottlenecks move to the server, and the work is split across many machines. Google says the speedup is currently limited by how many TEE machines are free. Those lines are Google Research’s.

What the chart is measuring. The figure is titled “Improving Privacy-Utility Curves.” The vertical axis is the noise multiplier. That is how much random noise is added. More noise hides one person more thoroughly, and it usually makes the prediction less accurate. The horizontal axis is the differential privacy budget, written as zCDP ρ. A smaller budget is a tighter privacy promise. The red curve is the previous system. The blue curve is the new TEE-based system. The figure marks a noise multiplier of 7.38 on both curves: the new system at a privacy budget of 0.113, and the previous system at 0.388. An arrow between those points is labeled “Improve Privacy.” At the same budget of 0.388, the new system’s noise multiplier is 3.99, against 7.38 on the old curve. An arrow down to that point is labeled “Improve Accuracy.” The caption says the curves come from an English next-word model trained for 5000 rounds, with cohorts of 6500 devices, on both systems. A cohort is the batch used in one round. Google says the new system can buy a stronger privacy guarantee, a smaller noise multiplier, or both, by choosing a participation schedule inside the program instead of waiting on which phones happen to be awake. Those figures are the labels and the caption on Google Research’s chart.

What an outsider can rebuild. Google says the key-management and data-processing programs can be reproducibly built from open-source code in the Confidential Federated Compute repository. Reproducibly built means another person can compile that source and get the same program the phones are trusting. Devices know the full set of server workloads that may touch an upload, because the access policies are on the public log. Those policies describe the Python program that runs the training, so an auditor can read the program that is allowed to see the data. Google also says a TEE can load extra information into that program while it runs, so a proprietary model shape or a preprocessing step can stay private, as long as the privacy-relevant logic stays written in the program an outsider can read. Those lines are Google Research’s.

What Google says is still ahead. The post calls this a step toward a rigorous proof that processing on the server preserves a person’s privacy. With outside verifiers able to inspect the code, Google says it can offer strong assurances that the data is processed as described. It also says current-generation TEEs have limits. It expects future TEE hardware, and research on side-channel observations, to give deeper protection when extra data is loaded at runtime, including against a malicious server. A side channel is a leak that comes from timing, power, or another indirect measurement, rather than from reading the file itself. Google says systems like this may one day ship with full proofs that the privacy software is correct. The post calls the TEE system the next milestone in an ongoing effort to remove the need to trust the operator of the server. The proof, and the side-channel work, are described as future work. Those lines are Google Research’s.

The picture is that chart, in a magenta frame. The title reads Improving Privacy-Utility Curves. The legend names the previous system in red and the new TEE-based system in blue. The frame does not print a calendar date. It is the curves figure from the research post. It is not a photograph of a phone or a server room.

In plain terms, Google Research said on Friday that Gboard’s English and Japanese next-word models are training on a system that keeps each upload encrypted until it is inside attested code, publishes the list of allowed programs to a public log, and shows operators only the noisy model and the metrics. Jobs that used to take one to two months move to the server, where the work can run in parallel, and Google says they finish substantially faster, up to the number of TEE machines on hand. The chart says the same amount of noise can come with a tighter privacy budget, or the same budget can use less noise. Google says today’s TEEs still have limits, that side channels are unfinished research, and that a full proof of the software is still ahead.