Google's private AI memory design keeps device-held keys, with two audit gaps

Google has published a design for giving cloud-hosted AI assistants persistent memory while keeping the decryption keys on a person’s devices. The change matters because Private AI Compute was built around short-lived processing. A memory-backed assistant needs to retain context between requests, across sessions and potentially across devices.

The security claim is stronger than ordinary encryption at rest. Google says its new per-user memory can be decrypted only inside approved confidential-computing workloads after attestation. A commissioned Trail of Bits assessment found no mechanism in the reviewed code for Google employees to read user data. It also found limits that should remain visible in any product decision: the reviewed system could not cryptographically prove that a deleted memory would never return, and hashes derived from some response text still left the trusted computing boundary.

Google published the architecture page at 16:00:57 UTC on 23 September 2026, but it is not a general product-availability notice. The post says Google is sharing how it will bring private server-side memory to the platform. It does not identify the first consumer feature, its launch date or the controls a user will receive. Buyers and security teams can evaluate the design now. They cannot yet assume that every future Google assistant carrying a memory label uses the reviewed path.

What changes when private inference remembers

Private AI Compute originally handled a request inside protected cloud infrastructure and discarded the plaintext state when the session finished. Persistent memory changes the threat model because the encrypted records remain useful only if a later request can find and decrypt the right user’s history.

Google’s updated technical brief describes a per-user database running in a hardware trusted execution environment. Records are encrypted with per-user keys. An orchestrator, the memory server and the inference pipeline authenticate one another over encrypted channels, and keys are released only when the memory enclave presents approved attestation evidence. Google says the surrounding cloud can store, replicate and back up ciphertext without seeing the underlying plaintext.

The memory service is built on Project Oak. Google has published the Oak private-memory source and says reproducible builds, a public ledger of approved binary digests and enclave attestation connect inspectable source to production code. Those mechanisms matter because a source repository alone does not show what is running for a particular request.

The stateful design necessarily gives up one property of the earlier service. For stateless inference, IP-blinding and anonymous tokens were intended to prevent a request from being linked to a user. The brief says a persistent store needs a stable per-user identifier so the request reaches the right database. It therefore does not claim network-level non-targetability for memory requests. Its security claim is narrower: targeting the store should yield ciphertext that remains unreadable without the user’s keys and an approved enclave.

That trade changes what a customer should ask. A private computation and a private historical profile are not the same asset. Retention, identity resolution, backup, deletion, key recovery and device enrolment become part of the system’s privacy boundary.

The audit supports part of Google’s claim

Google hired Trail of Bits to build a threat model and review the secure-memory implementation. Four consultants worked for five engineer-weeks between 4 June and 17 July 2026, followed by a fix review from 5 to 7 August. The final public report is dated 21 September. The review used private Google source code, configuration and documentation as well as open-source components.

Within that scope, Trail of Bits reports that it found no mechanism by which Google employees could access user data in the reviewed code. It commended the choice to hold memory encryption keys on user devices and make plaintext available in trusted server hardware only during active use.

Trail of Bits did not conduct a complete review of Private AI Compute, the hardened TPU platform or Oak’s infrastructure. It relied on an earlier NCC Group review for parts of that foundation. Its report is a point-in-time assessment commissioned by Google, not a standing guarantee. It also notes that extensive parts of the system remain closed source and that Google can change the service after the reviewed snapshot.

The audit identified ten issues: two high, one medium, two low and five informational. The fix review marked eight resolved. Two remained unresolved.

One unresolved issue concerns deletion rollback. An attacker with persistent privileged access to the untrusted storage layer could restore an older encrypted database snapshot after a person deleted a memory. Google fixed a related substitution problem by cryptographically binding record identifiers to ciphertext, but accepted the remaining rollback risk while investigating client-assisted state verification. The audit rates it low severity because exploitation requires privileged storage access and a later user session. Deletion removed the current record, but the reviewed design did not provide a cryptographic guarantee that an old encrypted state could never be presented again.

The other unresolved issue sits in recitation checking. The system sent truncated 96-bit hashes of response chunks to an out-of-enclave service used to detect reproduction of indexed material. Trail of Bits rated the issue high while describing exploitation as technically difficult and dependent on privileged internal access. The report does not say raw prompts or plaintext responses leave the trusted boundary through this path. Google told the auditors it planned an in-enclave Bloom-filter check so only likely matches would trigger an external hash query, but the final fix review still listed the issue as unresolved.

The findings do not show that staff can casually read memories or document an external compromise. Their practical value is in the boundary they draw around Google’s headline privacy promise: a privileged rollback is treated differently from plaintext access, and response-derived hashes are treated differently from raw content.

The verification roadmap is not the current control set

Google describes several ways outsiders can inspect the system: published source for the memory service, reproducible builds, binary digests in a ledger and third-party audits. Its brief also lists stronger measures as future work, including client-side verification of server attestation and a transparency log witnessed and co-signed by independent parties.

For procurement, a roadmap to user-verifiable attestation should not be recorded as a control already available in every client. A public audit should be tied to the version, binary identity and product route that will process the organisation’s data. If a product cannot expose that relationship, the assessment remains evidence about a reviewed design rather than the deployed instance.

Before approving a memory-backed assistant, ask for a feature-specific answer to six questions:

1. Which product, client version and workload route use the audited memory service?
2. How does a user enrol a second device, revoke a lost device and recover access without giving the provider an equivalent decryption path?
3. What does deletion remove from the active database, replicas and backups, and how is rollback detected?
4. Which telemetry or safety services receive plaintext, hashes or other response-derived data outside the trusted boundary?
5. Can the client verify the enclave, approved binary digest and ledger entry before releasing a key?
6. Which audit findings and mitigations apply to the exact build now in production, and who rechecks them after a material change?

Then test the controls a normal user can see. Create a distinctive, non-sensitive memory; retrieve it across the supported clients; delete it; revoke one device; and check whether the service documents each state transition. This cannot reproduce the cryptographic review, but it can expose gaps between the architecture and the user-facing lifecycle.

Index Us did not run Private AI Compute, inspect Google’s private code, verify a production binary, test deletion or reproduce the Trail of Bits findings. The audit was paid for by Google and time-boxed, although Trail of Bits authored the public findings and recorded unresolved issues. The reviewed evidence supports taking the design seriously. It does not remove the need to identify the actual product path and verify how memory, keys and deletion behave when the feature ships.

Sources

1. Google DeepMind — Advancing Private AI Compute with secure, server-side memory
2. Google — Private AI Compute technical brief
3. Trail of Bits — Google Private AI Compute secure server-side memory assessment
4. Project Oak — private memory source

Last reviewed: 24 Sept 2026. See our editorial policy for how we test, source and correct our work.