Privacy by design: How Wisp uses Phala to power confidential AI

Wisp is built around privacy by design: it isn’t enough for an AI provider to promise not to read, store, or train on your data. Those protections should be built into the system so that access is structurally prevented—not left to a provider’s word or privacy policy.

To make that possible, Wisp runs open-weight language models inside a Trusted Execution Environment (TEE): a protected area of a computer’s memory that is isolated from the rest of the system. When you send a prompt, Wisp encrypts it locally and routes it to a TEE-powered model.

Wisp uses Phala’s Confidential AI cloud to run private AI workloads on TEE-protected GPUs.

A Confidential VM is a virtual machine whose memory is encrypted at the hardware level. In Wisp’s case, that protection is provided by Intel TDX. The hypervisor, host operating system, and people with physical access to the server can observe that data is moving through the VM, but cannot read its contents. Phala operates the TEE infrastructure, while the hardware protections are designed to prevent the operator from seeing what happens inside the enclave.

How a prompt travels through Wisp

1. Your device — You write your prompt locally. Your chats, sessions, and audit logs are stored on your device and encrypted with ChaCha20-Poly1305.
2. The Wisp Proxy — Running as a Confidential VM on Phala, the proxy routes your prompt to the model. It also handles requests that could identify you, such as web searches, helping protect you from third parties building an advertising profile around your activity.
3. The AI model — The model runs inside its own hardware-secured enclave. Wisp forwards your prompt to a TEE-hosted model through providers such as Redpill and Tinfoil.
4. The response — The answer returns to the Wisp app along the same protected path. No server logs your request.

Every part of the journey that handles your prompt is protected: the Wisp Proxy, the network path it controls, and the model inference itself. The design keeps your prompt from sitting in plaintext on a machine that an outside operator could inspect.

Why we chose Phala

Phala makes TEE verification part of the infrastructure:

• Hardware isolation. The proxy runs on Intel TDX, which gives the entire VM encrypted memory. This protection is provided by the CPU rather than a software setting that can simply be switched off.
• Remote attestation. When the proxy starts, the hardware produces a signed report identifying the code that is running, including the Docker image hash and startup configuration. The report is signed with a key derived inside the enclave, making it difficult to forge. Phala verifies these reports automatically and makes them available through its TEE Attestation Explorer.
• dstack, the open-source runtime. The tools used to set up and verify the Confidential VM are public code that anyone can audit. If the proxy did not run as described, the attestation report would show a different measurement.

Attestation helps people verify Wisp’s privacy claims. Traditional AI cloud providers may offer compliance documents, but those documents do not prove what code is running on a particular machine. Phala provides a cryptographic attestation—a hardware-generated receipt—that identifies the code running on the hardware inside the protected environment. If Wisp changed the proxy to store or train on prompts, the attestation would change too, making that difference visible to anyone who checks it.

Privacy by design

AI providers often ask users to trust their promises. Wisp is designed to make that trust less necessary: your prompt leaves your device encrypted, is processed in memory that neither Wisp nor the infrastructure operator can read, and returns as an answer. The journey is cryptographically verified.

As the runtime is attested on Phala’s public infrastructure, you’ll be able to check what Wisp runs for yourself instead of relying only on our word. That’s the standard every AI product should meet.

Learn more at usewisp.io.