Private AI Compute gets a memory, and the privacy guarantee changes shape
Google is adding persistent, per-user memory to Private AI Compute, encrypted under user-bound keys and decrypted only inside attested enclaves. The design is careful, and its most important detail is the guarantee it openly gives up.
On September 23, Google DeepMind announced that Private AI Compute will gain secure, server-side memory. Private AI Compute is the hardware-isolated cloud platform Google introduced in November 2025 to run Gemini on sensitive personal data. Until now it was stateless: an enclave handled a request, then discarded everything. With memory, an assistant can keep context across sessions and devices while that data stays, in Google's words, "inaccessible to anyone else, even Google." It is an architecture update, not a new model, and its most interesting part is a tradeoff the brief states openly.
What was announced
The updated Private AI Compute Technical Brief has the detail. At its center is a memory Oak Server, a per-user Rust database running inside a hardware TEE. Each record is encrypted under that user's keys, so the platform can store, replicate and back up the database without handling plaintext. A request that needs past context goes through four steps:
- Ingress. The device opens a Noise Protocol session to an orchestrator enclave running in an AMD SEV-SNP confidential VM.
- Retrieve. The orchestrator opens a mutually attested ALTS channel to the memory server; the user's keys are unsealed only after the enclave's measurement verifies, and records are decrypted in volatile RAM.
- Infer. Context and prompt go to the TPU platform over an attested channel.
- Commit and purge. New memories are re-encrypted under the user's key and written back, and prompt context, tokens and activations are wiped.
Google also published a tamper-proof public record of its server software, summaries of 2025 and 2026 independent audits, and the memory server's source code. The post is written in the future tense and names no product using memory yet; for now, this is a published design.
Why it matters
A stateless enclave offers a clean guarantee: once the session ends, nothing is left to steal. The cost is an assistant that forgets. Google says the usual workaround, saving a list of facts and preferences, isn't "enough to support the rich, continuous experiences people expect." Keeping it all on-device hits capacity limits, sync friction and the cost of resending long histories. Personal AI will have persistent memory either way; the question is whether it can live in the cloud without the operator reading it.
The tradeoff, stated plainly
Stateless inference was built to be non-targetable: third-party IP-blinding relays strip anything linking a request to a user. A memory store can't, because every request must reach one specific user's store. The brief says so directly: the stateful system "does not claim network-level non-targetability."
| Stateless (before) | With server-side memory | |
|---|---|---|
| Context after the session | Discarded | Persisted, encrypted per user |
| Can an attacker single out one user? | Designed to be infeasible | Yes, but only reaches ciphertext |
| What protects the data | Nothing survives to steal | Key release gated on attestation |
So everything rests on one control: keys are released only to an enclave whose attestation matches an endorsed binary. Reproducible builds tie published source to a digest, recorded in an append-only ledger, that the enclave must attest to. Open-sourcing the memory server fits the brief's own view that persistent state "carries a fundamentally higher risk profile than ephemeral computation."
Two roadmap items decide how much users can verify rather than trust. The first is client-side attestation verification, described as "moving from Google-asserted compliance toward client-side cryptographic verification." The second is a binary ledger co-signed by independent third parties. Until both ship, part of the trust sits with the audits and Google.
What I would borrow
In most agent stacks I review, memory is a vector store with a tenant column, readable by every log line and debugger that touches it. You don't need confidential hardware to apply three ideas from this design. Encrypt memory per user, not per database. Decrypt only inside the narrowest piece of compute that needs the plaintext. Apply default-deny egress so memory can't leak through logs, monitoring or core dumps.