Products & Tools

Google Adds Encrypted Persistent Memory to Private AI Compute

Google will add encrypted persistent memory to Private AI Compute, with cryptographic keys held only on user devices — making stored AI context unreadable even to Google itself.

Advancing Private AI Compute with secure, server-side memory
Advancing Private AI Compute with secure, server-side memoryAI-generated
By James Calloway5 min read

Updated

Why it matters

  • Google is adding a persistent, encrypted server-side memory layer to its Private AI Compute platform, with decryption keys held exclusively on users' personal devices.
  • The cloud memory works via end-to-end encrypted channels to isolated secure enclaves that decrypt data only temporarily in memory, then immediately re-encrypt it.
  • Alongside the update, Google is publishing a tamper-proof public record of its server software and the results of an independent cybersecurity audit, inviting the privacy community to verify the platform's protections.

Google says it has solved one of the hardest problems in personal AI: how to give an assistant long-term memory that spans devices without moving the privacy boundary off your phone. In a technical update published today, the company detailed how it will add a persistent, server-side memory layer to its Private AI Compute platform — one that keeps decryption keys exclusively on a user's personal devices, making stored data inaccessible to anyone else, "even Google."

The announcement addresses a structural tension that has defined consumer AI privacy since the arrival of large language models. Local, on-device processing has historically been the gold standard for privacy. But frontier AI models, Google notes, often require far more computing power than any single device can provide. The company frames its new architecture as the resolution to that dilemma: "how to give an assistant long-term continuity across devices while upholding the strict privacy standards typically limited to on-device processing."

How the memory layer works

Google describes the new persistent memory as functioning "like a secure digital vault in the cloud." Under the model, the information an assistant needs to help a user is sealed within dedicated, encrypted storage. The cryptographic keys required to unlock that storage never leave the user's personal devices. The result, according to the company, is data that is inaccessible to outside parties — including Google itself.

The mechanics matter here. When an AI model needs to access stored information, an authenticated, end-to-end encrypted channel connects the user's device to a protected, isolated environment in the cloud — a "secure enclave." That enclave temporarily decrypts the data in isolated memory to process the request, saves any new context, and immediately re-encrypts it. From the user's perspective, Google says, the information stays as protected as if it never left the device.

This is a significant departure from how cloud AI memory typically works. Most commercial assistants that remember user context store it in conventional server-side databases, where the provider can read it. Google's design instead makes the cloud a dumb, locked container — the intelligence of the key management sits on the client side.

Why statelessness was the bottleneck

Private AI Compute is not new. Google previously introduced the platform to let users process complex tasks in hardware-isolated cloud enclaves. But the technology — along with, the company notes, similar solutions across the industry — has been strictly "stateless." Every session wiped all context the moment a task ended.

That limitation has real consequences for product experience. A stateless assistant cannot recall a conversation from yesterday, let alone carry context from your laptop to your phone. Google acknowledges that existing workarounds, such as having AI save a list of personal facts and preferences, "aren't enough to support the rich, continuous experiences people expect from personal AI." The engineering challenge was finding a way for cloud-scale AI to securely retain context over time and across devices without weakening the privacy guarantees.

The use cases Google points to are cross-device ones: pulling up assembly instructions on a laptop that you previously viewed through smart glasses, or resuming complex conversations between mobile and web. Persistent memory is what makes that kind of continuity possible — the assistant keeps "the pieces it needs to remember safely locked away," as the company puts it.

Transparency measures: a tamper-proof record and an audit

A memory system is only as trustworthy as users believe it to be, and Google is treating that as an engineering problem in its own right. "Building that trust starts with transparency," the company writes.

Alongside an updated technical whitepaper, Google says it will publish a tamper-proof public record of its server software. Devices running Private AI Compute will be able to verify that the software is authentic and unaltered before sending any personal data. That is a meaningful commitment: remote attestation of this kind would let third parties — not just Google — confirm that the enclave code running in production matches what the company claims.

Google is also providing an update on its technical methods, including the results of an independent audit conducted by what it describes as a leading cybersecurity firm. The company did not name the auditor in the announcement. By releasing these resources, Google says it wants to invite the broader privacy community to verify Private AI Compute's protections for themselves.

The company has also published an updated Private AI Compute Technical Brief covering its system architecture, security proofs, and verification protocols.

The competitive and policy stakes

The announcement lands at a moment when AI memory has become a differentiating feature across the industry. Assistants that remember user context promise more useful, continuous help — but they also concentrate large volumes of personal information in provider-controlled infrastructure. Google's bet is that cryptographic architecture, rather than policy promises, is the way to make that trade acceptable to users and regulators.

The framing is notable: "Adding private, persistent memory to Private AI Compute shows how deeply personal assistance can be private by design." That language — privacy by design — carries weight in regulatory contexts, particularly in Europe, where data protection law requires such safeguards by default. A memory system where the provider demonstrably cannot read the data is a stronger guarantee than any privacy policy.

Google credits the research to a cross-company effort. The work was co-developed by Google DeepMind, Platforms & Devices, and Core and Cloud teams, with executive sponsorship from Four Flynn, Jay Yagnik, and David Kleidermacher.

What to watch

The announcement is a technical update, not a product launch — Google says the memory layer "will enable" persistent cross-device AI memory, indicating the capability is still being rolled into the platform. The open questions are the ones Google itself has invited: whether the security proofs and verification protocols hold up under scrutiny from the privacy community, and whether the independent audit's results match the guarantees the architecture claims. The company has now put its server software on the public record; the next test is whether outside cryptographers and security researchers accept the invitation to check the math.

Original: blog.google

Share this article:

More from James Calloway

James Calloway

Show full bio

News editor covering industry trends and analytics at AI In Context.

144 articles

Related articles

  1. Google's Decoupled DiLoCo Trains LLMs Across Data Centers 20x Faster
  2. Apple Confirms iOS 27 AI Features Will Ship With Usage Limits
  3. Google Wants to Replace the Prompt With an AI-Powered Mouse Pointer
  4. OpenAI's 'Dreaming' memory system goes mainstream in ChatGPT
  5. Google DeepMind Launches AI Accelerator for Climate in Asia-Pacific

« Previous articleNext article »