Trust

How the seal works

Most assistants ask you to trust a company's promise. Embody tries to replace the promise with something your phone can check. This page explains what that check covers, what it doesn't, and where the edges are. If something here is wrong, the code is the source of truth and we'd like to hear about it.

Where Pip lives

Pip is a program running inside an Intel TDX confidential virtual machine hosted on Phala. TDX is a feature of the processor: the machine's memory is encrypted by the CPU, and the host it runs on, including whoever administers that host, can't look inside. The machine has no SSH and no admin shell.

Your data is kept as encrypted documents, one set per person. The keys are derived inside the enclave from Phala's key service, which only hands keys to the exact code that was measured at boot. Disks, snapshots and backups only ever contain ciphertext.

When Pip needs to think, it talks to GLM, an open-weights model running in a second enclave at Venice. Before sending anything, Pip checks Venice's enclave proof, then encrypts your conversation to a key that only exists inside that enclave. Venice's servers pass along ciphertext.

What's verified

• The enclave is real. Every time you open the app, it sends a fresh random number and gets back a TDX quote, signed by Intel's hardware, that includes it. A recorded answer can't be replayed. embody verify checks Intel's signature on your own machine.
• The code is the code. The quote includes a measurement of exactly what booted: the operating system image and the hash of the app's configuration, which pins the container image by digest. We publish the expected values so you can compare them.
• The model enclave is real. Pip verifies Venice's quote inside its own enclave and binds the encryption key to it before any of your words go out.
• TLS ends inside. The HTTPS certificate for this service is issued and kept inside the enclave, so the connection is decrypted only where Pip is.
• The log can't be quietly edited. Everything Pip does goes into a hash-chained log signed by a key that only exists in the enclave.
• Risky actions need you. Anything with side effects waits for your tap. Money and outgoing email also need a fresh passkey signature, which the enclave checks itself.

What we can and can't see

We, the people running Embody, cannot read your mail, memory, keys or messages. We can't log in as you or approve a payment for you.

We can see that your account exists, and counts: how many tokens and model calls you use, which tools ran, which sites Pip fetched, and a salted hash of the IP addresses you connect from (to spot abuse). Waitlist emails are visible to us, because the point is to email you. If you subscribe, Stripe handles the card and tells us your subscription is active; we never see card details.

Where the edges are

We'd rather you hear these from us.

• Forwarded mail passes through Cloudflare. If you use your Embody forwarding address, mail is received by Cloudflare's email service and relayed to the enclave. Cloudflare sees those messages in transit. Mail Pip fetches directly from Gmail or IMAP goes straight from the provider to the enclave over TLS.
• Proton Mail's encryption ends at the bridge. To read Proton, Pip runs a Proton bridge inside the enclave. It stores your Proton password, encrypted, inside the enclave, and it can decrypt your Proton mail. That is the point, but it is a big key to hand over.
• The browser runs without its own sandbox. Pip's web browser runs inside the enclave boundary, but with Chromium's sandbox switched off. The enclave protects it from the outside world; it does less to protect the enclave from a hostile website that found a browser bug.
• On Free, you share an enclave. People on the Free plan share one enclave, separated by software and by per-person keys, not by hardware. A serious bug or escape could cross that line. Premium gives you a dedicated enclave.
• You still trust the hardware and its makers. Intel's TDX, Phala's key service and Venice's enclave are the foundation. TDX has had side-channel attacks in the past; we check that the platform reports itself up to date, which is the best signal available, not a proof.
• The model's weights aren't bound yet. Venice's proof covers the serving enclave, not a hash of the GLM weights inside it.
• Metadata exists. Venice sees message sizes and timing. Phala sees that the machine exists and how much traffic it moves. Anything you send through Telegram, Telegram can read.
• The in-app seal is a quick check. The green seal in the app means the enclave answered with a fresh quote. The app itself doesn't verify Intel's signature chain; that's what embody verify is for.
• Pip can be fooled. A malicious email or web page can try to talk Pip into something. Approvals, spending caps and passkeys limit the damage; they don't stop the attempt.
• Your phone is the key. Someone holding your unlocked phone and passkey can approve anything your policy allows.

Check it yourself

In the app, More → Attestation shows the live quote, the configuration hash and Venice's status. For an independent check that doesn't rely on our server's word, run embody verify from the command line: it verifies Intel's signature chain on your own machine.

The full threat model and the published measurements are in the repository: threat model, measurements.

Join the waitlist Back to the start