Skip to content

SYSTEM Cited by 1 source

Confidential Federated Compute

What it is

Confidential Federated Compute is Google's next-generation Federated Learning system that provides externally verifiable, hardware-rooted data-anonymization guarantees by running the entire training loop server-side inside attested Trusted Execution Environments (TEEs). It replaces the earlier client-side-aggregation FL design (powered by TensorFlow Federated) and is named after its open-source google-parfait/confidential-federated-compute GitHub repository, from which its KMS and data-processing binaries are reproducibly built. Gboard is the first production adopter. (Source: sources/2026-10-02-google-toward-provably-private-learning-from-federated-data)

It builds on Google's earlier confidential federated analytics and "provably private insights" work — the aggregation-direction siblings — and extends the same TEE + attestation + transparency-log family to model training.

The four coordinated operational concepts

(Source: sources/2026-10-02-google-toward-provably-private-learning-from-federated-data)

  1. Data upload. Client devices locally encrypt training examples and upload them. Each device pre-authorizes an access policy — the set of TEE computations allowed to process its data — and these computations only release anonymized results. Access policies must be published to a public transparency log (Rekor).

  2. KMS and policy verification. The Key Management System (KMS) is a cluster of TEEs implementing the RAFT consensus protocol. It gives decryption keys only to server-side TEE workloads whose attested measurement matches the computations named in the access policy.

  3. Workload execution. A root data-processing TEE executes a Python program implementing the training loop and delegates parallelizable subtasks to a cluster of worker TEEs. Distributed logic is written in Federated Language (open-source, framework-agnostic, derived from TensorFlow Federated). The loop periodically releases differentially private model weights to the data analyst.

  4. Fault-tolerant recovery. The Python program saves KMS-encrypted recovery state at the end of each training round (see confidential storage inside the TEE), allowing recovery from intermittent root/worker failures without leaking additional privacy-sensitive information.

End-to-end flow

Client devices
   │  locally ENCRYPT training examples
   │  pre-authorize ACCESS POLICY (allowed TEE computations)
   │  require policy published to Rekor (transparency log)
   ▼
[ Rekor transparency log ] ◄── external auditors watch allowed workloads
   │
   ▼ encrypted uploads (decryptable only briefly, only by policy-named TEEs)
┌──────────────────────────────────────────────────────────────┐
│ KMS = cluster of TEEs running RAFT                             │
│   releases decryption keys ONLY to attested workloads whose    │
│   measurement matches the access policy                        │
└──────────────────────────────────────────────────────────────┘
   │ keys
   ▼
┌──────────────────────────────────────────────────────────────┐
│ ROOT data-processing TEE (runs Python training loop)           │
│   ├─ delegates parallel subtasks ─► WORKER TEE cluster         │
│   ├─ periodically releases DP model weights  ─► data analyst   │
│   └─ saves KMS-encrypted recovery state (fault tolerance)      │
└──────────────────────────────────────────────────────────────┘
   │
   ▼ Only metrics + differentially-private model weights leave the boundary.

Verifiability mechanisms

  • Public transparency log. Access policies describing the allowed server workloads are published to Rekor; external auditors observe the log to track the full set of workloads devices could participate in. (Source)
  • Reproducible builds. KMS and data-processing binaries are reproducibly built from the open-source confidential-federated-compute repo, tying the attested measurement back to auditable source. (Source)
  • Dynamic sideloading. Access policies on Rekor directly describe the Python training program. To protect proprietary model architectures / preprocessing while preserving auditability, data-processing TEEs can sideload serialized information into the Python program at runtime — permitted only while all privacy-relevant logic stays hardcoded in the published program. (Source)

Why it strengthens privacy over earlier FL

In earlier FL, device data was uploaded for immediate aggregation with no way for external observers to verify it was never logged or inspected. Secure Aggregation later protected uploads cryptographically but was incompatible with state-of-the-art central DP (MF-DP-FTRL). Confidential Federated Compute is positioned as "the next milestone in the ongoing effort to completely remove the need to trust the server operator": encrypted device data can be decrypted and processed only inside attested, policy-named Python training TEEs, for a limited time after upload, and only DP weights and metrics are visible to operators. (Source: sources/2026-10-02-google-toward-provably-private-learning-from-federated-data)

Performance impact

Shifting gradient computation from device to server removed the dominant FL bottlenecks. Collecting all uploads before running the workload eliminates diurnal device-availability variation; the optimal device-participation schedule and DP parameters are computed dynamically at execution time. Training that previously took 1–2 months per model (limited by device availability, on-device compute, and cross-workload device contention) is now substantially faster, bottlenecked only by TEE resource availability, via parallelization across many worker-TEE machines. Gboard launched English and Japanese next-word-prediction models on the system with stronger privacy and improved accuracy. (Source)

Relation to other wiki systems

Caveats

  • Subject to current-generation TEE limitations and side-channel risk; the verifiable-privacy guarantee holds "subject to current-generation TEE limitations."
  • Dynamic sideloading is a controlled escape hatch — safe only while all privacy-relevant logic remains in the published program.
  • Formal proofs are future work. The post is "a step toward rigorous proof"; full proofs of correctness of the DP-algorithm implementations and system components are aspirational.
  • No DP budgets (ε/δ), KMS/worker cluster sizes, or latency numbers disclosed; malicious-client / data-poisoning defenses not discussed.

Seen in

Last updated · 771 distilled / 2,233 read