Google wants its AI assistants to remember useful context between requests without keeping the keys to that memory on its servers. In a September 23 announcement, Google DeepMind described a persistent memory layer for Private AI Compute: encrypted, per-user storage in the cloud, with the keys needed to unlock it held on the user’s devices.
The design addresses a real constraint. An assistant that forgets each interaction cannot easily continue a task started on another device. Storing personal history in the cloud, though, raises questions about who can read it and under what conditions.
Google’s answer combines device-held keys with isolated cloud processing. It has also pointed to an updated technical brief, a server-software record and an independent security audit. Those are materials for scrutiny, not proof that a cross-device memory feature is available today or that every privacy claim has been independently established.
Private AI Compute Had Cloud Processing, but Not Persistent Memory
Google introduced Private AI Compute in November 2025 as a way to run sensitive AI requests using cloud-based Gemini models inside hardware-isolated environments. Google said the platform would give certain tasks access to more computing power than a device could provide while limiting access to the personal information involved.
The platform was already in use. Google identified selected features it supported, including more timely Magic Cue suggestions on Pixel 10 phones and expanded transcription summarization in the Pixel Recorder app. Those examples do not establish that the newly described persistent memory system is part of those features.
According to Google DeepMind, the earlier system could process a request in an isolated cloud environment, then discard its context when the task ended. That protects privacy, but limits continuity. To remember a project, preference or prior conversation on a later request, an assistant needs that information supplied again or stored outside the short-lived processing session.
Google’s proposed memory layer would retain per-user context in encrypted server-side storage for later use, including when the next request comes from a different device. Google describes a system intended to support ongoing, context-rich assistance, beyond saving a short list of preferences.
How Device-Held Keys and Cloud Enclaves Fit Together
The updated Private AI Compute technical brief accompanies Google’s description of a system with two distinct locations for a user’s data. Persistent memory would live in a per-user database on Google’s servers, encrypted with keys derived from or held by the user’s devices. Google says the keys required to unlock that stored memory would remain exclusively on those devices.
When an assistant needs the memory, the device would establish an authenticated, encrypted connection to a secure enclave in the cloud. An enclave is an isolated processing environment intended to restrict access to the data and code inside it. Google says the enclave would temporarily decrypt the relevant information in isolated memory, process the request, save any new context and encrypt the information again for storage.
The memory is not encrypted at every moment of use. An AI system cannot reason over relevant personal context without making it available to the computation performing the task. Google’s design places that plaintext processing inside a protected cloud environment instead of a conventional application server. The encrypted connection ends at that environment; the data is not readable only on the user’s devices.
The device also does more than hold keys. Google says devices running Private AI Compute will be able to check that the server software is authentic and unaltered before sending personal data. This check, known as remote attestation, is meant to help a device avoid sending sensitive information to an unexpected cloud environment.
The design separates storage, authorization and computation. Encryption protects the retained database; device-held keys are meant to control access; attestation and hardware isolation are meant to constrain where decrypted information can be processed. Encryption at rest alone would not address what happens when the assistant needs to read the memory.
The Privacy Boundary Moves Into Cloud Processing
Google describes the result as bringing on-device privacy standards to cloud-scale memory. Under the proposed workflow, personal context leaves the device and is decrypted for a task inside a cloud enclave.
That identifies the trust boundary readers should evaluate. The privacy claim depends on the security of the devices holding the keys, the authenticated connection, the enclave hardware, the software running inside it and the rules governing what that software can do with decrypted data.
Device-held keys could prevent someone with access only to the encrypted server database from reading its contents, assuming the system works as described. They cannot, by themselves, establish that the enclave’s code handles plaintext correctly. Encryption of the server copy also would not resolve the consequences of a compromised device that can authorize access. These are threat-model distinctions, not reports of a breach.
Google says its design prevents even the company from accessing users’ information. That is a stronger claim than saying ordinary Google systems cannot access it. Assessing it requires examining the implemented system and the evidence behind its protections, not only the placement of its keys.
Google Points to a Brief, a Software Record and an Audit
Alongside the architecture, Google says it is publishing an updated technical brief and a public record of its server software. It describes that record as tamper-proof and says devices will be able to verify software authenticity before transmitting personal data. Google also says it is providing results from an independent security audit by a cybersecurity firm.
Each offers a different form of evidence. A technical brief can make a design inspectable. A software record and attestation mechanism can help connect what a device is asked to trust with an identifiable software build. An audit can examine particular controls or implementations. Their announcement alone does not establish that every device, server configuration and future feature will behave as intended.
The announcement does not name the audit firm or explain the audit’s scope in the post itself. Judging which claims the materials substantiate would require examining the full technical brief and any underlying audit materials. Google’s statement that an independent audit took place is not equivalent to an independent evaluation of a finished, widely deployed cross-device memory feature.
Still, making mechanisms available for outside inspection gives researchers more to work with than an architectural claim alone. They could examine the verification process, the software record and the audit evidence. The strength of that evidence will depend on what it covers and whether deployed products can be checked against it.
Frequently Asked Questions
4 questions
1What Is Google’s New Private AI Compute Memory?
It is a proposed persistent, per-user memory layer for Google’s Private AI Compute platform. Google says the memory would remain encrypted in server-side storage, while keys held on a user’s devices would control access. A protected cloud enclave would temporarily decrypt relevant context to handle an AI request, then encrypt updated context for storage.
2
Sources
- September 23 announcementdeepmind.google
- introduced Private AI Computeblog.google
- updated Private AI Compute technical briefservices.google.com
