Skip to content

SYSTEM Cited by 2 sources

WhatsApp Private Processing

Private Processing is Meta's confidential-computing infrastructure that lets WhatsApp users invoke AI features (initially message summarisation + writing suggestions) over end-to-end-encrypted conversations without Meta, WhatsApp, or any third-party intermediary seeing the plaintext. Announced 2025-04-30, with launch projected "in the coming weeks" from that date.

Architecture (six-phase session flow)

Private Processing's wire architecture chains four independent primitives so that breaking any single one still fails closed:

  1. Authentication — the device obtains anonymous credentials via Meta's Anonymous Credential Service (ACS) that prove the caller is an authentic WhatsApp client without identifying the user.
  2. Third-party routing + load balancing — the device fetches HPKE public keys from a "third-party CDN" to enable Oblivious HTTP (OHTTP).
  3. Wire session — device establishes an OHTTP connection to a Meta gateway via a third-party relay. The relay sees the client IP but not the inner request; the gateway sees the inner request but not the client IP — this is the core non-targetability primitive.
  4. Application session (RA-TLS) — device and the target CVM establish a Remote Attestation + TLS session. The TEE attestation is cross-checked against a third-party ledger of acceptable CVM binary digests before the client releases its session key (patterns/protocol-algorithm-negotiation).
  5. Request — the device encrypts its payload (e.g. the messages to summarise) end-to-end between device and Private Processing with an ephemeral key only the device and the pre-selected CVM hold. Neither Meta, WhatsApp, nor the relay/CDN can decrypt.
  6. Response — processed output is returned under the same ephemeral key. After the session completes, Private Processing "does not retain access to messages"; CVMs do not persist to disk or external storage.

CVM-to-CVM calls (when one CVM must call another to complete the work) ride the same RA-TLS primitive that clients use.

Foundational requirements (five stacked)

  1. Confidential processing — no other system (Meta / WhatsApp / third party) sees data in processing or in transit.
  2. Enforceable guarantees — modification attempts fail closed or become publicly discoverable via the transparency log.
  3. Verifiable transparency — external researchers can audit: CVM image binary will be published; attestation-verification + load-bearing code open-sourced; Bug Bounty expanded to Private Processing; detailed security engineering design paper promised at launch.
  4. Non-targetability — an attacker cannot target a particular user without attacking the entire Private Processing system.
  5. Stateless processing + forward security — no retained access after the session, so a later CVM compromise cannot recover historical messages.

Threat model (Meta's canonical structure)

Assets — messages (in-flight + draft), the CVM's Trusted Computing Base, underlying hardware, cryptographic keys in transit. Threat actors — (1) malicious/compromised insiders with infrastructure access; (2) third-party / supply-chain vendors with component access; (3) malicious end users targeting other users. Named scenarios — (a) external actors exploit the product attack surface or compromise services inside CVMs (incl. prompt injection); (b) observability side-channels leak messages; (c) insiders tamper with the CVM at boot or runtime.

Disclosed operational controls

  • Hardened containerised binaries inside the CVM (cap blast radius on exploit).
  • Log-filtering system — only allow-listed log lines (e.g. error logs) exit the CVM; addresses the observability-vs-confidentiality tension.
  • Restricted-environment multi-party-reviewed CVM build — supply-chain defence.
  • Third-party log of CVM binary digests + published CVM image binary — transparency-side companion to attestation.
  • Encrypted DRAM + standard physical datacentre controls — hardware / physical-access defence.
  • Remote shell access prohibited (including from the host machine).
  • OHTTP relay for routing — non-targetability.
  • Enhanced host monitoring — abuse detection outside the CVM without observing its contents.
  • Novel-vulnerability tracking + continuous internal + external audits.

Three user-level principles (above the infrastructure)

  • Optionality — all AI features including Private Processing are optional.
  • Transparency — features that use Private Processing are identified as such.
  • User control — WhatsApp's Advanced Chat Privacy feature lets users disable AI features per-chat (e.g. the @Meta AI mention).

What's not disclosed

  • TEE vendor (AMD SEV-SNP / Intel TDX / Arm CCA not named).
  • Confidential-GPU vendor/mode ("Confidential Compute mode GPUs" only; NVIDIA Hopper CC is the obvious candidate but is not named).
  • Specific attestation protocol (RA-TLS is named; underlying attestation claims format is not).
  • Third-party relay + CDN + ledger operators are unnamed (only "a third-party…").
  • Production numbers (latency, throughput, CVM fleet size) — this is an architecture preview, not a retrospective.
  • Prompt-injection-specific defences — flagged as a threat class, but only generic TEE mitigations are listed.

Positioning

Private Processing is the canonical wiki instance of the TEE-for-private-AI-inference architectural pattern: a structural alternative to both on-device inference (too constrained for large models) and standard server-side inference (breaks E2EE). It composes the concepts/confidential-computing primitive with the OHTTP + anonymous-credential unlinkability stack and a published binary ledger so that the trust statement "Meta cannot see your messages" is backed by mechanism, not just policy.

Extension: Private Processing for AI Glasses (2026-09-24)

In September 2026 Meta extended Private Processing from WhatsApp AI to AI glasses, and in doing so broadened the system from a WhatsApp-specific feature into Meta's general confidential-computing infrastructure for AI workloads (Source: sources/2026-09-24-meta-bringing-private-processing-to-meta-ai-glasses). The glasses deployment reuses the same five-requirement backbone (hardware isolation, fail-closed guarantees, public verifiability, non-targetability, encrypted storage), the same RA-TLS-attested-against-a-public-ledger session gate, and the same OHTTP-relay + anonymous-credential non-targetability stack. Three things are new or newly-concrete:

  1. Stateful, always-on, agentic assistant is the forcing function. Glasses need an assistant that is "stateful and deeply personal — understanding your context, connecting ideas across days or weeks, and working proactively in the background." This is a step beyond WhatsApp's discrete summarize-this-message tasks and is what drives the two additions below.
  2. Storage engine inside the TEE. Rather than encrypt-then-store-in-a-normal-DB (which leaks access patterns and doesn't scale for encrypted vector search / multi-session joins), Meta builds the storage engine inside the CVM boundary so state is stored — not just processed — confidentially, co-locating execution and state in processor-encrypted memory. Persisted output is encrypted with user-provided keys before leaving the TEE.
  3. Out-of-band observability. Because engineers cannot attach a debugger, dump memory, or log model I/O inside the TEE, the observability layer relies on aggregate health signals only (CPU / memory / latency / hardware-failure rates) — enough to run a fault-tolerant multi-regional system "without ever exposing a single byte of user data."

Newly-concrete disclosures vs the 2025 WhatsApp post: the OHTTP relays are named (Fastly, Cloudflare); an independent auditor is named (NCC Group); the trust boundary is explicitly stated to span host CPUs and GPUs so a workload needing both stays inside it; and inter-model (TEE-to-TEE) calls must attest over the same RA-TLS protocol. Meta positions this as the foundation for an "increasingly stateful, multimodal, and agentic" future in which an agent holding sensitive state requires strict isolation, verifiable data provenance, and inter-CVM communication.

Seen in

Last updated · 766 distilled / 2,225 read