Phala
6.3K posts
@PhalaNetwork
Empowering 10,000 builders and companies to build scalable, private, and safe intelligence.
#ICML2026 @PhalaNetwork is presenting its legal bench paper at AI4Law workshop poster session. Come to poster board 3211 at Hall A if you wanna know why Saul argues your citation is hearsay from an AI
At ICML now @icmlconf #ICML2026 Phala will present the LegalCiteBench paper (arxiv.org/abs/2605.10186) at AI for Law workshop poster session on Friday.
Getting a lot of questions about how TEEs work in @usewisp_io and why they are the most private way to use AI. Wisp uses TEEs in 2 cases: Wisp Proxy (Anonymizer) and the actual LLM inside @PhalaNetwork with @TinfoilAI as fallback. I'll explain both and how we verify TEEs stay intact: > What is TEE or Trusted Execution Environment? It is a hardware-isolated region inside the CPU/GPU that can't be accessed even by the host's OS, hypervisor or other applications. Wisp runs AI inside TEEs. Your prompts are encrypted on your device before being sent to the LLM that lives inside a hardware-secured chip. Your prompts are only decrypted once inside TEE, where nobody can see them. > How do we know for sure that nobody can see inside TEE? Intel TDX (what Wisp uses), has a dedicated hardware memory-encryption engine in the CPU memory path that encrypts data with a per-VM key as it moves between CPU<>RAM. The key lives inside CPU and is never exposed to software. Not even @PhalaNetwork, which supplies the hardware, can see inside. > Since nobody can see inside, how do we make sure that the code running inside TEE is what we claim it to be, and also that it runs on correct hardware? Before anything leaves your device, the Wisp desktop app asks TEE for an attestation - cryptographic proof that TEE is running *this exact code* on *this exact hardware*. The flow is: 1. Wisp asks TEE to attest, sending a fresh nonce. 2. The TEE returns a quote covering a) a hardware attestation and b) a measurement of the code it booted. 3. Wisp verifies the hardware attestation is signed by Intel - proof it's a genuine, up-to-date TDX chip. 4. Wisp matches the code measurement against the published build: the exact image digest our CI produced from the code. We'll open source it soon, so anyone will be able to rebuild it and check the hash themselves. 5. Any mismatch → Wisp refuses to send a single byte off your device. > Why do you use TEEs and not FHE? FHEs are theoretically the most private option for AI inference because your prompts never get decrypted. In TEE, the prompt arrives encrypted, then the enclave decrypts it because the model has to run inference on plaintext. FHE skips the decryption step, AI hardware computes directly on ciphertext and produces an encrypted answer that only your key can open. Problem is, FHE inference is 10,000x slower atm and still doesn't prove which model ran inference, so you need the attesation anyway. Atm, FHE simply isn't commercially viable for mass market AI. When a more private + performant solution emerges, we'll adopt it. > is TEE 100% secure? Nothing is trust-free (including FHE), but the attack cost is the metric here. TEE Attestation doesn't remove trust - it moves the attack vector from 'insider greps the logs' to 'physically taking over a secure machine' which is substantially more expensive. If you need more info on how Wisp works + sign up to the waitlist, go to usewisp.io
