Google moves federated learning into attested server enclaves

Google has deployed a federated-learning stack that uploads locally encrypted training examples and computes model updates inside server-side Trusted Execution Environments, or TEEs. According to its technical post, the system now trains Gboard’s English and Japanese next-word prediction models.

Google’s original federated-learning architecture kept training examples on each phone. Devices computed model updates locally, and Secure Aggregation prevented the server from inspecting individual updates before combining them. The approach reduced central access to user data, but phone availability and compute limited training, while external auditors had little evidence about the server software applying privacy protections.

The new stack moves the confidential boundary from the phone into attested server hardware. Devices still supply decentralized data, while encrypted examples now leave the device. A key-management service releases decryption keys only to approved TEE workloads, and those workloads apply differential privacy before model weights leave the enclave.

Five stages enforce each access policy

1. Encrypted upload: A client encrypts its training examples locally and associates them with an access policy. The policy identifies which confidential workloads may process the data and can limit how long access remains valid.
2. Public registration: Workload policies are published to Rekor, a public transparency log. Auditors can inspect the set of declared computations that devices may join.
3. Attested key release: A key-management service runs across a cluster of TEEs using the Raft consensus protocol. It releases decryption keys only after attestation shows that the requesting workload matches an authorized policy.
4. Confidential execution: A root TEE runs the Python training loop and delegates parallel work to worker TEEs. Google orchestrates these jobs with Federated Language, an open-source descendant of TensorFlow Federated.
5. Protected recovery: The program saves key-management-service-encrypted recovery state after each training round. A replacement workload can resume after a failure without exposing an additional plaintext checkpoint.

Attestation narrows the trust surface

A TEE provides remote attestation, confidential memory, and execution integrity. Remote attestation lets another system verify the identity and configuration of code running inside supported hardware. Confidentiality hides the workload’s internal state from the host, while integrity controls prevent the host from silently modifying execution.

Google connects those machine-level properties to a public audit trail. The key-management and data-processing binaries can be reproducibly built from the Confidential Federated Compute repository. An auditor can rebuild the software, compare its measurement with the attested workload, inspect its access policy in Rekor, and review the Python code that clips contributions, adds noise, and controls outputs.

Runtime sideloading allows proprietary artifacts, including model parameters, tokenizers, and serialized architecture details, to enter the confidential workload without appearing in the public source tree. The audited Python program still governs data access and release. This arrangement exposes the privacy control flow while allowing model intellectual property to remain closed.

Gboard swaps handset delays for enclave capacity

Gboard previously had to wait for eligible phones, typically devices that were idle and charging. Training progress varied with time zones, device availability, local compute, and competition among jobs requesting the same handsets. The new architecture collects encrypted uploads first, then schedules training across server-side TEEs when capacity is available.

The previous Gboard models could take one to two months to train. Google reports substantial speedups from server parallelism, although its post does not provide a new end-to-end training time. TEE availability now sets the throughput ceiling.

Central differential privacy also becomes easier to enforce inside the confidential workload. The program can bound each device’s contribution and add calibrated noise before releasing model weights. This limits how much any single device can influence the output, with the privacy budget controlling the strength of that bound.

For an English next-word prediction benchmark, Google trained for 5,000 rounds with cohorts of 6,500 devices. Its reported privacy-utility curves show less model-quality loss at a given privacy target than the previous system.

The guarantee stops at several boundaries

• Side channels remain: Current TEEs can leak information through timing, cache behavior, memory-access patterns, and other side channels. Google acknowledges that the hardware does not eliminate these attack classes.
• Hardware roots stay trusted: Attestation depends on the processor vendor, its signing infrastructure, firmware, and the security of the enclave implementation.
• Closed artifacts limit review: Auditors can inspect the privacy logic but may be unable to examine sideloaded model components. A valid attestation confirms which measured program ran, not whether every closed input is safe or correct.
• Differential privacy needs sound parameters: Enclaves can enforce a configured mechanism, but the protection still depends on clipping bounds, noise levels, sampling assumptions, and privacy accounting.
• Capacity moves to the data center: Training speed depends on available confidential-computing hardware. Support for GPUs and TPUs remains less mature than CPU-based TEE execution, especially for large deep-learning workloads.

Two repositories expose the building blocks

Google has released the confidential-computing components and the Federated Language orchestration framework as open source. The announcement does not include a public managed service or API that developers can use to run the complete Gboard infrastructure.

Components required for a similar deployment

• Clients that encrypt uploads and authorize explicit access policies
• A public, append-only transparency log
• Reproducible enclave binaries and published source code
• An attestation-aware key-management service
• Confidential workloads that enforce contribution limits and differential privacy
• Encrypted checkpoints that preserve privacy during recovery
• Auditing tools that connect source code, binary measurements, policies, and attestations

Confidential accelerators set the next ceiling

Moving model computation into server-side enclaves removes the memory, power, and runtime limits imposed by phones. Larger architectures become feasible as confidential accelerators gain stronger isolation, attestation, and integration with key-management systems.

Google also describes the infrastructure as a general Python execution environment and is experimenting with workloads such as synthetic-data generation. The same policy, attestation, and controlled-release design could support confidential analytics or model inference over sensitive user data.

For developers handling private datasets, the reusable design lies in the connection between client-approved policies, public logs, reproducible builds, attested execution, restricted key release, and differentially private outputs. Each component supplies evidence about who can process encrypted data, which program receives it, and what information may leave the confidential boundary.