Google Brings Persistent Server-Side Memory to Private AI Compute

Google will bring private, persistent server-side memory to Private AI Compute, its cloud AI processing platform, the Google Private AI Compute Team announced in a Google DeepMind blog post published September 23, 2026, releasing an updated technical brief, a public record of its server software, and summaries of independent audits alongside the announcement.

A Secure Vault Model With Device-Held Keys

The team said the new persistent memory layer is designed to function like a secure digital vault in the cloud. Under this model, information needed to assist a user is sealed within dedicated, encrypted storage, while the cryptographic keys required to unlock it are held exclusively on the user’s personal devices — an arrangement Google says makes the data inaccessible to anyone else, including Google itself.

When a model needs stored information to handle a request, an authenticated, end-to-end encrypted channel connects the device to a protected, isolated environment in the cloud. That space, called a secure enclave, temporarily decrypts the data in isolated memory, saves any new context, and immediately re-encrypts it. Google describes the design as combining hardware-enforced secure enclaves, encrypted channels, and per-user databases shielded by device-derived encryption keys.

The announcement frames the capability as an answer to a longstanding dilemma: giving an assistant long-term continuity across devices while upholding the strict privacy standards typically limited to on-device processing. As examples of the intended continuity, the team describes pulling up assembly instructions on a laptop that were previously viewed through smart glasses, or resuming a complex conversation between mobile and web.

From a Stateless Platform to Persistent Memory

Google introduced Private AI Compute on November 11, 2025, in a post by Jay Yagnik, vice president of AI innovation and research, describing it as a platform that combines its Gemini cloud models with the security and privacy assurances of on-device processing. The platform runs on Google’s custom Tensor Processing Units secured by Titanium Intelligence Enclaves. At launch, Google said Private AI Compute would make Magic Cue more helpful on Pixel 10 phones and allow the Pixel Recorder app to summarize transcriptions across a wider range of languages.

Until this update, the technology was strictly stateless, wiping all context the moment a task ended. Google says workarounds, such as having the AI save lists of personal facts and preferences, were not enough to support the continuous experiences it expects from personal AI.

Memory Architecture and Request Lifecycle

The updated Private AI Compute Technical Brief, from Google’s Platforms and Devices, DeepMind, Core, and Cloud teams, describes the feature as a stateful extension of the platform: a persistent, per-user memory that lives in the cloud while remaining unreadable by Google, operating entirely within the platform’s protected execution environment.

At its core is the memory Oak Server, a stateful per-user database running inside a hardware trusted execution environment. Records are encrypted under per-user keys that the brief says are never visible outside the system’s trusted computing base or to Google infrastructure, and an orchestrator mediates between the AI model and the memory server so that plaintext never leaves the enclave. The memory application is written in Rust and runs in the Oak Containers runtime, and both the server and the runtime are open source. Reproducible builds tie the published source to the binaries deployed in production, with the resulting digests publicly endorsed in an append-only ledger and attested by the enclave before any key is released.

For a request requiring historical context, the lifecycle begins with the client establishing an encrypted session via the Noise Protocol; the request then reaches an orchestration enclave inside an AMD SEV-SNP confidential virtual machine. The orchestrator opens a mutually attested ALTS channel to the memory server, and after hardware verification of the enclave’s measurement, the user’s decryption keys are unsealed to the database engine and the relevant records are decrypted strictly in volatile enclave memory. The retrieved context is merged with the active prompt and evaluated entirely within the hardened TPU platform. If the session produces new memories, facts, or updated preferences, they are re-encrypted under the user’s key and written to persistent storage, and all volatile prompt context, tokens, and intermediate activations are wiped upon response delivery.

Key release to the memory server is gated on attestation. According to the brief, an enclave that cannot present valid attestation evidence matching an endorsed memory binary (including a modified or unauthorized build) cannot obtain the keys and therefore cannot read a user’s memory.

Threat Model and External Verification

The brief acknowledges that retaining data changes the platform’s security posture. A persistent store must resolve a stable per-user identifier for each request, so the stateful system does not claim network-level non-targetability, the property intended to keep any single query from being linked to a user on the stateless inference path. Google says targeting a specific user’s memory yields only opaque ciphertext, because the keys needed to read it are available only inside an attested enclave.

Stated security goals for the persistent store include no administrative path to plaintext user data even in break-glass emergency scenarios, containment of a compromised instance through confidential virtual machines, and default-deny egress policies covering monitoring, logging, and core dumps.

Google says external auditors validated the system design for both the initial release and the server-side memory update, and it has published summaries of the 2025 and 2026 audit reports. Devices running Private AI Compute will be able to verify that the software is authentic and unaltered against the public record before sending any personal data, according to the company.

The work was co-developed by Google DeepMind with the Platforms and Devices, Core, and Cloud teams, with Four Flynn, Jay Yagnik, and David Kleidermacher credited for executive sponsorship.

The brief closes with planned next steps: client-side attestation verification that would let user devices independently validate server evidence before transmitting sensitive data, an append-only transparency log observed and co-signed by independent third parties, broader reproducible build coverage across additional system components, and recurring third-party audits.