How WhatsApp Built Cloud AI Without Breaking Its Biggest Promise?
Three structural patterns from WhatsApp’s Private Processing architecture, worth stealing even if you never build a Trusted Execution Environment.
There’s always another AI incident coming.
My favorite part of the job has become putting real thought into the primitives and architectures that prevent the recurring classes of problems by design.
I love team camaraderie. I just don’t love it showing up at 2 a.m. on an all-hands call, staring at a fix everyone already knows is a band-aid.
I value my sleep. I value even more the moments I can tell users trust me.
“We take your privacy seriously” copy, or a tucked-away incognito button, looks great on a privacy-first landing page. It’s also a ticking time bomb. The fix ends up being one patch after another. One incident is all it takes to erase years of trust.
Welcome to Code Like a Girl, the community where women in tech come to be seen, heard, and championed as they walk this path together.
If you are a woman in tech who wants to build systems that hold up under scrutiny, this is where you find the people who push your thinking.
WhatsApp Private Processing
I spent years working on privacy, messaging, and infrastructure at WhatsApp. So when WhatsApp introduced cloud AI, I stopped at the obvious architectural contradiction: how do you keep a promise like “not even Meta can read your messages” when the model has to process your messages in the cloud
Turns out it’s a masterclass in embedding privacy into product. Three patterns are worth stealing, whether or not you ever touch or hear about a Trusted Execution Environment (TEE) again.
Inaccessibility Invariant. “We can’t look.”
Remote Attestation. “Verify, then trust.”
Split Trust. “No one gets the whole picture.”
The deeper pattern behind all three: the strongest product promises aren’t just defended by policy. They’re enforced by architecture, sometimes down to the hardware itself.
Here’s how each one works, and where the shape is reusable.
Pattern 1: Inaccessibility Invariant - We Can’t Look
How do you build a system where even your own engineers can’t peek?
Normal cloud AI runs on privacy-by-policy: “we promise not to look.” WhatsApp needed something a policy can’t give you: “we cannot look.”
The mechanism is a TEE: a Trusted Execution Environment, a hardware-sealed boundary rooted in the physical chip.
If you’ve used Face ID, you’ve already trusted this pattern.
The Secure Enclave is a hardware-isolated subsystem inside Apple’s silicon. It keeps your biometric data walled off from the rest of iOS at the hardware level, not just in software.
Private Processing scales that same idea to cloud AI. The LLM runs inside a sealed environment built directly into the silicon: AMD confidential computing on the CPU chip, NVIDIA H100 confidential computing on the GPU chip. The surrounding Meta infrastructure still routes packets and schedules work, but it cannot inspect the message plaintext or arbitrarily reach into the confidential workload.
Even the engineers operating the service don’t get normal SSH-style access to look around inside.
Where to steal this: any workload where “trust me” is still the primary privacy guarantee.
The question is not only who is allowed to look, but whether fewer people could look at all, and whether that could become an invariant of the system design.
Honestly, that includes most AI products. Prompts and uploaded files carry PII by default, often with far less scrutiny than data in regulated domains such as banking.
Pattern 2: Remote Attestation - Verify, then trust
How does your phone know it’s sending data to the real protected server, not a normal Meta server pretending to be one?
Before your phone sends anything sensitive, the server presents hardware-backed proof of the environment it’s running in. That proof includes the server’s key and a fingerprint of the software loaded inside the TEE.
WhatsApp checks two things:
that the proof chains back to AMD’s hardware root of trust
that the software fingerprint matches an approved build in Cloudflare’s transparency system.
A normal Meta server can invent its own key, but it can’t produce valid AMD-backed proof that the key belongs to a genuine TEE running approved software. If either check fails, the client refuses the connection.
The architectural move is simple: make the server prove what it is before the client sends it anything sensitive. Only then does the client establish a session key and encrypt anything to the TEE.
Where to steal this: anywhere a client has a real reason to distrust the server it’s about to talk to.
Pattern 3: Split Trust - No one gets the whole picture.
How do you stop anyone from connecting who asked with what they asked?
Sealing the compute doesn’t hide that you used the AI feature. A gateway could still see your IP address hit the AI endpoint, and for sensitive topics, knowing you asked can already say too much.
WhatsApp’s answer: route through Fastly using Oblivious HTTP.
Your phone encrypts the request to the sealed TEE’s own key, not a key Meta holds generally, then sends it to Fastly, which can see your IP but not the payload. Fastly forwards the encrypted payload to Meta’s servers, which see the ciphertext but hold no key that can open it. Meta sees Fastly as the sender, never your phone’s IP. The payload only gets decrypted once it’s inside the sealed environment, using a private key that never exists anywhere else.
Fastly sees the source IP but not the plaintext. Meta’s general infrastructure sees the encrypted request but not the source IP. Only the sealed TEE ever sees the plaintext, and the routing is designed so it never learns who sent it.
Where to steal this: least privilege applied across parties, not just within one system. Distribute what each party knows, so no single one ever holds enough to violate the promise alone.
WhatsApp’s Private Processing is not the only tool. The real question is what execution boundary a given workload actually needs:
Treating cloud AI as untrusted and keeping PII out of the request. Structured prompts, local filtering, or compressed context, when that’s genuinely enough.
A conventional cloud with strict retention limits, limited or disabled training on user data, and explicit controls, when a TEE isn’t worth the engineering cost or product needs.
A TEE, when the data is sensitive enough that it can’t just go to a normal cloud, but the job still needs more reasoning, context, or iteration speed than the device can give you.
On-device models, when the task is bounded, personal, latency-sensitive, or useful offline.
Any system that handles sensitive data can borrow the shape without borrowing the exact solution.
The Real Lesson
Every product makes promises.
Great systems ask: can this promise also become architecture beyond just policy?
Structure Beats Policy
“We promise not to look” is a policy. “Our infrastructure can’t see the plaintext, and you can verify that yourself” is structure. Wherever you can turn a promise into a constraint, trust gets cheaper to maintain and scale.
Observability Has to be Designed in, Not Bolted On.
Sealing the server also removes engineers’ ability to inspect problems directly. This requires defining observability in advance: structured logs, predefined schemas, allowlisted diagnostic endpoints, and aggregate metrics.
That constraint produces better systems. Observability becomes auditable, transferable, and less likely to leak PII. The privacy-first primitives do not invent the discipline; they make them mandatory.
State Your Gaps
The approach above has its own edges. Serious systems name what they do not protect: side channels, hardware limits, multi-GPU links, retention windows, and what remains outside the trusted boundary. If you do not say where the boundary ends, the system becomes harder to understand and even harder to extend.
Private Processing isn’t cheap. It demands harder infrastructure. It removes the safety net of normal debugging. But breaking the product’s premise is expensive too, just later, and in a currency you don’t get back.
One cost makes the system harder to build. The other makes the product harder to trust.
Choose your expensive.
What critical promise is your product making, and what would it take to make it structural? Tell me what you’re building in the comments. I’d genuinely like to know.
We're grateful to Shalini Sah for sharing her work here. If you want systems thinking that turns product promises into architecture you can verify, her writing is worth following.
You Belong Here
Shalini showed how the strongest promises get enforced by structure, not by good intentions.
Code Like a Girl is the community for women in tech who want to build things that earn trust and know how to prove it.
If you are not subscribed yet, that is the place to start. It is free.
Read Next
 | A guest post by
|
Looking behind the curtain is fascinating! Thanks Shalini.
This is the same tension every AI-native product hits once it scales past a demo: the promise that got you users (privacy, speed, whatever) becomes the hardest constraint to preserve once you add cloud inference. I've seen teams solve it by architecting for the constraint from day one versus retrofitting privacy after the ML pipeline exists, and the retrofit path is almost always the one generating the 2 a.m. calls. Did WhatsApp's team have the encryption-first constraint baked in before they started building the AI features, or did that get layered in mid-build?