Google Private AI Compute Memory Has Two Open Audit Findings

Google is moving personal AI memory into the cloud

Google plans to give Private AI Compute persistent memory so an AI feature can retain context across sessions and devices. The company’s September 23 announcement describes encrypted per-user databases, keys held on the user’s devices, and processing inside attested secure hardware. Google has not named the first products, supplied a launch date, or said that the feature is generally available.

Private AI Compute already handles selected AI workloads on Google infrastructure when a phone cannot run them locally. The new design changes the privacy problem because the service must recognize the same user over time and retain state between requests. Google’s technical brief explicitly says the stateful system does not claim network-level non-targetability: a stable per-user identifier is required outside the trusted environment so requests can reach the correct memory.

That makes this encrypted cloud processing, not on-device AI. It may reduce what Google operators and ordinary cloud services can see, but the request still leaves the device and depends on Google’s servers, implementation, identity layer, and update process.

Device-held keys define the storage boundary

Each enrolled device creates or receives keys that protect the user’s memory. Google says those keys are unavailable to its normal infrastructure and only become usable after the device verifies an approved workload running in a trusted execution environment. Plaintext memory is meant to exist only inside that environment. Administrative access, including emergency access, cannot decrypt it through the documented service path.

The memory server is built on Google’s open-source Oak project in Rust. Reproducible builds and an append-only transparency ledger are intended to connect reviewed source code to the software running in the enclave. Network access from the trusted environment is denied by default, apart from destinations needed to fulfil the user’s request. After a response, the service re-encrypts the updated memory and wipes volatile prompt, token, and activation data.

These controls reduce several familiar cloud risks, but they do not make the system equivalent to keeping a model and conversation entirely on a phone. Google still controls the surrounding infrastructure and software release process, and parts of the wider platform remain outside the public code and audit boundary.

Eight audit findings were fixed and two remain open

Trail of Bits reviewed the secure-memory component over five engineer-weeks and reported ten findings. Google resolved eight before publication. The remaining findings were accepted as risks rather than fixed, and both require a privileged attacker inside the service environment rather than an ordinary remote user.

The first is a low-severity rollback problem. Someone with privileged control of encrypted storage could restore an older database snapshot after a user deleted a memory. Encryption prevents the attacker from reading the content directly, but the old memory could reappear during a later legitimate session because the client has no standard cryptographic proof that the newest state was loaded. Google says it is investigating client-assisted state verification.

The second finding is rated high severity. Deterministic 96-bit hashes of response chunks leave the trusted boundary so another system can check for repeated output. Trail of Bits found that a privileged internal actor with the relevant hash material and a prepared index could potentially reconstruct structured responses. Google plans to move toward an enclave-based Bloom filter, but that mitigation was not complete in the final report.

The audit did not find a normal employee mechanism for reading memory plaintext within its scope. It also did not cover every Private AI Compute component, physical attacks, the host and TPU kernels, or all closed-source services surrounding the memory server. A point-in-time review cannot guarantee that later software will preserve the same properties.

User-verifiable attestation is still future work

Google’s announcement says devices will be able to verify that they are communicating with approved software. The technical brief is more precise about what remains: direct client-side verification of attestation evidence and independently witnessed transparency logs are listed as future releases. Today’s architecture provides attestation and a public ledger, but end users do not yet perform the full independent verification path described as the long-term goal.

The feature should be judged again when Google names a shipping product. Its memory controls need to make storage, deletion, device recovery, and account removal understandable in the interface. The two audit findings also need visible resolution or a clear explanation of the accepted exposure. Until then, Private AI Compute memory is a documented architecture with meaningful safeguards and unusually specific audit evidence, but not a generally available substitute for local storage and inference.