That post was about the architecture. This one is about what happened when someone tried to break it.

Trail of Bits just published its pre-launch security audit of WhatsApp’s Private Processing system. They found 28 issues, including 8 high-severity findings. Meta fixed the critical issues before launch.

That makes this one of the best public case studies we have on what TEE-based AI security actually requires — and where the trust model’s assumptions collide with messy real-world implementation.

TEEs do not produce trust. Complete measurement does.

The central lesson from the audit is simple, but uncomfortable: a TEE is only as trustworthy as its attestation boundary is complete.

In theory, remote attestation gives a client a cryptographic way to verify what code is running. If the measurement matches, the system should be trustworthy.

In practice, the measured boundary often excludes things that still shape behavior: environment variables, hardware configuration, firmware claims, session freshness, and other inputs outside the neat conceptual model.

That is where the failures showed up.

Four findings every confidential AI builder should study

1) Code injection after measurement

Trail of Bits found that WhatsApp’s system loaded environment variables after the attestation measurement was taken (TOB-WAPI-13). That created a dangerous gap between what the client verified and what the system might actually execute.

A malicious insider could inject something like LD_PRELOAD=/path/to/evil.so, causing arbitrary code to load at startup. The attestation would still appear valid. The code would still run inside the “trusted” environment.

That is the kind of bug that breaks the whole promise.

Meta fixed this by strictly validating environment variables and explicitly blocking dangerous ones like LD_PRELOAD. But the broader lesson is architectural:

Every input a TEE consumes must either be measured or treated as hostile.

If your system loads config, feature flags, or runtime parameters after measurement, you need to think very carefully about what exactly the client is trusting.

2) Unmeasured hardware configuration

The audit also found that ACPI tables were not included in the attestation measurement (TOB-WAPI-17).

That matters because ACPI tables define how the operating system sees hardware. A malicious hypervisor could inject fake virtual devices with read/write access to memory regions that should have been protected. The secure VM could then boot, trust those tables, and expose sensitive memory — including user messages and keys — while the attestation still appeared valid.

Meta addressed this with a custom bootloader that verifies ACPI table signatures as part of secure boot, so tampering changes the measurement.

This is exactly the kind of finding that gets missed in high-level confidential computing discussions. Most teams think about measuring application code. Fewer think about measuring the hardware configuration their code implicitly trusts.

But the attack surface is not just your binary. It is everything your binary trusts.

3) Self-reported firmware versions are not a trust signal

AMD patches SEV-SNP firmware to fix vulnerabilities. WhatsApp’s system checked patch levels, but initially trusted the firmware’s self-reported version rather than verifying it against AMD’s cryptographically signed certificate data (TOB-WAPI-8).

That is a subtle mistake with major consequences.

A compromised or outdated firmware stack could simply claim to be patched. If the verifier trusts that claim, the system can present itself as healthy while still running code with known weaknesses.

Meta fixed this by validating patch levels against the VCEK certificate’s X.509 extensions.

The lesson is broader than firmware: never rely on a component to honestly report its own trustworthiness.

That is the entire reason attestation exists. The minute your verification logic falls back to self-reporting, you have reintroduced the trust assumption you were trying to remove.

4) Attestation without freshness can be replayed

Before the audit, WhatsApp’s attestation reports did not include a client-provided nonce or equivalent freshness guarantee (TOB-WAPI-7).

That meant an attacker who compromised a TEE once could potentially save a valid attestation and replay it later. What should have been a one-time compromise could become a durable impersonation path.

Meta fixed this by binding attestation to the TLS client_random, tying the report to a specific session.

This is a critical lesson for any system that uses TEEs as a trust anchor: attestation is not just about identity. It is also about freshness.

If a relying party cannot tell whether an attestation is live or replayed, it cannot meaningfully trust the session.

Why this matters beyond WhatsApp

These were not exotic cryptographic breaks. They were implementation and integration failures — exactly the kind that show up when a sophisticated security design meets real production systems.

That is why this audit matters so much.

The confidential computing ecosystem has spent years making the theoretical case: hardware root of trust, encrypted memory, attested execution, privacy-preserving compute. The theory is strong. But this audit shows where real systems still fail:

• unmeasured inputs
• implicit trust in low-level configuration
• verification shortcuts
• weak freshness semantics

That has implications well beyond WhatsApp.

For confidential AI builders

Treat this audit like a threat-model checklist.

Ask:

• What sits outside our measured boundary?
• Are we trusting any input loaded after measurement?
• Are we verifying firmware and platform state cryptographically?
• Is attestation bound to a specific session?

If you cannot answer those clearly, your TEE story is probably weaker than you think.

For enterprise buyers

This audit gives enterprises much better questions to ask vendors.

Not just:

• “Do you use TEEs?”

But:

• “What exactly is measured?”
• “What sits outside the attestation boundary?”
• “How do you verify firmware and patch state cryptographically?”
• “How do you prevent replayed attestation?”
• “What inputs are loaded after measurement?”

That is a much more useful procurement conversation than vendor marketing around “secure enclaves.”

For the agentic AI stack

This is where I think the lessons become especially relevant.

As AI agents start invoking tools, accessing sensitive data, and acting on behalf of users, the runtime environment becomes part of the trust model. The same issues Trail of Bits found here — incomplete measurement, misplaced trust in unmeasured inputs, weak freshness guarantees — apply directly to agent runtimes, MCP servers, and other execution environments where a relying party needs to trust what is actually running.

If the industry is serious about attested agent identity, this is the kind of implementation discipline it will need.

The real scorecard

What I find most encouraging here is not that Meta built a perfect system. It didn’t.

It is that Meta submitted the system for review before launch, fixed the high-severity issues, and allowed the findings to be published.

That is the model.

Too much of the confidential computing market still runs on branding: “we use enclaves,” “your data stays private,” “the cloud provider can’t see it.” Those claims may be directionally true. But the WhatsApp audit is a reminder that the real question is not whether a TEE is present.

It is whether the trust boundary is actually complete.

The cleanest takeaway from the report is this: trust the measurement, not the enclave.

A TEE without complete, fresh, cryptographically verifiable attestation is just a VM with better marketing.

Meta got to the right place before launch. The more important question is whether the rest of the industry will learn from this audit — or repeat the same mistakes in private.

This is a follow-up to my earlier post, WhatsApp’s Private Processing: Confidential Computing at Internet Scale.

If you’re interested in how these same trust-boundary problems show up in the agentic stack, I also wrote about that here: The Weakest Link in AI: Hardening MCP Servers with Confidential Computing.

Disclaimer: The views expressed here are my own and do not represent those of my employer.