Google Research has announced a next-generation federated learning system built on Trusted Execution Environments, and the team is making a claim that would have been dismissed as unreachable a few years ago: externally verifiable central differential privacy guarantees for federated learning, for the first time. The system, which is being applied to Gboard, replaces a long-standing "trust us" arrangement with cryptographic attestation and public logs that outside auditors can actually inspect. For ongoing coverage of privacy-preserving machine learning, follow our latest AI developments.
The trust gap in federated learning
Federated learning, which Google introduced in 2017, was supposed to solve a specific problem: how to train useful models on user data without collecting that data centrally. Instead of uploading raw typing behavior to a server, devices compute model updates locally and contribute only those updates. The approach quietly powers a remarkable amount of what users touch every day — next-word prediction and Smart Compose in Gboard, reply suggestions in Google Messages, and Smart Text Selection in Android.
But the original architecture had a trust gap at its center. Devices uploaded their data for immediate aggregation, and outsiders had no way to verify that the data was never logged, retained, or inspected along the way. Users had to take Google's word for what happened server-side. Later, Secure Aggregation added cryptographic protection so that individual contributions could not be read in isolation — but that technique was not compatible with state-of-the-art central differential privacy algorithms such as matrix factorization DP-FTRL, and it still left one assumption untouched: Google had to be trusted to add the differential privacy noise correctly. A misconfigured noise parameter would be invisible to everyone except the company making the mistake.
How the new system works
The new design attacks the trust assumption directly. It moves client gradient computation to the server — inside a Trusted Execution Environment — and then makes that server logic attestable, so the operator no longer needs to be trusted at all. A TEE is a hardware-isolated processor enclave whose running code can be cryptographically verified by outsiders; if the enclave does something other than what it claims, the attestation breaks.
According to Google's announcement, the system coordinates four core components. First, data upload: devices encrypt training examples locally and pre-authorize an access policy that lists exactly which TEE computations may process the data — and those policies must appear in a public transparency log. Second, a Key Management System built from TEEs running the RAFT consensus protocol releases decryption keys only to workloads that match the published policy. Third, workload execution: a root TEE runs a Python training loop and delegates subtasks to worker TEEs, with orchestration handled by a system called Federated Language, derived from Google's TensorFlow Federated framework. Only differentially private model weights are ever released from the enclave. Fourth, fault-tolerant recovery: each training round saves a KMS-encrypted recovery state so that root or worker failures do not destroy in-progress training.
Why the guarantees can actually be checked
The verifiability claim rests on a chain of public evidence rather than corporate attestation. Access policies are published to Rekor, Sigstore's public transparency log, so external auditors can track every server workload that a device's data could possibly feed. The KMS and data-processing binaries are reproducibly buildable from open-source code, meaning anyone can compile the published source and confirm it matches the binaries running in production.
The policies themselves directly describe the Python training program, which closes the most common loophole in privacy architectures: a gap between what a privacy policy says and what the code actually does. To protect proprietary model architectures, the TEEs do support sideloading serialized logic at runtime — but with a hard constraint that all privacy-relevant logic must stay hardcoded in the attested program. Workload operators, including Google's own infrastructure staff, see only metrics and differentially private model weights. Encrypted data can be decrypted only for a limited time after upload, bounding the window in which anything at all could be inspected.
From promises to evidence
The significance of the design is less any single component than the shift in burden it produces. Privacy guarantees in machine learning have historically been framed as promises backed by policy documents, internal audits, and the operator's reputation. This system converts those promises into artifacts — attestation reports, transparency-log entries, reproducible builds — that a skeptic can verify without access to Google's internals.
It also marks a notable convergence of two research communities that have mostly worked in parallel. Trusted execution environments and differential privacy solve different problems: TEEs restrict who can compute on data, while DP restricts what any computation can leak. Combining them under a single attestable program, with the DP noise generation itself inside the verified enclave, addresses the residual weakness of each approach in isolation.
For now the system is running in Google's own stack, powering training workloads of the kind Gboard performs. Whether verifiable privacy becomes a competitive expectation across the industry — the way HTTPS did after transparency logging was standardized for certificates — will depend on whether users and regulators start asking other AI providers the question this system is designed to answer: prove it.
---
Stay Ahead of AIGet the latest AI news, analysis, and breakthroughs — all in one place.
Read more AI news →
