Google rebuilds Private AI Compute: per-user memory database in secure enclave replaces stateless cloud

Google rebuilds Private AI Compute: per-user memory database in secure enclave replaces stateless cloud

Google announced on 23 September 2026 that Private AI Compute, the company's platform for cloud-based AI processing, is getting persistent server-side memory. That breaks with the platform's previously strict stateless design — and it is wrapped in encryption whose keys are meant to exist only on the user's own devices.

The news

The Google Private AI Compute team announced the change in a blog post published on Google DeepMind's blog on 23 September 2026. At the same time, the company released an updated technical brief, a public log of the server software, and summaries of independent audits, according to coverage by Unite.AI (bbb59ce9).

Until now, the platform has been stateless: all context was deleted when a task was completed. Google says that interim workarounds, such as maintaining lists of personal facts and preferences, do not provide the context needed for continuous assistance. The new system is intended to let cloud-based AI retain context across sessions and devices (c923e0bd).

Coverage articles from Help Net Security and Unite.AI followed on 23–24 September 2026.

Background: half a year of cloud AI under wraps

Private AI Compute launched on 11 November 2025 in a post by Jay Yagnik, vice president of AI innovation and research, as a platform combining Google's Gemini cloud-based models with the security and privacy properties of on-device processing (bbb59ce9).

The platform runs on a combination of Google's own Tensor Processing Units (TPUs) and AMD-based Trusted Execution Environments, wrapped in what the company calls Titanium Intelligence Enclaves. With remote attestation, end-to-end encryption, and ephemeral processing, the solution was designed to simulate the privacy properties of local processing in the cloud (1324425c).

The first use cases were Magic Cue on the Pixel 10 and transcription summarisation in Pixel Recorder (bbb59ce9).

What is changing: from ephemeral to a per-user database

The core of the new system is a memory database called Oak Server — a "stateful per-user database" that runs in a hardware-based trusted execution environment (bbb59ce9).

The memory records are stored in dedicated, encrypted storage. The cryptographic keys that unlock them are to be held exclusively on the user's devices. Google says this makes the data inaccessible to everyone else, including the company itself — but that is a vendor claim, not an independently verified fact (c923e0bd).

How the security mechanism is supposed to work

The memory application is written in Rust and runs in the Oak Containers runtime. Both the server and the runtime are open source. Reproducible builds tie the published source code to the binaries that run in production: the resulting digests are published in an append-only ledger that cannot be altered retroactively, and the enclave attests that it is running the correct software before any key is released (bbb59ce9).

In practice, that means three layers: the developer cannot hide what the code does (open source), operations cannot swap out the binary covertly (reproducible builds with a public log), and key release requires cryptographic proof that the enclave is running the approved version.

Verification and external review

Devices that use Private AI Compute are to be able to verify that the server software is authentic and unmodified before personal data is sent (c923e0bd).

Google has also published a set of verification artefacts: the updated technical brief, a tamper-proof public log of the server software, audit results from an independent party, and community review of the security evidence (c923e0bd).

NCC Group, an independent security firm, conducted an assessment of Private AI Compute from spring to autumn 2025, covering architecture, cryptography, and underlying code (1324425c). But that assessment predates, chronologically, the announcement of the memory feature, and the sources do not establish that the audit covers the new persistent memory specifically.

Where the limits are

Several caveats are worth highlighting:

• "Inaccessible even to Google" is a claim from the company, not an independently verified property. The underlying Google documents and architecture are not available in the sources.
• Cross-device scenarios are future use cases, not launched features. Google highlights examples such as viewing assembly instructions from smart glasses on a laptop, or resuming conversations across mobile and web — but the timing or availability of these features is not known (c923e0bd).
• The scope of the NCC audit relative to the memory feature is unclear. The audit took place in 2025, before the announcement.
• Some technical details come from Unite.AI, whose articles carry an AI-generated byline ("Jonas Reeve, AI Research Agent"). The details match the other coverage, but should be corroborated against Google's own documents.

What this means

As AI assistants are expected to become more useful, they need to remember more. Current solutions based on local lists and fact databases have limits in both volume and context. Persistent memory in the cloud, combined with encryption whose keys live only with the user, is an attempt to resolve that trade-off.

Whether it actually holds up in practice — and whether NCC Group's audit will be supplemented to cover the new memory feature — remains to be seen. At minimum, Google has set a precedent by publishing source code, build logs, and audit summaries that allow others to examine the claims.