Google says even Google can't read your AI's new memory. Here's what that promise actually rests on.

On September 23, Google DeepMind announced persistent, server-side memory for Private AI Compute , the system Google uses to run Gemini on sensitive personal data in its own data centres. The pitch is an assistant that remembers your long-running project, your preferences and the decisions it already made for you, and picks all of that up again on whichever device you happen to be holding. The privacy promise attached to it is about as big as privacy promises get: the memory is “sealed within dedicated, encrypted storage, while the cryptographic keys required to unlock it are held exclusively on your personal devices — ensuring your data is inaccessible to anyone else, even Google.”

“Even Google” is a strong phrase from a company whose business is knowing things about you. So we did the boring thing and read the technical brief  behind it, dated September 2026. Short version: this is serious engineering, a long way better than “trust us, we have a policy.” But the sentence about keys living “exclusively on your personal devices” is the marketing version. The brief tells a more interesting story, and it’s the story worth understanding before you hand any service the most personal data you have.

Worth saying up front: nothing here is live yet. Google hasn’t given a rollout date, and the blog post describes what the platform “will be able to” do.

Where the key actually is when your data is readable

Every “we can’t read your data” claim comes down to one question: at the moment your data is readable, where is the key, and whose hardware is it in?

For Google’s new memory, the brief answers plainly. Your records sit in a per-user database run by something Google calls the memory Oak Server. When Gemini needs your context, that server proves to the rest of the system that it’s running approved code, and then, in the brief’s words, “the user’s decryption keys are unsealed to the database engine. The relevant records are decrypted strictly in volatile enclave RAM.” Elsewhere: “the key material is only ever available in plaintext inside an attested TEE.”

A TEE, or trusted execution environment, is a walled-off section of a server that the rest of the machine, including the people who run it, is not supposed to be able to see into. Google uses two kinds here. General-purpose work runs in confidential virtual machines on AMD’s SEV-SNP hardware, and the model itself runs on what Google calls a hardened TPU platform, which the brief says delivers “privacy and security properties comparable to a typical TEE.” Your memories get decrypted inside that boundary, merged with your prompt, sent to the model, and wiped from memory once the answer is out. Anything new gets re-encrypted and written back.

So the key isn’t only on your phone. When the system is actually using your data, the key and the plaintext are both inside a Google data centre, on Google hardware, running Google code. What stops Google from reading them is the enclave, not the distance. It’s a real protection. It’s just a different one from “only your devices hold the key,” and the difference matters when you’re working out what you’re trusting.

What you’re trusting instead

Google’s answer to “why should I believe the enclave?” has three parts, and all three are more than most cloud services offer.

• Attestation. Before a key is released, the enclave has to prove, with hardware-backed measurements, that it’s running a specific approved build. A modified build, the brief says, “cannot obtain the keys, and therefore cannot read a user’s memory.”
• Published code. The memory Oak Server and the runtime it sits on are open source, written in Rust, and built reproducibly, so outside researchers can check that the binary running in production matches the source they read. The approved binary’s fingerprint goes into an append-only public ledger.
• Audits. External auditors reviewed both the original 2025 release and this year’s update, and Google has published summaries of their reports.

Now the fine print, all of it from Google’s own document.

First, who checks the attestation. Under future releases, the brief lists “moving from Google-asserted compliance toward client-side cryptographic verification, enabling user devices to independently validate server attestation evidence and endorsed binary identities before transmitting sensitive data.” That’s a direction, not something shipping now. Read the other way round, it says that today your device doesn’t fully check that evidence itself, and the chain of trust still leans on Google’s side of the line.

Second, targeting. The earlier, stateless version of Private AI Compute made a nice claim: a query couldn’t be linked to a user, because nothing in it identified you. A memory store can’t work that way, because your request has to reach your store. The brief says so directly: “the stateful system does not claim network-level non-targetability.” Its argument is that anyone who targets your store only gets “opaque ciphertext”. That holds only for as long as the enclave does.

Third, the enclave itself. The brief’s own threat section names attackers who “exploit flaws in the hardware components, as well as vulnerabilities in the operating system, hypervisor, and application code.” That’s why the design has several layers. It’s also an admission that the walls are made of hardware and software, and those have bugs. The same family of chips has been broken before: BadRAM , published at IEEE S&P in 2025, used under $10 of equipment and a tampered memory module to get into SEV-SNP’s encrypted memory, and AMD had to ship firmware fixes.

None of this makes Google’s design bad. It’s a bet on attestation, audits and hardware isolation holding up, placed by the company that also runs the hardware. If you use Gemini on your personal data anyway, this beats the alternative. Just know that “even Google can’t” means “Google has built the system so that Google can’t, and published enough for other people to check parts of that.” That’s a narrower claim than it sounds.

Why the data had to leave in the first place

The brief is honest about why this isn’t on your phone. It says on-device storage runs into “physical capacity limits, friction syncing across multi-device surfaces,” and the cost of repeatedly sending huge histories to cloud models. The model that reads your memory is a frontier model in a data centre, so the memory has to be decryptable next to it. The architecture follows from that one requirement.

That’s the right question to ask of any sensitive data you own: does it actually need to be decrypted anywhere other than your own machine? For an AI memory feeding a giant model, Google has decided yes and built the best walls it can. For a lot of your data, the answer is no, and then the whole stack of enclaves, ledgers and audit summaries is solving a problem you didn’t need to have.

Passwords are the clearest case. A vault doesn’t need a frontier model to be useful. It needs to open when you sit down to log in, and to stay shut the rest of the time. We went through the same “who can open it” question for password managers in what “zero-knowledge encryption” actually promises, and the recurring problem there is that the company making the promise also runs the server that decides whether it’s kept. Google’s memory design is, in effect, a very elaborate attempt to make its server checkable from outside. The simpler option is not to need the server at all.

That’s the choice we made with Vauz . Your vault opens on your own computer, and nothing we hold would let us open it. There’s no enclave on our side to attest, because the step Google has to protect so carefully, a key meeting your plaintext on someone else’s hardware, doesn’t happen with us. The Vauz threat model  lists exactly what we do hold, which is account details like your name and email address, and what we can’t see, which is everything in the vault. We explain the longer reasoning in how Vauz keeps your secrets local.

To be fair, local-first has its own costs. It moves the risk rather than removing it. Malware running on your own computer is a problem for any password manager, and we’ve written about what a local vault does and doesn’t change there. And keeping things on your machine means thinking about what happens if you lose that machine, which we cover in the problem with backing up a master password. What local-first removes is a whole category of trust in someone else’s building, someone else’s staff and someone else’s chips.

The question to carry around

The next time a company tells you it can’t read your data, and with AI memory arriving across the industry you’ll hear it a lot, skip the adjectives and ask two things. When my data is readable, where is the key? And who owns the hardware it’s sitting on at that moment?

If the answer is “your device, and only your device,” you’re trusting your own machine. If it’s “our data centre, inside an enclave we built,” you’re trusting attestation, audits and chip designers. That’s a legitimate thing to trust, but it’s a choice you should make knowingly, one kind of data at a time. And if we’re talking about handing an AI agent your passwords, keep the key as close to home as you possibly can.