AI Affairs, home

Thursday 24 September 2026

Technology

Google DeepMind adds persistent server-side memory to Private AI Compute

The update makes the platform stateful while keeping encryption keys on user devices, so Google cannot read stored context, enabling cross-device AI continuity.

Rows of server racks in Amravati Data Center
Photo: PiDatacenters, CC BY-SA 4.0, via Wikimedia Commons (cropped)

Google DeepMind announced on 23 September 2026 that its Private AI Compute platform will gain a persistent, server-side memory layer that runs inside hardware-enforced secure enclaves while cryptographic keys remain exclusively on users’ personal devices, a design the company says keeps stored data inaccessible even to Google the company said.

Key points

  • Private AI Compute, launched in November 2025, was strictly stateless; the new memory layer adds cross-device, cross-session continuity.
  • User data is encrypted in per-user databases; decryption keys are derived from and held only on the user’s devices.
  • The stateful “memory Oak Server” runs in a hardware trusted execution environment, written in Rust on the Oak Containers runtime.
  • Independent auditors validated the system design for both the 2025 launch and the 2026 memory update; summaries are published.
  • Key release is gated on hardware attestation of the enclave’s measurement; modified or unauthorised builds cannot obtain keys.

From stateless inference to a persistent vault

Private AI Compute debuted on 11 November 2025 as a platform that paired Gemini cloud models with the privacy assurances of on-device processing, running on custom Tensor Processing Units secured by Titanium Intelligence Enclaves. Until this update, the platform was strictly stateless: every request was handled in an isolated enclave and all context was wiped the moment the task ended. Google acknowledged that having the model retain catalogues of individual details and user choices fell short of delivering the ongoing continuity it envisions for personal AI.

The fresh memory layer operates as a protected digital vault hosted in the cloud. Data that helps the assistant is locked inside per-user encrypted databases, and the keys that open them never leave the owner’s devices. When the model requires stored context, an end-to-end encrypted link joins the user’s hardware to a shielded cloud enclave. The enclave unseals the data in volatile memory, records fresh context, then encrypts it again without delay.

Memory Oak Server and the request lifecycle

The revised Private AI Compute Technical Brief, authored by Google DeepMind alongside the Platforms & Devices, Core and Cloud groups, characterises the capability as a stateful addition to the platform. At its core is the memory Oak Server, a per-user database running inside a hardware trusted execution environment. Per-user keys encrypt each record, and the brief states those keys remain inaccessible beyond the trusted computing boundary or to Google’s own systems. A coordination layer sits between the model and the memory store, ensuring unencrypted data stays confined to the enclave. The memory application is written in Rust and runs in the Oak Containers runtime; both the server and the runtime are open source. Reproducible builds link the published source code to the running binaries, and their hashes are recorded in a public ledger that the enclave verifies before handing over any key.

For a request requiring historical context, the client establishes an encrypted session via the Noise Protocol; the request reaches an orchestration enclave inside an AMD SEV-SNP confidential virtual machine. The coordination layer establishes a mutually verified ALTS connection to the memory store; once the enclave’s measurement passes hardware checks, the user’s keys are provided to the database engine and the matching records are decoded solely in temporary enclave memory. The fetched context combines with the current input and is processed completely inside the fortified TPU platform. Should the session generate fresh memories, facts or revised preferences, they are encrypted with the user’s key and committed to long-term storage, while all temporary prompt context, tokens and intermediate activations are erased once the answer is sent.

Threat model shifts with persistence

The brief acknowledges that retaining data changes the platform’s security posture. Because a persistent store must match each request to a fixed per-user ID, the stateful system drops the guarantee that no individual query can be tied to a user on the stateless path. Google states that aiming at a particular user’s memory returns only unreadable encrypted data, since the keys capable of deciphering it exist solely within a verified enclave. Declared aims for the persistent store encompass blocking any internal route to readable user data even during emergency access, isolating a breached instance via confidential virtual machines, and egress rules that block monitoring, logging and core dumps by default.

Bringing up step-by-step guides on a notebook that were earlier seen via wearable displays, or picking up an involved dialogue across phone and browser, would become possible because the context required for continuity lives in the cloud yet stays readable only inside a verified enclave using keys that remain on the user’s hardware.

Independent audits and a transparency log co-signed by third parties

Google says external auditors validated the system design for both the initial 2025 release and the 2026 server-side memory update, and it has published summaries of both audit reports. Devices running Private AI Compute will be able to verify that the server software is authentic and unaltered against a public record before sending any personal data. The brief outlines coming work: device-side attestation checks so user hardware can confirm server proofs before sending private data, a public log watched and countersigned by outside parties, wider reproducible build coverage for more components, and regular third-party audits.

Topics: Inference, Safety