Private Processing: A New Approach to Confidential AI on WhatsApp

AI has opened up new possibilities for messaging apps, but the way most AI models work today creates a fundamental tension with privacy. Large language models typically process data on remote servers, meaning user requests are visible to the service provider. For an app like WhatsApp, whose core promise is end-to-end encryption, that trade-off doesn't fit.

WhatsApp has been working on a technology called Private Processing to bridge that gap. It's designed as an optional capability that lets users direct AI features—such as summarizing unread threads or generating writing suggestions—to run in a confidential, secure environment where no one, including Meta and WhatsApp, can access the underlying messages.

The design is built around three core principles:

  • Optionality: Using Meta AI through WhatsApp, including features that use Private Processing, is entirely optional.
  • Transparency: WhatsApp must clearly indicate when a feature relies on Private Processing.
  • User control: For particularly sensitive chats, users can prevent messages from being used for AI features through WhatsApp's Advanced Chat Privacy setting.

How the Infrastructure Protects Data

Private Processing runs on confidential computing infrastructure built on a Trusted Execution Environment (TEE). The goal is to let powerful AI models process requests without ever exposing the data in a way that Meta, WhatsApp, or any third party could access.

To achieve that, the system was designed with several foundational requirements:

  • Confidential processing: No other system—including Meta or WhatsApp—can access user data while it's being processed or in transit to the processing environment.
  • Enforceable guarantees: Any attempt to break the confidentiality guarantee must cause the system to fail closed or become publicly visible through verifiable transparency.
  • Verifiable transparency: Users and security researchers can audit how Private Processing behaves to independently verify the privacy and security claims.

Beyond those core requirements, WhatsApp also treats additional layers as essential. Non-targetability means an attacker can't single out a particular user without trying to compromise the whole system. Stateless processing and forward security ensure the system retains no access to messages after a session ends, so even a successful attack wouldn't expose historical requests or responses.

The threat model that guided the design covers three main threat actor types: malicious insiders with infrastructure access, third-party supply chain vendors, and malicious end users targeting other users on the platform.

The Session Flow

Private Processing works through a chain of cryptographic steps designed to keep every hop protected:

  1. Authentication: The system obtains anonymous credentials to verify that requests come from authentic WhatsApp clients.
  2. Third-party routing: It fetches HPKE encryption public keys from a third-party CDN to support Oblivious HTTP (OHTTP).
  3. Wire session: An OHTTP connection is established from the user's device to a Meta gateway via a third-party relay, which hides the requester's IP from Meta and WhatsApp.
  4. Application session: A Remote Attestation + Transport Layer Security (RA-TLS) session runs between the device and the TEE, with attestation cross-checked against a third-party ledger.
  5. Request: The device sends an encrypted request to Private Processing using an ephemeral key that only the device and the selected TEEs can decrypt.
  6. Processing: AI models handle the data inside a confidential virtual machine (CVM), which doesn't store any messages. CVMs can also communicate with each other using the same RA-TLS session.
  7. Response: The result returns to the device encrypted with a key only the device and the pre-selected Private Processing server possess. No access is retained after the session completes.

Threat Scenarios Considered

The architecture addresses several distinct attack paths. One concern is external actors exploiting the product's attack surface or compromising services inside the CVMs to extract messages. This could involve zero-day vulnerabilities or AI-specific attacks such as prompt injection. The system minimizes this by limiting entry points to a small set of reviewed components, hardening service binaries, and running them in containerized environments to limit what a compromised binary can exfiltrate.

A second scenario involves internal or external attackers extracting messages exposed through a CVM. Observability is inherently tricky in confidential computing—debugging tools can create side channels that leak data. WhatsApp implemented a log-filtering system that limits exports to allowed log lines only, such as error messages. The CVM build process runs in restricted environments requiring multi-party review, and binary digests will be published in a third-party log so external researchers can analyze and report any concerns.

The third scenario covers insiders with physical or remote access interfering with CVMs at boot or runtime. TEE exploitation is an active area of security research, with researchers repeatedly demonstrating ways to bypass protections. WhatsApp's approach relies on defense-in-depth: tracking emerging vulnerabilities, sanitizing untrusted inputs, hardening the CVM surface, and enabling abuse detection through enhanced host monitoring. Physical risks are mitigated with encrypted DRAM and standard data center security controls, while OHTTP relay routing helps eliminate the viability of targeting a specific user.

Building in the Open

WhatsApp plans to publish components of Private Processing and is expanding its Bug Bounty program to cover the new infrastructure. A detailed security engineering design paper is also planned ahead of the launch, which is expected in the coming weeks.

The first use case focuses on AI-powered message summarization and writing suggestions at users' direction, but the same infrastructure could apply to other scenarios where private processing of user requests is beneficial.

Inside the Private Processing Architecture

Private Processing is built around several layered security mechanisms that work together to meet the requirements defined by the threat model. The following sections break down each component of the design.

Confidential Compute Environment

Data sent to Private Processing is handled exclusively within a Confidential Virtual Machine (CVM) that no other system can access. End-to-end encryption between the client and the Private Processing application ensures that only the intended application can read the data — not Meta, WhatsApp, or any intermediary relay. The CVM's boundaries also restrict what data can leave the environment: only minimal service reliability logs are allowed out, limiting the potential for user data leakage.

Software and Runtime Protections

A key design decision is the complete prohibition of remote shell access to the CVM, including from the host machine. This prevents any privileged runtime access to Private Processing. Code isolation further constrains the system so that only designated code within Private Processing can touch user data. Neither the host OS nor a networked user can obtain a shell into the CVM.

Supply chain and source control attacks are mitigated through industry-standard practices. Builds are created exclusively from checked-in source code and artifacts, with any modification requiring multi-engineer approval across the build pipeline. All code changes remain fully auditable, enabling detection of issues through both internal continuous audits and external security researchers examining the released binaries.

Hardware-Level Security

The hardware foundation uses CPU-based confidential virtualization technologies alongside Confidential Compute mode GPUs. This combination defends against attacks originating from the host operating system as well as certain classes of physical attacks.

Attestation Before Data Transfer

Before any client-server connection is established, Private Processing performs attestation checks rooted in hardware. These attestations are verified against a third-party log of acceptable binaries, guaranteeing the system's security prior to any data transmission. Only after these checks pass does the client send data.

Stateless Operation and Data Minimization

Private Processing operates as a stateless service — it does not store or retain access to messages after a session completes. No data is written to disk or external storage. The service also practices data minimization by including only what is needed to process a given prompt; for example, a message summarization request includes only the messages the user explicitly directed the AI to summarize.

Anonymous Routing and Non-Targetability

The system implements the OHTTP protocol for secure sessions with Meta's routing layers. This prevents Meta and WhatsApp from determining which user is connecting to which CVM while a request is in transit, making it impossible to route a specific user to specific hardware. Users are authenticated through anonymous credentials over OHTTP, which verifies eligibility to use Private Processing without revealing identity. No identifiable information is included during session establishment, and even small-scale attacks cannot be leveraged to target an individual user's data.

Transparency and External Verification

Users will have access to an in-app log showing all requests made to Private Processing, the data shared with it, and details of the secure session setup. For independent verification, Meta will release the CVM image binary along with source code for certain components, including the attestation verification code and other load-bearing elements, to allow external researchers to audit the implementation.

The existing Bug Bounty program will be expanded to cover Private Processing, encouraging deeper independent security research. Additionally, Meta plans to publish a comprehensive technical white paper detailing the security engineering of Private Processing to support others building similar systems.

Private Processing will roll out in the coming weeks. Feedback from users, researchers, and the wider security community is welcome: