Google Moves Gboard’s Federated Training Into Attested TEEs With Publicly Logged Privacy Rules
Google Research says its new federated learning system runs training inside attested server-side TEEs, publishes the allowed workloads to a public transparency log, and has already trained Gboard English and Japanese models with a privacy budget about three times smaller.
Google Research has moved the core of its federated learning stack off phones and into Trusted Execution Environments (TEEs) on its servers. It says the result is the first federated learning system whose central differential privacy guarantees outsiders can verify. In an October 2, 2026 post, Katharine Daly and Research Director Daniel Ramage said Gboard has already adopted the system to launch English and Japanese next-word prediction models. The design is described in a paper, “Toward provably private learning from federated data” (arXiv:2609.31494). It is built on TEEs backed by AMD SEV-SNP and Intel TDX, which can be remotely attested, keep their internal state confidential, and protect the integrity of the code they run.
From trusting the operator to checking the code
Federated learning, which Google introduced in 2017, trains models on data that stays spread across devices. It powers Gboard next-word prediction and Smart Compose, reply suggestions in Google Messages, and Smart Text Selection on Android. Earlier versions aggregated uploads right away, and outside observers had no way to confirm the server never logged or inspected them. Secure Aggregation later protected uploads cryptographically, but Google says it could not be combined with state-of-the-art central differential privacy. That left users trusting Google to add the right noise.
The new system replaces that trust with checks. Each device encrypts its training examples locally and pre-authorizes an access policy, which lists the server-side computations allowed to touch the data. Devices require those policies to be published to Rekor, a public transparency log, so auditors can see every workload that could ever process the uploads. A key management service runs as a cluster of TEEs using the Raft consensus protocol. It releases decryption keys only to TEE workloads that match an approved policy. Only metrics and differentially private model weights leave the enclave.
Google says the KMS and data-processing binaries can be reproducibly built from code in its Apache-2.0 Confidential Federated Compute repository on GitHub. Distributed training logic is written in Federated Language, an open-source orchestration language derived from TensorFlow Federated. A “root” TEE runs the Python training loop and hands parallel work to worker TEEs. Encrypted recovery checkpoints let a job survive machine failures without leaking extra information. To protect proprietary model architectures, operators can sideload serialized logic at runtime. Google says the guarantees hold as long as all privacy-relevant code stays hardcoded in the audited program, subject to current TEE limits such as side-channel observation.
What Gboard measured
Collecting all uploads before training starts removes the old dependence on when phones happen to be idle and charging. For a Japanese model, the paper reports that the previous system ran 3,000 rounds over 38 days and incorporated 8.5 million of 35.5 million available devices, about 23.9%. The TEE system gathered 17.8 million uploads in about six days, and all of them went into the training run that was later launched.
The privacy gains are just as concrete. An English model on the old system needed a noise multiplier of 7.38 and more than 8,600 rounds over 85 days. On the TEE system, Google targeted a zCDP privacy budget of 0.232 at 5,000 rounds and needed a noise multiplier of 5.16. By the paper’s figures, the old system would have needed 9.54 for the same budget. In a live A/B test with 3.5 million devices per arm, the best TEE-trained arm used a privacy budget of 0.215, against 0.641 for the production model after adjusting for the same MF-DP-FTRL mechanism. That is roughly three times smaller, with neutral results on Words Per Minute and Words Modified Ratio. That model trained in three weeks, compared with two months for its predecessor. Google says compute time is now limited mainly by available TEE capacity.
Limits and what comes next
The paper is open about scale. So far the system has trained models of up to 10 million parameters. Larger models will likely need GPU-equipped worker TEEs and fixes for communication bottlenecks between root and workers. Google says that moving gradient computation to the server lifts the old on-device compute ceiling, and that integrating TEEs with accelerators will be central to training bigger models this way.
The infrastructure also is not limited to federated training. Google says it can run any Python workload verifiably, and the team is experimenting with synthetic data generation and with pairing these enclaves with TEEs that specialize in LLM inference. The authors expect future TEE hardware and side-channel research to strengthen protection for dynamically loaded code.
For teams building on-device AI products, the takeaway is architectural. Privacy promises about training data can now come with an audit trail anyone can check: a published policy, attested binaries, and a public log of which code is allowed to run.
- #Federated Learning
- #Differential Privacy
- #Google Research
- #Confidential Computing
- #AI Infrastructure
Author
Raj M
Contributor
AI Systems Architect is a seasoned technology leader with over 15 years of experience in the IT industry working with Fortune 500 companies. With a solid foundation in multi-agent systems, open-source LLM infrastructure, and enterprise deployment, he excels at building scalable production-grade AI platforms.