Meta's engineering team has published an architectural account of Private Processing, the confidential-computing system it is extending from WhatsApp and the Meta AI app to AI Glasses, describing how the company intends to run stateful, personalized AI workloads — streaming transcription, contextual search, long-term recall — in the cloud without Meta itself being able to read the underlying data. The post, credited to Pritam Shah and Oskar Linde on Meta's engineering blog, frames the problem plainly: glasses can't host models large enough for these features locally, so the compute has to move to the cloud, and the cloud has to be redesigned so it can't see what it's processing.
The mechanism rests on trusted execution environments, or TEEs — hardware in certain CPUs and GPUs that encrypts the memory of a confidential virtual machine (CVM) under a key held by dedicated silicon, never released to the host OS, hypervisor, or infrastructure operator. Meta's post cites the Confidential Computing Consortium's three guarantees for this model: data confidentiality (no one outside the CVM can read memory in use), data integrity (no one outside can alter it), and code integrity (no one can modify running code). Before a glasses device sends any personal context, it performs remote attestation over TLS — demanding a hardware-signed certificate from the server's TEE, then cross-checking the TEE's binary hashes against what Meta calls an independent, public transparency ledger. If the vendor certificate check fails or the hash doesn't match the ledger, the post states, the handshake fails and the device does not connect.
The routing layer is built to prevent Meta's own infrastructure from linking a request to an identity. Per the post, devices use anonymous credentials — blind-signed tokens fetched on randomized schedules — so the authentication service cannot tie a request back to an account, then connect through a third-party OHTTP relay (the post names Fastly or Cloudflare) to select a TEE node using non-user-identifiable heuristics. This is the "non-targetability" property Meta lists as one of five engineering requirements for the system, alongside hardware isolation, fail-closed guarantees, public verifiability, and encrypted storage.
Persistent memory — the feature that lets an assistant recall something from an earlier session — is handled by putting the storage engine inside the TEE itself rather than in an external encrypted database. Meta's post argues this design choice is forced by two failure modes it identifies in the conventional approach: access-pattern leakage, where even strongly encrypted databases still reveal when and how often a user queries them, mapping daily behavior through metadata alone; and scaling collapse, where semantic vector search or multi-session joins over encrypted storage require pulling ciphertext across the network and decrypting it per query, causing "latency spikes" as context grows. Co-locating execution and state inside processor-encrypted memory, the post says, means reads never cross an external network boundary.
The operational cost of this design shows up in observability, and the post is candid about it. Standard engineering diagnostics don't work inside a TEE: no attaching a debugger, no memory dumps on crash, no inspecting the payload that triggered a fault. Meta says it built its monitoring around aggregate health signals only — CPU utilization, memory allocation, network latency, and hardware failure rates — meaning engineers troubleshoot a production system for AI Glasses queries without ever seeing a request that fails.
The post names no benchmark numbers, no latency figures, no cost or parameter counts for the models running inside these CVMs — an omission notable for a piece pitched at scale claims. What it does commit to is third-party validation: Meta says it partners with independent security firms including NCC Group to audit the attestation logic and isolation model, and is expanding its Bug Bounty program to explicitly cover Private Processing on AI Glasses, providing external researchers with CVM binaries and documentation to test the attestation chain. The post also flags where the design is still aspirational rather than shipped: it describes Private Processing to date as handling "discrete tasks, like summarizing a message," while framing multi-session, agentic use — an agent holding sensitive state across real-world contexts — as a future extension requiring inter-CVM attestation that isn't fully specified here.
For teams building split on-device/cloud inference for wearables, the operational lesson is less about the crypto primitives and more about the debugging tax: if your trust boundary excludes your own engineers from inspecting live payloads, your incident response has to be redesigned around aggregate telemetry before you ship, not after the first production fault.