Skip to content

META 2025-04-30

Read original ↗

Meta — Building Private Processing for AI tools on WhatsApp

Summary

A 2025-04-30 Meta Engineering Security post previewing Private Processing — the confidential-computing infrastructure WhatsApp is rolling out so users can invoke AI features (message summarisation, writing suggestions) over end-to-end-encrypted conversations without Meta, WhatsApp, or any third party seeing the plaintext. The architecture is built around a Trusted Execution Environment (TEE) — specifically a Confidential Virtual Machine (CVM) with Confidential-Compute-mode GPUs — and stacks five named security requirements on top: confidential processing, enforceable guarantees (hardware-rooted attestation), verifiable transparency (published CVM binary digests on a third-party ledger + open-sourced components + expanded Bug Bounty), non-targetability (attacker cannot route a specific user to a specific host), and stateless + forward-secure processing (no message retention after the session). The wire architecture chains anonymous credentials (via Meta's Anonymous Credential Service, open-sourced 2022), Oblivious HTTP (OHTTP) over HPKE through a third-party relay (Meta gateway does not learn client IP), and a Remote Attestation + TLS (RA-TLS) session whose attestation is cross-checked against the third-party binary ledger before any key material bound to Private Processing is released. Only after that check does the client encrypt its request with an ephemeral key that only its device and the pre-selected CVM hold. Extra operational discipline: log-filtering limits what can leave the CVM boundary; containerised hardened binaries inside the CVM cap blast radius on exploit; encrypted DRAM plus multi-party-reviewed build pipelines address physical + supply-chain threats; CVM-to-CVM calls reuse the same RA-TLS channel the client negotiated. The post is an architecture preview — no production numbers, no fleet size, no latency figures; a detailed security engineering design paper is promised at launch.

Key takeaways

  1. The whole design answers one question — can you run AI over E2EE messages without breaking E2EE? Meta's requirement posture is unusually explicit: "no one except you and the people you're talking to can access or share your personal messages, not even Meta or WhatsApp." Private Processing is Meta's attempt to add AI features to WhatsApp without weakening that invariant, by moving the trust boundary from "the server runs Meta's code" to "the server runs a specific, publicly-inspectable CVM binary image whose hardware attestation the client verifies before releasing the key". Canonical wiki statement of TEE-for-private-AI-inference as an architectural pattern distinct from federated learning and on-device inference (Source).
  2. Five named foundational requirements — stacked, not redundant. "Confidential processing" (no system outside Private Processing sees data in transit or in use); "enforceable guarantees" (modification attempts fail closed or become publicly discoverable via verifiable transparency); "verifiable transparency" (external researchers can audit); "non-targetability" (can't compromise one user without compromising the whole system); "stateless processing + forward security" (no retained access to messages after the session). These are not overlapping controls — each closes a distinct class of adversary move (run-time bypass, boot-time tamper, targeted-host compromise, post-session compromise) and together map cleanly to the threat model Meta describes. Canonical wiki instance of defense-in-depth for private-AI-inference (Source).
  3. Explicit threat model with three actor classes and named scenarios. Meta follows textbook threat-modeling structure — assets (messages in flight + in draft; TCB of the CVM; underlying hardware; cryptographic keys), threat actors (malicious/compromised insiders with infra access; third-party or supply-chain vendors with component access; malicious end users targeting other users), threat scenarios (product-surface exploitation incl. prompt injection; CVM message-extraction via observability side-channels; insider physical/remote access tampering with CVM at boot or runtime). For each, named mitigations — hardened containerised binaries, log-filtering, restricted-environment multi-party-reviewed builds, third-party binary-digest ledger for anomaly reports, novel-vulnerability tracking, encrypted DRAM, physical datacentre controls, OHTTP relay for route-level non-targetability. Canonical illustration that threat modeling is the structural spine of the post, not an appendix (Source).
  4. Wire-session chain: anonymous credentials → OHTTP (HPKE) → RA-TLS → ephemeral E2EE to CVM. Six phases disclosed verbatim: (i) authentication — Private Processing obtains anonymous credentials to verify the caller is an authentic WhatsApp client; (ii) third-party routing + load balancing — fetches HPKE public keys from a third-party CDN to support OHTTP; (iii) wire session — establishes an OHTTP connection from device to a Meta gateway via a third-party relay (the relay hides the client IP from Meta/WhatsApp); (iv) application session — establishes an RA-TLS session between device and TEE, attestation verification cross-checks measurements against a third-party ledger to ensure the code running satisfies the verifiable-transparency guarantee; (v) request — after the session, the device's message-summarisation (or similar) request is encrypted end-to-end between device and Private Processing with an ephemeral key Meta/WhatsApp cannot access; (vi) response — returned encrypted with a key only the device and the pre-selected Private Processing server hold; Private Processing does not retain access after session completion. CVM-to-CVM traffic (when one CVM must call another to complete the work) rides the same RA-TLS connection primitive (Source; patterns/attestation-before-session-key-release).
  5. Non-targetability has a named structural mechanism, not just policy. The threat Meta wants to kill is "can a well-resourced attacker route a specific user to a specific compromised hardware instance" — because if they can, the attack cost scales per-target rather than per-fleet. The countermeasure is OHTTP routing through a third-party relay + anonymous credentials for authentication inside OHTTP: "Meta and WhatsApp do not know which user is connecting to what CVM... a specific user cannot be routed to any specific hardware." Small-scale attacks cannot be used to target a specific user's data. Canonical wiki instance of concepts/non-targetability as a first-class security property distinct from confidentiality / integrity — and of patterns/third-party-ohttp-relay-for-unlinkability as its structural realisation (Source).
  6. "Verifiable transparency" has a concrete mechanism: publish a third-party ledger of acceptable CVM binary digests + publish the CVM image binary. Without this, attestation is "the server says its code hashes to X" — useful only if X is known-good. Meta's disclosure: "we will make available the CVM image binary powering Private Processing… we will make these components available to researchers"; attestation verification code and load-bearing code will be open-sourced; the Bug Bounty program is being expanded to cover Private Processing; a detailed security engineering design paper is promised. Canonical wiki instance of concepts/verifiable-transparency-log and patterns/publish-binary-digest-ledger as the transparency-side companion to hardware attestation (Source).
  7. Observability is treated as an explicit in-tension-with-confidentiality axis. Meta names the trade-off rather than eliding it: "Observability and debuggability remains a challenge in highly secure environments as they can be at odds with the goal of confidential computing, potentially exposing side channels to identify data and in the worst case accidentally leaking messages themselves." Their answer is a log-filtering system that permits only allowed log lines ("such as error logs") to leave the CVM boundary, and host-monitoring enhancements for abuse detection outside the CVM without observing its contents. The structural lesson is broader than WhatsApp: any TEE-based service at scale has to build an explicit allow-listed egress pipeline for telemetry, not inherit the standard "log everything then filter downstream" posture of most production services (Source).
  8. Stateless + forward secure is operationalised as a service property, not a policy. "We operate Private Processing as a stateless service, which neither stores nor retains access to messages after the session has been completed... Private Processing does not store messages to disk or external storage, and thus does not maintain durable access to this data." The architecture choice is load-bearing: once the session ends, the ephemeral key material for that session is destroyed (by being non-extractable from the CVM) and there is no disk-write path for message bodies to survive through. Canonical wiki statement of concepts/stateless-processing + concepts/forward-security in a TEE inference context — distinct from standard TLS forward secrecy because the inference state (not just the wire) is what's being forgotten (Source).
  9. Data minimisation is first-class: requests carry only what processing needs. "As part of our data minimization efforts, requests to Private Processing only include data that is useful for processing the prompt — for example, message summarization will only include the messages the user directed AI to summarize." This is explicit, not aspirational — the client sends the minimal set of ciphertext messages to decrypt-and-summarise inside the CVM, not the entire thread or history. Canonical wiki instance of concepts/data-minimization operationalised at the request/API layer of an AI inference service (Source).
  10. Opt-in and user-control are architectural, not just UX. Three user-level principles sit above the infrastructure: "Optionality" (AI features including Private Processing must be optional); "Transparency" (features using Private Processing must be identified as such); "User control" — WhatsApp's Advanced Chat Privacy feature lets users disable AI mentions (e.g. @Meta AI) in sensitive chats, preventing messages from being used for AI features at all. Advanced Chat Privacy is the pre-existing WhatsApp feature Private Processing composes with — it provides the opt-out at chat granularity, Private Processing provides the E2EE-preserving opt-in at request granularity (Source).

Architectural numbers + operational notes (from source)

  • Disclosed requirements: 5 foundational (confidential processing, enforceable guarantees, verifiable transparency, non-targetability, stateless + forward security) + 3 user principles (optionality, transparency, user control).
  • Disclosed threat-actor classes: 3 — malicious/compromised insiders; third-party / supply-chain vendors; malicious end users targeting other users.
  • Disclosed threat scenarios: 3 named + "not limited to" — product-surface exploitation (incl. prompt injection); CVM-observability-based message extraction; insider physical/remote CVM tampering at boot or runtime.
  • Disclosed wire phases: 6 — authentication, third-party routing + load balancing, wire session (OHTTP), application session (RA-TLS), request, response.
  • Named primitives: TEE, Confidential Virtual Machine (CVM), Confidential-Compute-mode GPUs, OHTTP, HPKE, RA-TLS, anonymous credentials, Anonymous Credential Service (open-sourced December 2022; engineering.fb.com/2022/12/12/security/anonymous-credential-service-acs-open-source/).
  • Named operational controls: containerised hardened service binaries; log-filtering system limiting CVM egress to allow-listed log lines; restricted-environment multi-party-reviewed CVM build process; third-party log of CVM binary digests + published CVM image binary; novel-vulnerability tracking; CVM input sanitisation; abuse-detection via enhanced host monitoring; encrypted DRAM; standard physical datacentre controls; remote-shell access prohibited (incl. from host machine); all code changes auditable + continuous internal audits + external security research.
  • First use case named: message summarisation + writing suggestions for drafts, both at users' direction. Meta explicitly anticipates "others where the same or similar infrastructure might be beneficial in processing user requests".
  • Open-source promises: components of Private Processing; attestation verification code; "certain… load-bearing code". Bug Bounty scope expanded to Private Processing. Detailed security engineering design paper promised.
  • No production numbers disclosed: no latency, no throughput, no CVM fleet size, no GPU model/class named, no TEE vendor named (the post is silent on whether the CPU-based confidential virtualisation is AMD SEV-SNP, Intel TDX, or other), no ledger technology named, no OHTTP relay operator named, no CDN operator named for HPKE keys, no concrete attestation-scheme named beyond RA-TLS, no inference-model details.
  • Timing: post dated 2025-04-30; launch projected "in the coming weeks".

Systems / hardware extracted

New wiki pages:

  • systems/whatsapp-private-processing — the overall Meta/WhatsApp confidential-computing infrastructure for AI features over E2EE messages. First user-facing use: message summarisation + writing-suggestion drafts. Chains anonymous credentials + OHTTP + RA-TLS + CVM + ephemeral E2EE in the flow described above. Canonical wiki instance on the TEE-for-private-AI-inference axis.
  • systems/cvm-confidential-virtual-machine — the CPU-based Confidential-Virtual-Machine primitive + Confidential-Compute-mode GPUs Meta builds Private Processing on. Neither CPU vendor nor specific technology is disclosed (AMD SEV-SNP / Intel TDX / other unnamed). Stub with links to the TEE concept + RA-TLS + attestation.
  • systems/meta-acs-anonymous-credentials — Meta's Anonymous Credential Service (ACS), open-sourced in December 2022 per Meta's earlier post, now load-bearing in Private Processing's authentication phase. Mints credentials that authenticate the caller as a legitimate WhatsApp client without identifying which user — a prerequisite for non-targetability once OHTTP strips the IP.
  • systems/whatsapp-advanced-chat-privacy — the pre-existing WhatsApp feature that gives users a per-chat opt-out for AI features; composes with Private Processing's opt-in. Stub.

Concepts extracted

New wiki pages:

  • concepts/trusted-execution-environment — TEE as the generic primitive class. Hardware-isolated execution context whose contents are not visible to the host OS, hypervisor, or (with confidential-VM variants) the cloud-operator control plane. Meta's CVM is a specific realisation.
  • concepts/confidential-computing — the umbrella industry term for the posture Private Processing takes: protect data in use via TEEs, not only in transit and at rest. Canonical wiki definition.
  • concepts/remote-attestation — the cryptographic primitive that lets a client verify a server is running a specific, known-good software image before releasing secrets. Hardware-rooted; bound to TEE instance identity.
  • concepts/ra-tls — Remote-Attestation + TLS: the composition in which the TLS handshake carries (or piggybacks) a fresh attestation of the server TEE's binary digest + instance identity, gated against a known-good ledger, so session key material is only released if attestation passes.
  • concepts/oblivious-http — OHTTP: HTTP over HPKE through a third-party relay; the gateway learns the request contents but not the client IP, the relay learns the client IP but not the request contents. The two-party-untrusted property is what enables non-targetability in Private Processing.
  • concepts/hpke — Hybrid Public Key Encryption (RFC 9180): the cryptographic primitive OHTTP uses to encrypt the inner HTTP exchange from client to gateway. Asymmetric-to-symmetric hybrid with forward-secure single-shot semantics.
  • concepts/non-targetability — security property distinct from confidentiality/integrity. An attacker must compromise the whole system (not a chosen user's hardware instance) for the attack to succeed. Meta's structural realisation: OHTTP + anonymous credentials + attestation-against-ledger.
  • concepts/stateless-processing — a service-level discipline whose load-bearing architectural consequence is that state cannot leak to a later session even if the service is later compromised, because it wasn't kept. Distinct from "logs are rotated" or "data is eventually deleted".
  • concepts/forward-security — in the Private Processing context, the property that future compromise of the CVM cannot recover past messages, because the ephemeral session keys were never extractable and are destroyed at session end. Sibling of TLS forward-secrecy, applied at the inference-state layer.
  • concepts/verifiable-transparency-log — the published third-party ledger of acceptable CVM binary digests that turns remote attestation's "the server hashes to X" into a verifiable "X is one of the binaries we said is running". Sibling of Certificate Transparency, Sigstore's Rekor, and binary-transparency efforts.
  • concepts/data-minimization — the discipline of sending only the data needed for the immediate processing step. Meta operationalises this at the request API: a summarisation request carries only the messages being summarised, not the full thread/history.

Extended (cross-link added on Seen in + related):

  • concepts/anonymous-credential — adds a second canonical industrial instance beyond Privacy Pass / ARC / ACT: Meta's ACS used for WhatsApp-client authentication in Private Processing without user identification.
  • concepts/end-to-end-encryption — extended with the private-AI-inference case where E2EE must be preserved across a server-side compute step, not just extended between clients.
  • concepts/threat-modeling — extended with the Meta Private-Processing instance: assets / actors / scenarios, with explicit generalisation to AI-specific attack classes (prompt injection).
  • concepts/defense-in-depth — extended with the Private-Processing layering (hardened containerised binaries + log-filtering + encrypted DRAM + OHTTP relay + third-party binary ledger + Bug Bounty / open-source + expanding Abuse detection via host monitoring outside CVM).

Patterns extracted

New wiki pages:

  • patterns/tee-for-private-ai-inference — the architectural pattern: move LLM inference for private user content into a confidential-computing TEE whose binary digest is published on a third-party ledger and verified by client attestation before the inference key is released, preserving E2EE across the server-side compute step. Meta's Private Processing is the canonical wiki instance.
  • patterns/third-party-ohttp-relay-for-unlinkability — the pattern of routing client requests through an operated-by-a-different-party OHTTP relay so that the provider gateway never learns client IP. Essential for non-targetability when the provider also operates the TEE fleet: even if the provider wanted to route a specific user to a specific CVM, it doesn't know who the requester is.
  • patterns/attestation-before-session-key-release — the pattern of gating the TLS/session key agreement on a successful attestation verification against a known-good ledger. Without this, the TEE is only trusted by assertion; with it, a compromised or swapped-in binary fails closed because the client refuses to release its ephemeral key.
  • patterns/publish-binary-digest-ledger — the transparency-side companion to attestation: publish a third-party log of every acceptable CVM binary digest so external researchers can detect "the server says it's running binary X, but X was never published" or "X was published but was never reviewed". Structural sibling of Certificate Transparency for TLS certificates.

Caveats + what's missing from the post

  • Architecture preview voice. No production deployment data. No end-to-end latency. No throughput numbers. No CVM fleet size, shape, or topology. No GPU model or class named (only "Confidential Compute mode GPUs"). No CPU TEE vendor named (AMD SEV-SNP, Intel TDX, Arm CCA — all plausible; post doesn't say).
  • Third-party operators unnamed. The OHTTP relay operator is named only as "a third-party relay"; the HPKE-key CDN is named only as "a third-party CDN"; the binary-digest ledger is named only as "a third-party ledger" / "a third-party log". These are load-bearing choices for the non-targetability + verifiability guarantees — each operator is part of the TCB's adversary-model partition — but no names are given.
  • Attestation primitive details not disclosed. "Remote Attestation + TLS (RA-TLS)" is named, but the specific attestation protocol (Intel DCAP? AMD SEV-SNP attestation reports? Azure Attestation? custom?), the claims format, and the verifier-policy language are not described.
  • Abuse detection vs. confidentiality trade-off only sketched. Meta states "enhanced host monitoring" for abuse detection outside the CVM but does not describe what signals are collected, how the host-monitoring surface is itself attested, or how abuse reports are generated without observing CVM contents.
  • AI-specific attacks (prompt injection) named but not mitigated specifically. The post flags prompt injection as an attack class inside the threat model but the mitigations listed (hardened binaries, containerisation, sanitised inputs, limited entry points) are the generic TEE mitigations — no specific prompt-injection defence architecture is described.
  • Bug bounty scope not quantified. The program is being expanded, but scope, payouts, and specific rules-of-engagement for TEE / attestation bugs are not disclosed here.
  • Open-source scope unclear. "Components of Private Processing" + "certain… load-bearing code" is gestured; a complete manifest of what's being open-sourced is deferred to the design paper + launch.
  • Launch timing uncommitted. "In the coming weeks" as of 2025-04-30; no firm GA date. No staged rollout geography or user-cohort disclosure.
  • No numbers on the Anonymous Credential Service. The 2022 ACS post linked from the body has richer detail (VOPRF, protocol shape, etc.); this post treats ACS as a black-box primitive.
  • User-experience surface not described. How attestation-failure manifests to the user, what the in-app request-log experience looks like, how the "Meta AI in chats" trigger is surfaced, etc., are not covered.
  • Confidential-Compute-mode GPU details absent. Which confidential-GPU mode (NVIDIA Hopper Confidential Computing is the obvious candidate as of the 2025-04 date), but neither the vendor nor the mode is named.

Source

Last updated · 319 distilled / 1,201 read