Page 15 of Meta's Private Processing whitepaper, updated March 16 (printed page numbers; the PDF runs three ahead): "Orchestrator binaries are stateless by design with no database access." Page 6: "The TEE does not manage any storage," the TEE being a trusted execution environment, an enclave sealed off from the machine's own operator. Meta's September 23 post bringing Private Processing to its AI glasses cites that whitepaper as its threat model, then says "Meta's infrastructure stores the ciphertext," decrypted when "your device provides the key."
Part 4 of six on the Connect 2026 documents; part 3 read the 9.25-millisecond hearing loop as a limit set by the glasses' frame.
TL;DR
- Meta's September 23 Private Processing design keeps AI-glasses memory on Meta's servers, encrypted under a key from the user's device.
- Meta has not said how the glasses' memory key survives a lost device, or what its servers see when memory loads.
- No Meta document says whether Muse on Meta's glasses runs on Private Processing or in a cloud VM Meta can access when necessary.
- In my view, the moat in cloud-kept glasses memory is key custody plus the enclave fleet that honors it, and on-device-context startups lose privacy as their argument for local memory.
What was Private Processing built to do?
To forget. The Private Processing whitepaper (opens in a new tab) is written for WhatsApp: the phone resends the history "with every request," and Private Processing "must not retain access to messages once the session is complete" (page 3), so a confidential virtual machine (CVM) broken tomorrow yields nothing from today.
Meta's glasses post (opens in a new tab) gives the same platform a stateful mode: "Query engines run directly within the TEE boundary." Wired reported that Private Processing is not on the glasses yet; Pritam Shah, a co-author, "doesn't have a timeline."
Meta's documents keep little on the frame: commands such as placing a call or answering a text "occur entirely on device" (the glasses post), the glasses "activate when they detect the wake word" (the voice notice), you wake Muse "by saying its name" (the Muse glasses page), and even captions and translation "may be processed on your AI Glasses, in the Meta AI App or on Meta servers" (the privacy policy). Listening for the wake word stays on the face; remembering leaves it.
Who holds the key?
Your device, per Meta's few published clauses: memory is "encrypted with user-provided keys" and read when "your device provides the key." The post never says how the key is made, whether "your device" means glasses or phone, or what happens when it is gone. Meta now holds the whole history, so the key is the memory.
Meta has an answer for chats: its Backup Key Vault, described May 1, keeps recovery codes in hardware security modules "inaccessible to Meta, cloud storage providers, or any third party." The glasses post never mentions it; a recall feature whose key dies with a lost, reset or replaced phone is a demo.
What the host can still see
Meta's post states the problem: an external encrypted database "still observes when you read and write data, how frequently you query it, and which records are accessed together." Its fix runs the query engine inside the enclave, but each session still loads the ciphertext and writes back changes, events on that list (my reading).
Opal, a UC Berkeley and Google DeepMind paper (arXiv:2604.02522 (opens in a new tab)), hides access patterns with ORAM (oblivious RAM), touching a fixed number of blocks per access. On a 4 GB Intel TDX enclave, Opal answers a query in 2.32 seconds against 1.48 for the same pipeline on plaintext storage, so encryption plus obliviousness costs at most 2.32 - 1.48 = 0.84 seconds (my arithmetic), less than the 1.15 seconds its model calls take. The catch is the threat model: "We focus on access-pattern leakage outside the enclave, assuming the enclave itself is uncompromised." ORAM hides which blocks a query touches, not when a store loads or how long a request runs.
Meta's post names no ORAM, fixed access budget or padding, yet promises no one can target "a specific individual's session or storage." A store cannot be anonymous to itself: unless reads are oblivious, every read under your ciphertext's stable handle ties your sessions together.
Which lane does Muse take from the glasses?
Meta has not said. Superpower Daily counted three processing paths on September 24 and asked what leaves the protected environment when the agent calls a model. Meta's September 8 Muse safety post (opens in a new tab) never mentions glasses or Private Processing. Muse lives on "your own dedicated computer in the cloud," which today "does not prevent Meta from accessing data when necessary to support, secure or operate the service"; a Confidential VM is due "later this year." Private Processing puts the model inside the TEE; Muse "sends limited data out of the VM when necessary for inference."
A Confidential VM would protect the storage, but today's model call leaves the VM carrying what the same post calls inference data, "the back and forth conversations between you and your Muse and the tool calls and subagent handoffs that result," and the post is silent on whether the Confidential VM changes what that call carries. For an agent the model call is where memory goes: whatever Muse wants the model to use has to be in the prompt, and Meta's developer pages list a 1M-token context window for Muse Spark 1.3. Every call leaves through what the Muse post calls "Proxies for inference and telemetry." Wired credited Confidential VM with "a similar promise"; similar about storage, and as published, different about inference.
Where the moat went
So yes, Meta's cloud can remember what it cannot read; encryption is the easy part. The moat is key custody plus attested enclaves that store and search at glasses scale, which per Meta's documents takes AMD SEV-SNP confidential VMs with NVIDIA H100s, third-party OHTTP relays and a transparency log, and outside audits (NCC Group alone spent 115 person-days on the WhatsApp version). Opal prices its own version at a million users: about $1.4 million a year for its oblivious design against $21 million for one that loads each store whole. A rival must run every piece to make the same promise.
On-device-context startups betting Meta and Google would keep memory local for privacy have lost that argument: Google moved Private AI Compute to cloud memory under keys "held exclusively on your personal devices" the day Meta's glasses post went up.
Dated calls:
- By December 31, 2026, Muse Confidential VM is still limited to testers: no Muse user in any market can turn it on without an invitation, Meta's "later this year" notwithstanding.
- On June 30, 2027, Muse runs on Meta's AI glasses in at least one market, and no Meta document yet says any glasses feature runs on Private Processing.
- Before any glasses memory feature on Private Processing is generally available, Meta documents lost-phone key recovery for it through the Backup Key Vault it runs for chat backups, with a user-set recovery code or passkey (by December 31, 2027).
- That feature's documentation names no ORAM or fixed access budget for its ciphertext store (by its general availability or December 31, 2027).
Grading two of my own calls
In June, calling Muse Spark a model built from the battery up, I wrote that "the winners in wearable AI will be the teams that never started from the cloud," and my exemplar was "Multi-agent reasoning at inference time, on a chip in a glasses frame." Meta's September 23 post now says advanced glasses features need models "far larger than can be packed into a pair of glasses," and the agent runs in a cloud VM. That exemplar is a miss.
My on-device memory call in July held that "the moat moves upstream to the context layer - the on-device personal knowledge graph that takes months of daily wear to build." Meta confirms the first half, arguing that an assistant gets "more useful" as "it learns your style, preferences and context," and reverses the second: the context sits on Meta's servers and only the key on the device. I grade it partial. Unlike the hearing loop, memory has no deadline, so it went to the datacenter with the model that reads it.
The question for anyone selling private memory, Meta included, is the one the glasses post skips: when the phone that holds the key is gone, who gives the memory back?