Secure messaging platforms like **Signal**, **WhatsApp**, and the recently **encrypted RCS** operate on a core principle: the content of a conversation remains private to its participants. End-to-end encryption provides mathematical guarantees that platform operators cannot access message content. However, this guarantee ends once a message arrives on a device, and the integration of artificial intelligence (AI) features into these apps is blurring that line. While on-device AI computation is less concerning, many AI features demand significant processing power, necessitating offloading data to company servers. Tech companies propose **Trusted Execution Environments (TEEs)** as a privacy solution for this server-side computation. But do server-side TEEs genuinely solve the privacy problem, or are they a compromise? TEEs serve various functions, from digital rights management (DRM) to securing mobile wallet information. Our focus here, however, is on their application in AI tools. The basic premise is straightforward: most consumer devices lack the power for advanced AI features. To compensate, data is sent off-device to more powerful cloud servers for processing, with results then displayed on the user's device. This offloading inherently introduces a privacy compromise. For example, asking a messaging app to summarize a conversation might send the entire message history to a cloud server and back. TEEs are designed to keep these requests private. Notable implementations include **Apple's Private Cloud Compute**, **Google's Private AI Compute**, and **WhatsApp's Private Processing**. Beyond the tech giants, even chatbots are leveraging TEEs. While TEEs offer more security and privacy than plaintext processing, they are fundamentally different from local execution or true end-to-end encryption. Despite company assurances, they cannot match the security and privacy levels of encryption. Consequently, a user's device should never automatically transmit data to a TEE. Let's explore why. ## What Exactly Is a TEE, Anyway? A TEE is a hardened section of a computer designed to run software in a way that remains secret even from other processes on the same machine. TEEs also enable users to verify that the intended code is running, not backdoored code, through a process called "attestation." You might also know them as "secure enclaves" or by brand names like **Intel SGX** or **ARM TrustZone**. The intention behind a cloud-based TEE is simple: a company can operate a server in its data center and process user-provided data on their behalf without being able to view that information themselves. ## Is a TEE Secure? In practice, TEEs have demonstrated vulnerabilities, with multiple cracks and hacks discovered annually. This is because, unlike encryption which relies on mathematics, TEEs depend on engineering for their security. Standard encryption algorithms are the product of decades of collaborative mathematical research, offering high reliability and resistance to breakage without fundamentally disrupting mathematical understanding. The global mathematical community generally considers standard encryption algorithms unbreakable with current knowledge. Responsible engineering dictates that new encryption methods undergo extensive scrutiny before implementation. Engineering, however, operates differently. Each system is a product of a specific engineering team, inevitably containing unique quirks and bugs that are discovered and patched post-deployment. No system has ever been built to be unbreakable, and new research consistently reveals methods to compromise TEE systems. While patches are issued, perfect security remains an elusive goal. TEEs present a particularly challenging engineering problem because the encryption key resides physically on the device. Building a TEE requires keeping this key entirely separate and inaccessible, despite being on the same physical device as other system components that should not have access to it. Many attacks on TEEs involve "side channels." In a side-channel attack, an attacker measures electrical impulses or other physical effects to deduce the timing of operations within the TEE, ultimately revealing the key. Once the key is compromised, all data can be read. This contrasts sharply with end-to-end encryption, where the key is never on the server machine, requiring an attacker to target the user's device directly. Companies using TEEs to protect data aim to have the key on the server while performing complex operations like running a Large Language Model (LLM), which significantly increases the difficulty of key protection. Nevertheless, a TEE offers a substantial improvement over plaintext data on a server. It transforms easily readable data into information requiring specialized, often physical, access to retrieve. This is particularly relevant for protection against mass surveillance, and for many, this level of security might suffice. However, this highlights the core issue: "secure enough for most cases" and "encrypted as in math" are not interchangeable concepts. It's crucial not to conflate them. Services currently offering "encryption as in math" experience a genuine downgrade in security when transitioning to TEE-based security. For a deeper dive into the security issues and limitations of TEEs, extensive documentation is available: * [https://arstechnica.com/security/2025/10/new-physical-attacks-are-quickly-diluting-secure-enclave-defenses-from-nvidia-amd-and-intel/](https://arstechnica.com/security/2025/10/new-physical-attacks-are-quickly-diluting-secure-enclave-defenses-from-nvidia-amd-and-intel/) * [https://ieeexplore.ieee.org/document/9152801](https://ieeexplore.ieee.org/document/9152801) * [https://dl.acm.org/doi/10.1145/3456631](https://dl.acm.org/doi/10.1145/3456631) * [https://ieeexplore.ieee.org/document/9935045](https://ieeexplore.ieee.org/document/9935045) ## What Does This Have To Do With LLMs and AI? Organizations often seek to offer private LLM responses. While on-device LLMs exist, their size is limited. To offer the ability to answer queries without viewing the conversation content, organizations turn to TEEs. This approach enables a reasonably private chatbot, as adopted by **Apple**, **Google**, **WhatsApp**, and others. Why not use encryption? LLM inference is essentially a complex mathematical computation—input to a large function yielding an output. While homomorphic encryption allows for computations on encrypted data without decrypting it, the computational cost is currently too high for practical LLM inference. Instead, the appeal of a TEE lies in its ability to perform this computation within a special, opaque section of a server. TEE manufacturers strive to make it as difficult as possible for the server operator to peek inside. However, users must still trust the operator not to employ side-channel techniques to deduce what's happening within. In this context, these systems can be reasonably considered "privacy-preserving," but not "encrypted." This distinction is crucial, especially when considering TEEs' interaction with secure messaging. When a user of an end-to-end encrypted chat app asks an LLM to summarize, review, or store messages, the content leaves the device and goes to an unencrypted third-party server. This poses a significant threat to the privacy of secure chat apps, and it's a threat users are finding increasingly difficult to control. ## How Does This Translate to Practical Advice? The answer depends on an individual's threat model. However, a sound rule of thumb is that a user's device should never automatically send data to a TEE. When the user has explicit control over what information is sent, even if it's a chunk of data, they maintain agency over their privacy.