Google DeepMind Says Private AI Compute Will Get Encrypted, Cross-Device Memory

Google DeepMind published a technical update on September 23, 2026 describing how its Private AI Compute platform will support persistent, server-side memory — a cloud store of user context that the company says is sealed with cryptographic keys held only on a user's own devices. The company frames it as a way to give assistants continuity across a phone, a laptop and smart glasses without giving up the privacy properties normally associated with on-device processing. The post is written in the future tense, and Google did not disclose a launch date, the products involved, or which regions or account types will get it first.

What Google says the architecture does

According to the Private AI Compute Team, the new capability adds a persistent memory layer that behaves like an encrypted vault in the cloud. The stored data sits in dedicated encrypted storage, and the keys needed to decrypt it live exclusively on the user's personal devices. Google's claim is that this makes the contents inaccessible to anyone else, including Google itself.

The flow described in the post works roughly like this: when a model needs stored context, the device opens an authenticated, end-to-end encrypted channel to an isolated cloud environment — a "secure enclave" in Google's terms. Inside that enclave, the data is temporarily decrypted in isolated memory, the request is served, any new context generated during the session is written back, and everything is re-encrypted. Google describes the combination as hardware-enforced enclaves, encrypted channels, and per-user databases protected by device-derived keys.

The company's own framing of the benefit is mundane in a useful way: viewing assembly instructions through smart glasses and then picking them up on a laptop, or continuing a long conversation between a mobile app and the web. That is a continuity problem, not a capability problem, and it is the kind of thing users notice immediately when it does not work.

Why the old design was stateless

The more interesting part of the post is the admission of what the previous version could not do. Google says Private AI Compute, as introduced earlier, was strictly stateless: context was discarded the moment a task finished. The company notes that similar approaches elsewhere in the industry share that constraint.

Statelessness is a strong privacy property precisely because there is nothing left to compromise. It is also a hard ceiling on product design. Google says the usual workaround — having the assistant maintain a list of saved facts and preferences — is not enough to support the continuous experiences people expect. That is a fair assessment. A summarized profile of a user is lossy by construction; it captures what a model decided was worth writing down at the time, not the raw thread of interactions.

The company also restates the underlying reason any of this is necessary: frontier models need more compute than a single personal device can supply, so the work has to move to servers. The design goal, in Google's words, is to make cloud processing feel as protected as if the data never left the device. Whether it is equivalent to on-device processing is a different claim, and Google does not make it.

Transparency claims, and what they cover

Alongside the architecture, Google says it is publishing a tamper-proof public record of its server software, and that devices running Private AI Compute will be able to verify the software is authentic and unaltered before transmitting any personal data. That is remote attestation combined with a transparency log, and it is the right shape for this problem: it shifts the trust question from "do you believe Google's policy" to "can your device check what it is talking to."

The company also says it is releasing an updated technical brief covering system architecture, security proofs and verification protocols, and reporting results from an independent audit conducted by what it describes as a leading cybersecurity firm. Google did not name the firm in the post, did not summarize the audit's findings, and did not say whether the full report will be published or what scope it covered. For a security claim this strong, those omissions matter — an audit of enclave attestation logic is a very different artifact from an audit of the entire storage and key-management stack.

Attestation also only proves that the running software matches a published measurement. It does not, by itself, tell a user whether the published software does what the accompanying documentation says. The value of the transparency log depends heavily on whether independent researchers can practically reproduce builds and reason about the code paths that touch decrypted memory.

The questions the post does not answer

Device-held keys create an obvious operational problem: what happens when the device is lost, replaced or wiped. Any recovery mechanism — escrow, a recovery key, sync through another trusted device — is where systems like this usually make their real privacy trade-offs. Google's post does not describe how keys are provisioned to a second device in the first place, which is a prerequisite for the cross-device scenarios it uses as examples.

Several other gaps stand out. The post does not address data retention limits, whether users can inspect or delete the stored memory, or how the system behaves under legal process directed at Google. It does not discuss the latency or cost of decrypting and re-encrypting per-user state on each request, which is not free at consumer scale. It does not say whether enclave side-channel risk was part of the audit scope. And it does not specify whether the memory layer is opt-in.

There is also a structural point worth naming. A stateless system holds nothing worth stealing; a persistent one accumulates a durable, per-user record of what a person asked, saw and was shown. Even under strong encryption, that changes the value of the target and the consequences of a flaw in key handling or enclave isolation. Google's design appears to take that seriously, but the risk profile is genuinely different from what came before, and the post does not frame it that way.

Google credits the work to teams across Google DeepMind, Platforms & Devices, Core and Cloud, with executive sponsorship from Four Flynn, Jay Yagnik and David Kleidermacher. It invites the privacy research community to review the materials — which is, in practice, the test that matters.

What to watch

• Whether the independent audit is published in full, with the firm named and the scope defined, or remains a summary line in a blog post.
• How key provisioning and recovery work across multiple devices, and whether any server-side escrow is involved.
• Whether users get visibility and deletion controls over the stored memory, and whether the feature ships as opt-in.
• Whether outside researchers can reproduce builds from the published server software record and validate the attestation chain end to end.
• Which products adopt the memory layer first, and on what timeline — none of that was disclosed.