Google's cloud AI memory keeps the keys on your devices

Private AI Compute is moving from stateless inference to persistent personal context

On 23 September 2026, Google described a persistent, cross-device memory layer for Private AI Compute. The existing platform uses hardware-isolated cloud environments for work that is too large or complex for a personal device. Google says those environments have been stateless, discarding task context when processing ends.

The proposed memory layer stores the information an assistant needs in dedicated encrypted cloud storage. The cryptographic keys needed to unlock it are derived from and held by a user's personal devices. Google says that design makes the stored information inaccessible to anyone else, including Google.

This is an architecture announcement rather than a general availability promise for every Google AI product. The useful question is how the protection is constructed and which assumptions must remain true for the privacy claim to hold.

A request crosses four security boundaries

How persistent private memory is intended to work

Boundary	Operation	Protection described by Google
Personal device	Authenticates the user and contributes device-derived key material	Keys required to unlock memory remain on personal devices
Network	Carries a request and encrypted memory material to cloud processing	Authenticated end-to-end encrypted channel
Secure enclave	Temporarily decrypts data in isolated memory and runs the approved workload	Hardware-enforced isolation and software verification
Memory service	Reads existing context and records new context	Dedicated per-user database and enclave-mediated access
Cloud storage	Retains encrypted memory between sessions and devices	Data-encryption keys are wrapped using device-derived protection

When the model needs personal context, the device creates an authenticated encrypted connection to a protected cloud environment. An approved enclave temporarily decrypts the required information in isolated memory, uses it for the request, writes any permitted new context and encrypts the result again. A second device belonging to the same user can participate through the cross-device key design rather than receiving plaintext memory from the first device.

The security goal depends on more than encryption during storage. The system must verify the enclave software before releasing data, isolate one user's database from another, protect key-wrapping operations, prevent operators from substituting unapproved code and limit what the model is allowed to remember.

The public software record is meant to make the server side inspectable

Google says devices will check a tamper-proof public record of Private AI Compute server software before sending personal data. This kind of attestation is intended to answer a difficult cloud question: how can a personal device know that the remote enclave is running the reviewed software rather than a modified build that extracts plaintext?

The company also points to an updated technical brief, security proofs, verification protocols and an independent assessment. These artefacts make the design more testable, but readers should distinguish architecture evidence from universal proof. An assessment covers a defined system version, scope and threat model. Operations, updates, client code and surrounding products can introduce risks outside that boundary.

The design narrows operator access but does not remove every threat

What the architecture addresses and what still needs scrutiny

Threat or failure	Relevant control	Remaining question
Cloud operator reads stored memory	Device-derived keys and encrypted per-user storage	Can any recovery or support path bypass the normal key boundary?
Modified server software extracts plaintext	Enclave attestation and public software ledger	How quickly are devices and auditors alerted to a bad or withdrawn build?
Network interception	Authenticated end-to-end encrypted channel	How are endpoint and account compromise handled?
Cross-user data exposure	Per-user databases and isolated processing	What tests verify tenant separation through every service?
Compromised personal device	Keys remain on personal devices	Can an attacker with the device or account authorise memory access?
Unwanted or incorrect memory	Product-level retention controls	Can users view, correct, delete and disable stored context?
Model leaks remembered data	Policy and inference controls	How is sensitive memory limited across prompts, tools and recipients?

Enterprise adoption needs controls around the memory, not only the cryptography

Persistent memory changes the privacy argument for personal AI

A stateless cloud assistant can process sensitive content, but it starts each request without durable continuity. Persistent memory can make the assistant more useful across a phone, laptop, browser and wearable. It also creates a concentrated, long-lived record of preferences, relationships, tasks and past context.

Google's design tries to retain the utility while denying the platform operator routine access to plaintext memory. If the implementation and verification hold, it is a stronger model than ordinary server-side encryption where the service provider controls all decryption keys. It also raises the standard for competitors: claims of private AI memory should explain who holds the key, which code can receive it, how that code is verified and how users remove what the system remembers.

Key facts