When AI remembers you, who can read its memory?

For an AI to pick up where an earlier conversation left off, it needs to retain something after that conversation ends. If those memories include details about your work or family, how much can the company running the AI read?

On September 23, 2026, Google DeepMind announced a design for adding secure, persistent server-side memory to Private AI Compute. The aim is to store memories in the cloud while protecting their contents even from Google's operators. The design rests on three elements: encrypted storage, keys originating from the user's device, and isolated execution environments that protect data during processing. Announcement

This does not mean that keys and memories never leave the device during processing. The published audit describes a system in which an isolated environment receives a key from the device, decrypts the memories, and uses them. It also shows that preventing others from reading a memory and preventing a deleted memory from returning are separate guarantees. That distinction appears in concrete, unresolved audit findings.

Key points

• The September 23 announcement concerns the architecture for persistent memory. It does not give a general availability date or a complete list of supported products.
• The design encrypts memories at rest and decrypts them only when needed inside a verified, isolated environment. It does not let the AI understand data while it remains encrypted.
• Trail of Bits' public audit lists eight of ten findings as resolved. Two remained unresolved at the time of the report: deleted memories returning and hashes derived from responses being sent outside the protected environment.

Sources checked September 30, 2026. We distinguish Google's design claims, the auditor's findings, and LATENT's interpretation of the documents. LATENT did not independently penetration-test the production system.

Contents

1. The addition is storage for memories that outlast a conversation
2. Keys pass from the device to a verified, isolated environment
3. Protecting memory contents does not hide the link to the user
4. The audit left questions about deletion and outbound data unresolved
5. A public ledger is not the same as independent verification by a device
6. Before using it, check which features are covered and how to delete memories

The addition is storage for memories that outlast a conversation

Private AI Compute is infrastructure for having cloud AI process personal data inside a protected environment. When Google announced the platform in November 2025, it cited Pixel's Magic Cue suggestions and Recorder transcript summaries as examples. The new memory design adds a persistent storage layer to that platform; it is not the platform's debut. Google's 2025 announcement

A system that processes one request and then discards its working data has different protection requirements from one that retains information for the next request. Remembering preferences, for example, could save you from repeating them whenever you ask about a business trip. But those stored preferences and plans must remain protected afterward.

Memory here does not mean changing the AI model's weights. The technical brief describes storing information for each user in a database, retrieving relevant records, and passing them to the model alongside a new request. It keeps material the model can use to form an answer outside the conversation itself. Technical brief, pages 10–12

The existence of this design does not establish that all past Gemini conversations or saved information have moved to the new system. Neither the September 23 announcement nor the technical documents reviewed here establish general availability, supported apps, regions, or device requirements.

Keys pass from the device to a verified, isolated environment

When a service says it stores data encrypted in the cloud, the next question is how it handles the decryption key. Locking a storage box offers no protection from its custodian if the custodian can open it freely.

This design uses two types of keys. According to the audit, the device derives a key from a user's secret to protect another key. This is the KEK, or key-encryption key. A separate, per-user DEK, or data-encryption key, directly encrypts the memory contents. Ordinary server storage holds the encrypted memories and the DEK encrypted under the KEK. Audit PDF, pages 13–17

Element	Role	What it aims to prevent
Storage	Holds encrypted memories and the encrypted DEK	Reading the contents simply by stealing stored data
Keys	The device's KEK unlocks the DEK	Decryption at the storage service's sole discretion
Isolated environment	Uses keys and memories temporarily	Reading data in use through ordinary administrative access

An isolated execution environment, also called a trusted execution environment or TEE, uses hardware mechanisms to separate data in use from surrounding software. The aim is to reduce what must be trusted beyond what ordinary application permissions alone can achieve. Private AI Compute uses multiple protected computing environments, with authentication and encrypted communication between them. Technical brief, pages 4–5

Leaving out the intermediate routing details, the audited memory workflow is as follows.

1. The device verifies the destination's attestation and establishes an encrypted channel to the isolated environment.
2. The device sends the KEK through that channel. The isolated environment uses it to unlock the DEK and decrypt the memories into working memory.
3. The AI uses relevant memories as context for the request. Updated memories are encrypted again before storage.
4. When the session ends, temporary data such as search structures is discarded.

In other words, saying a key is device-side does not mean it can never leave the device. This is easy to miss in Google's general announcement, but the audit explicitly describes sending the KEK into a verified session. Where the key goes, and what can run there, are central to the protection. Audit PDF, pages 14–17

Protecting memory contents does not hide the link to the user

Persistent memory introduces requirements that do not apply in the same way to one-off processing. To retrieve the right memories, a request must be linked to the same user's storage.

Google's technical brief explicitly states that, for this reason, systems using persistent memory do not claim a guarantee of network non-targetability. Trail of Bits also explains that systems outside the isolated environment can identify the user whose request is being processed. Technical brief, page 12; audit PDF, page 6

That does not by itself mean memory contents can be read. But keeping those contents confidential is different from concealing whose storage was accessed. What needs checking depends on how much a user expects the phrase private memory to cover.

The audit left questions about deletion and outbound data unresolved

An external assessment of the implementation has been published alongside the design. Commissioned by Google, Trail of Bits primarily examined the memory design and code in June and July 2026, then reviewed fixes on August 5–7. Its final report, dated September 21, marks eight of ten findings as resolved. Audit PDF, pages 4–8 and 49–51

The auditor reports finding no mechanism in the reviewed code that would let Google employees view user data. However, the review did not cover all system and TPU infrastructure code, and important code remains private. The result should be understood as an independent assessment limited to the scope and period examined.

The two remaining findings also matter to ordinary users.

Finding	Severity	Implications for users
Memories returning	Low	Restoring an older state with powerful internal privileges could cause deleted information to be used again in a later session
Sending hashes outside the protected environment	High	Values derived from response fragments leave the protected environment and could help an attacker with powerful internal privileges infer information

The first finding is TOB-PAICSM-1. With persistent, privileged access to internal storage, an attacker can change which historical memory state is loaded without breaking the encryption. Erasing decrypted working memory does not guarantee that old encrypted data can never return. The report says Google accepted the remaining rollback risk and was considering device-assisted state verification.

The second, TOB-PAICSM-9, concerns matching used to prevent lengthy reproduction of copyrighted works. Google says the plaintext response itself is not sent out and exploitation requires substantial privileges. It also outlined plans for a Bloom filter to narrow candidates inside the isolated environment, but the finding remains unresolved in the public report. The auditor does not describe these findings as enabling compromise by an external third party. They are not reports of a public data leak or observed harm. Audit PDF, pages 7–9 and 49–51

The assessment cannot simply be extended to the production environment as of September 30. LATENT has not independently verified whether subsequent mitigations were completed or what is currently running.

A public ledger is not the same as independent verification by a device

Another question is whether the software described is actually the software running. Even if the audited program is secure, the audit provides no assurance if the service you connect to has substituted a different program.

Google describes a mechanism that records identifiers for deployed software in a public ledger and ties them to connection attestations. It has also published verification instructions for inspecting the ledger and cryptographically checking inclusion. The memory implementation is published within Project Oak, providing a starting point for examining the source.

A ledger entry alone does not prove that an implementation has no flaws. Understanding the scope of verification also requires asking whether the public source matches the production program and who checks for changes.

Separately from its description of current attestation and the public ledger, Google's technical brief places expanded independent verification by user devices, transparency logs continuously monitored and co-signed by third parties, and broader reproducible-build coverage on its future roadmap. The audit included device-side attestation verification code, but that does not establish that every verification path for ordinary users is already available. Technical brief, pages 13–14

LATENT checked the documents, the location of the public code, and the audit's scope and remediation status. We did not verify ledger signatures, rebuild the software from source, or compare it with the production executable.

Before using it, check which features are covered and how to delete memories

Deciding whether to trust Google is not enough to assess this announcement. Separating encrypted storage, the conditions for releasing keys, where decryption happens, and what happens after deletion makes the questions more concrete.

Before enabling persistent memory in an actual product, first check whether that feature is covered by these protections. Then consider whether you can review what is stored, stop or delete memories, and recover keys and memories if you lose or replace a device. The announcement and technical documents alone do not establish these user-facing controls or recovery procedures.

Confidential storage also does not make a memory accurate. An AI could securely retain a preference it misunderstood or a plan that is out of date. Technology that controls who can read memories needs to be assessed alongside product features that let users inspect and correct them.

The advance is that there is now more concrete material for assessing persistent AI memory, including device-based key management, a public implementation, and an external audit. Look beyond restrictions on who can read a memory to guarantees against restoring deleted memories and the extent of verification available to users themselves. Those are useful criteria when choosing an AI that will retain personal information over time.

Sources and scope of verification

Primary sources were checked on September 30, 2026. Audit PDF page numbers below count the cover as page 1. They sometimes differ from the page numbers printed inside the report.

1. Google DeepMind's September 23, 2026 announcement — Announcement date, design objectives, and official architecture diagram.
2. Google Private AI Compute Technical Brief, September 2026 edition — Pages 10–12 cover persistent memory, keys, and user identification; pages 13–14 cover current verification and future plans. This is Google's own design description.
3. Trail of Bits' audit report dated September 21, 2026 — An independent audit commissioned by Google. Pages 5–9 contain the summary and Google's response; page 12 covers limitations; pages 13–17 describe key and data flows; pages 49–51 report the review of fixes.
4. NCC Group's 2025 audit summary — An earlier assessment of the underlying platform, with a different scope from the 2026 memory audit.
5. Project Oak's memory source code — We verified where the implementation is published. LATENT did not conduct a comprehensive code audit or verify a build.
6. Public-ledger verification instructions — We reviewed the procedure for checking ledger records and attestations, but did not execute the verification commands.
7. Google's November 11, 2025 platform announcement — Consulted to distinguish existing use cases from this update.

Still unverified: general availability and supported products, regions, and devices; user-facing storage, deletion, and key-recovery controls; completion of mitigations for unresolved findings after the audit; and independent verification spanning every user's device and the production environment. References to the design, Google's account, and the report's findings are qualified to avoid presenting them as universally available or independently demonstrated capabilities.