Privacy has to follow the context
Meta’s September 23 announcement makes a strong claim about one part of AI glasses: context sent to its Private Processing service will run inside a protected cloud environment that Meta says it cannot read. The claim matters. Glasses become useful to an assistant precisely because they can gather context without asking someone to pull out a phone. But that same convenience creates a broader privacy problem than a cloud server can solve.
My test for a wearable privacy promise is whether it follows information from the moment a person decides to use a feature through capture, transmission, inference, memory and any later use. Meta’s announcement addresses the middle of that path in unusual technical detail. It says less about what the glasses capture, how a wearer or nearby person can tell when context is being sent to AI, or how a long-lived memory can be inspected and deleted.
This is a distinction between a security control and a complete product promise. A confidential-computing system can reduce who is able to see data while a model processes it. It cannot establish that the right data was captured, that everyone affected understood what was happening, or that every later data path uses the same protections.
Meta’s own explanation starts with the device’s physical limits. Simple actions such as placing a call or answering a text can happen on the glasses, the company says. More capable models and assistants that connect context across days or weeks need more computing power than a pair of glasses can carry, so some work must move to the cloud. Private Processing is Meta’s answer to that trade: more computation without giving the infrastructure operator ordinary access to the information being processed.
What the enclave is designed to protect
The system Meta describes uses confidential virtual machines, or CVMs, running in hardware trusted execution environments (TEEs). In broad terms, the hardware isolates a workload and encrypts its memory so that the host operating system, hypervisor and data-center operators sit outside the intended trust boundary. Meta says its glasses implementation extends that boundary across CPUs and GPUs.
The client is supposed to check the server before sending context. Meta says the server provides a hardware-signed remote-attestation report that identifies the software image running in the CVM. The glasses compare its binary hashes with a public transparency ledger. If the hardware certificate or recorded measurement does not match, the connection fails and the client sends no data.
Meta also describes separating identity from routing. Anonymous credentials are fetched on randomized schedules, it says, and requests pass through a third-party Oblivious HTTP relay operated by Fastly or Cloudflare before reaching a TEE selected without user-identifying information. Meta says the relay and its own authentication service therefore cannot simply attach an account identity to a particular workload. If one model needs to pass information to another, the company says those services must attest to each other as well.
These mechanisms address a specific threat: someone with privileged access to the ordinary server stack reading or silently changing a workload that handles user data. A public record of software measurements can also make a changed binary easier to detect. That is a real advance over a promise that asks customers to trust a cloud provider’s internal access policy alone.
But an attestation proves a bounded thing. It can show that a particular measured workload is running on a supported hardware platform and that the client accepted its measurement. It does not, by itself, prove that the workload’s policy is adequate, that the client software handles every sensor correctly, or that no other product path receives related information. Nor does a public ledger make proprietary code self-explanatory. The guarantee depends on what is measured, what is excluded, and who can inspect the implementation.
The independent audit is useful—and limited
There is an independent technical review of an earlier version of Meta’s approach, but it is important to describe its scope accurately. NCC Group assessed WhatsApp’s message-summarization service in 2025, not AI glasses and not the system Meta announced in September 2026. The firm says its work involved 115 person-days, source-code review, some dynamic testing and interaction with development deployments.
NCC Group reported 21 findings. By the end of its engagement, 16 were fixed, one low-risk issue remained for planned development, and four findings were risk-accepted. Among the examples it discusses are a hypervisor-provided network interface that could expose a path for data exfiltration, a missing freshness check that could allow an old image to be used, and a key-configuration concern. Those examples were addressed during the review, according to the report. The review is evidence that the earlier system could be examined and improved; it is not a certification of the glasses design.
The report also explains why “confidential” does not mean “risk-free.” NCC Group did not audit the procedures of important third parties such as Fastly and Cloudflare. It said users still had to trust controls around signing keys and artifacts that were not open source, and that traffic analysis remained a possible source of inference. The assessment also noted that no system can fully cover unknown hardware or firmware exploits. Its conclusions apply to the WhatsApp service and the review’s particular scope, not automatically to every later deployment.
Meta says it is working with independent security firms, including NCC Group, on Private Processing and is expanding its bug bounty to cover the glasses implementation. That is a useful path for outside scrutiny. The September announcement did not include a completed glasses-specific audit or a date for consumer availability, however. It also did not identify the first glasses models, regions or features that will use the service.
The company describes an operational cost of its approach, too. If engineers cannot inspect memory, payloads or ordinary execution traces inside the enclave, they must maintain the service using aggregate health information such as CPU use, memory allocation, network latency and hardware failure rates. That protects content from routine inspection, but the announcement provides no measurements showing the system’s latency, throughput or reliability. The trade is visible; its practical cost is not yet quantified.
Memory raises the stakes
The most consequential part of the announcement may be the move from one-off questions to persistent context. Meta says a feature that needs to remember information can store it encrypted with a key supplied by the user before it leaves the TEE. Its infrastructure would hold ciphertext, which Meta says is only accessible inside the protected environment when a user later asks to retrieve a memory.
That design could make a personal assistant more useful. It could also turn an occasional request into a record that spans many situations. The September post does not explain how people will review, edit or delete individual memories, how they recover access if they lose a device, or how long deletion takes. Those are not small settings questions: they define whether a person can understand and control the history the system is asked to keep.
Meta’s technical white paper documents its earlier WhatsApp Private Processing service and helps explain the design lineage. It does not fill in those missing glasses-specific details. The paper discusses optional web search in that WhatsApp system, for example, where a query may leave the TEE for a search provider. That does not establish that glasses will use the same route. It does show why a reader needs a map of each service boundary rather than one label applied to an entire product.
The boundary before the cloud still matters
The gap is clearest when gallery recording is separated from an AI request. Meta’s July FAQ says the camera’s capture light blinks when content is recorded for the wearer’s gallery, and that the camera disables if the light is blocked or tampered with. The company also says gallery files stay on the glasses until the wearer imports them to a phone. Those statements describe the gallery-capture controls. Meta’s September engineering post describes context sent to cloud inference. It does not spell out every device-side state change that separates the two paths.
That distinction matters to people near the wearer as much as to the wearer. A bystander cannot check a server attestation or decide whether the code running in a TEE matches a transparency entry. A cloud enclave therefore cannot provide notice or consent at the moment a camera or microphone gathers context. The engineering control and the social problem sit at different points in the chain.
The concern is not hypothetical, but the evidence must be kept in its proper lane. The Los Angeles Times reported in September on a proposed class-action lawsuit in which more than 70 people alleged that sensitive footage from Meta glasses had been captured without awareness and exposed to overseas review contractors. The report includes Meta’s response: the company says it may review AI data to improve its products and applies filters intended to protect privacy. These are disputed allegations, not a court finding. They do not show that Private Processing was breached or that the disputed footage passed through it.
They do make one boundary question hard to avoid: what information travels through the enclave, and what remains in other capture, review or product-improvement workflows? An attestation can tell a client which measured workload it connected to. It cannot answer that question unless the product also identifies the paths and makes their rules visible. This is where broad language about private processing needs a feature-by-feature explanation.
A better standard for wearable privacy
Meta’s design is a meaningful infrastructure control, and the distinction matters. If implemented as described, hardware isolation, remote attestation and public software measurements can constrain access to data while it is being processed in the cloud. The WhatsApp audit offers a bounded example of how an earlier system was tested and where residual trust remained. Neither source establishes that every privacy question about AI glasses is solved.
I would judge the product by whether a person can follow one piece of context end to end: what the glasses sensed, what the wearer asked the assistant to do, what left the device, which service processed it, whether it entered memory, and whether a human or model-training workflow could later receive it. The public should be able to distinguish those states without reading a cryptographic ledger, and independent reviewers should be able to inspect the glasses implementation rather than infer its behavior from a related service.
The evidence that would change my view is concrete: a published glasses-specific security assessment, a clear map of sensor and cloud-processing states, and user-facing controls that explain memory scope, access, recovery and deletion. Until those are available, Private Processing should be understood as a strong protection for a defined cloud workload—not a complete answer to the privacy questions posed by a computer worn on someone’s face.