Google says user devices will hold the keys to persistent AI memory

Google described a new architecture for persistent AI memory on September 23. Private AI Compute, which previously erased context after each task, is designed to retain information across sessions and devices without giving the cloud storage layer the keys needed to read it. Google says those keys will remain exclusively on a user’s personal devices. (Google DeepMind)

That turns memory into more than a retrieval feature. It creates a distributed security system whose product behavior depends on device enrollment, key recovery, enclave attestation, retention, and deletion.

The disclosure is also explicitly forward-looking. Google says the design “will enable” persistent memory and does not provide a rollout date. Its public post refers to an independent audit but does not name the firm or link to an audit report. The linked technical brief was unavailable during this review. The architecture is therefore useful design evidence, not production evidence.

The storage service sees ciphertext, while the enclave sees plaintext

Google’s stated data path separates three roles.

1. A personal device opens an authenticated, end-to-end encrypted channel to a protected cloud environment.
2. A hardware-enforced secure enclave temporarily decrypts the user’s memory in isolated memory, runs the request, and saves new context.
3. The new state is encrypted again before it returns to a dedicated per-user database.

Google says the database is protected by device-derived encryption keys and is inaccessible even to Google. The company’s original Private AI Compute platform already used remote attestation and encrypted connections to hardware-isolated cloud enclaves, but it was stateless. The new proposal adds durable storage to that trust boundary. (Private AI Compute)

This split limits what a compromised storage system should reveal, but it does not make the system simple. Plaintext still exists inside the enclave while a request runs. The device must decide which enclave software it trusts. Google says it is publishing a tamper-proof public record of server software so devices can verify that the code is authentic and unaltered before sending data.

For architects, the important artifact is not just an encryption claim. It is the complete authorization chain:

enrolled device -> accepted enclave measurement -> temporary plaintext -> encrypted per-user memory

Every arrow needs a version, an expiry rule, and an audit trail.

Cross-device continuity makes recovery part of the threat model

A memory that follows someone from phone to laptop needs a device-membership protocol. Adding a device, replacing a lost device, removing a stolen device, and restoring access after all devices disappear are security-sensitive product flows.

The public announcement does not explain those flows. That leaves a structural trade-off to resolve. If a provider-controlled recovery path can recreate the unlocking authority, that path becomes part of the trust boundary. If no such path exists, losing the last authorized device may make the memory unrecoverable. A system can choose either behavior, but it should not hide the choice behind a generic “encrypted” label.

Revocation also has two clocks. A device can be removed from the account immediately, while old credentials, cached attestations, or queued requests may remain valid for some period. Tests should prove the maximum interval during which a removed device can still obtain useful plaintext.

The same discipline applies to server software. A public software log helps only if clients reject unknown, revoked, or rolled-back enclave measurements. Authentic code is not necessarily current code.

Persistent memory needs three separate state models

Teams building a similar system should keep three kinds of state distinct.

• Product memory: the facts, preferences, summaries, provenance, confidence, and retention period the assistant may use.
• Security state: authorized devices, key versions, enclave measurements, revocations, and recovery authority.
• Operational state: schema versions, deletion jobs, backup generations, replication status, and incident holds.

Combining them in one opaque “memory” record makes failures hard to contain. A product edit should not silently rotate credentials. A key rotation should not change the semantic memory. A restore should not resurrect data that the user already deleted.

A practical design review should ask six questions:

1. What exact data is remembered, and can the user inspect or correct it?
2. Which device or service can authorize decryption?
3. How are new devices enrolled and old devices revoked?
4. What survives deletion in replicas, backups, caches, and audit logs?
5. What happens when attestation, key access, or memory storage is unavailable?
6. Which claims can an external reviewer reproduce without trusting an operator dashboard?

Fallback behavior deserves special attention. If private memory is unavailable, the assistant should fail closed or continue in a clearly stateless mode. Quietly switching to a different storage or processing path would change the privacy contract at the moment the system is degraded.

Today’s API deadline has no migration target

OpenAI’s Videos API and the sora-2 model family are scheduled for removal on September 24. The deprecation table lists no replacement. This is feature retirement, not a model migration. (OpenAI deprecations)

Teams that still have the API in a production path should disable new work, drain or cancel queued jobs, preserve required outputs under their own retention policy, and verify that user-facing fallbacks do not keep retrying a retired endpoint. An HTTP error is not a migration plan.

Stay Sharp: recovery defines the real trust boundary

Encryption diagrams usually show the happy path. Recovery diagrams reveal who ultimately has authority.

For any device-held-key design, write down what happens after loss of one device, loss of every device, account compromise, support escalation, and legal hold. Identify who can add a new decryption-capable device and what evidence that action requires.

Then test the inverse operation. Removing a device should revoke future access, and deleting memory should make old ciphertext useless even after a backup restore. Crypto-shredding, which destroys the relevant key material, can help, but only if no recoverable key copy or alternative authorization path remains.

The principle is simple: a party that can restore access can influence the confidentiality boundary. Recovery is not an exception to the security model. It is part of the model.

What to watch

• Whether Google publishes the named auditor, full findings, threat model, and reproducible verification steps.
• How device enrollment, total device loss, revocation, and account recovery work before persistent memory reaches users.
• Whether deletion propagates through backups and derived memories, and whether users can inspect provenance and retention.
• How Private AI Compute behaves when attestation or memory access fails, including whether it falls back to an explicitly stateless experience.