Google DeepMind outlines private cloud memory for AI assistants

Google DeepMind's architecture illustration for Private AI Compute with secure server-side memory.Google DeepMind
Google DeepMind's architecture illustration for Private AI Compute with secure server-side memory.Google DeepMind
AI & Automation

Google DeepMind says its Private AI Compute platform will add persistent cross-device memory while keeping user-held decryption keys outside Google's control. The architecture is described in a technical update, not as a broad consumer rollout.

Google DeepMind has outlined a persistent-memory layer for Private AI Compute that is meant to let an assistant carry context between devices without handing Google the keys to a user's stored data. The announcement describes a technical architecture and supporting verification material; it does not announce general availability for consumers.

Google DeepMind moves Private AI Compute beyond stateless requests

Private AI Compute previously focused on processing tasks inside hardware-isolated cloud environments and discarding context when a task ended. DeepMind says the new design adds encrypted, per-user storage so an assistant can retain selected context over time—for example, resuming work started on a phone from a laptop or continuing an interaction across devices.

That changes the privacy question. A stateless request can avoid retaining context, while useful personal memory requires some form of durable state. DeepMind's proposal is to keep that state in a protected cloud vault while deriving the decryption keys from the user's devices.

The proposed key boundary keeps Google out of the decryption path

According to the technical update, dedicated encrypted storage holds the retained information, while the keys needed to unlock it remain exclusively on the user's personal devices. When a model needs the data, the device establishes an authenticated, end-to-end encrypted channel to an isolated cloud environment.

Inside that secure enclave, the request can temporarily decrypt the relevant data in protected memory. New context is then saved and encrypted again. The design combines hardware-enforced secure enclaves, encrypted channels, and device-derived keys; the stated goal is to make cloud processing behave, from a privacy perspective, more like on-device handling.

The Confidential Computing Consortium describes the underlying class of technology as protection for data in use, complementing encryption at rest and in transit. Its overview also points to trusted execution environments and hardware-backed isolation as ways to reduce exposure to privileged infrastructure operators. That provides useful technical context, but it does not independently validate Google's implementation or its security claims.

Concept illustration: The proposed key boundary keeps Google out of the decryption path
AI-generated illustration

Persistent memory still needs verifiable software and operational limits

DeepMind says it is publishing an updated technical whitepaper, a tamper-proof public record of the server software, system architecture details, security proofs, and verification protocols. It also says the work includes an independent audit by a cybersecurity firm, but the announcement does not identify the firm in the page text.

Those artifacts matter because the security model depends on more than encrypted storage. Users and reviewers will need to examine device enrollment, key recovery, enclave attestation, software update verification, deletion semantics, and what metadata remains visible outside the enclave. Persistent memory also raises product questions: which facts are stored, how users inspect or remove them, and whether memory is enabled by default.

What the announcement does—and does not—promise

The immediate news is an architecture update for private, server-side AI memory. DeepMind presents cross-device continuity as the intended use case, but gives no consumer launch date, supported product list, retention controls, or independent audit report link in this announcement. Readers should therefore treat it as a technical direction and review invitation, not as evidence that a finished memory feature is already available.

The next meaningful milestone is publication of the updated technical brief and verification materials. Those documents will determine whether the proposed key separation and enclave controls can be independently assessed beyond the announcement's high-level description.

Sources

From reading to doing

Try the related loot

Give Any Model a Sandboxed Shell and File Workspace with OpenRouter

Open loot