HOW IT WORKS

Private computation.
Verifiable by design.

The model needs to read your prompt. The people running the servers don’t. Confidential computing separates the two.

Your deviceYour prompt. Your answer.
PROTECTED ENVIRONMENT
The model
CPUGPU
Readable only inside

Serence & hosting operators stay outside this boundary.

Follow a request

THE MISSING LAYER

Encryption doesn’t usually
cover the moment that matters.

Most services decrypt your data on a server they control. A trusted execution environment, or TEE, adds hardware isolation while that data is being processed.

01

At rest

Encryption protects stored files. The service can still decrypt them when it holds the key.

On a disk
02

In transit

HTTPS protects a connection. The server at the other end can still read what arrives.

On the network
03

In use

Protected hardware isolates the model’s working memory from the hosting operator.

While the model works

FROM REQUEST TO RESPONSE

The protected inference path.

This is the architecture we’re building: your client releases data only to protected software it has verified. The current trial does not yet implement this complete path.

  1. Ask the hardware for proof.

    Before sending a prompt, the client on your machine requests a fresh, hardware-signed report. This is remote attestation: evidence of the environment’s identity, security settings, and the software loaded inside it.

  2. Check what will receive your data.

    The client checks the signature, security state, and freshness. It compares the software’s cryptographic fingerprint with approved reference measurements. It also checks that the connection’s public key belongs to that same measured environment.

    A genuine server isn’t enough. It must be the approved software, holding the right key.

  3. Encrypt before it leaves you.

    Once those checks pass, the client establishes an encrypted channel ending inside the verified environment. Routers, proxies, and hosting infrastructure carry ciphertext. They don’t receive the key that unlocks your prompt.

  4. The model works inside the boundary.

    The model reads plaintext inside the protected environment. The CPU, GPU, and any links carrying readable data must all stay within the verified boundary. Approved software controls where that data can go.

    The computation uses readable data. Hardware isolation keeps it out of the operator’s reach.

  5. Only your client opens the answer.

    The response is encrypted before it leaves the protected environment and decrypted on your device. Both sides of the conversation follow the same rule: readable at the endpoints, opaque to the infrastructure between them.

THE BOUNDARY, CLEARLY

What this protects.

This design protects prompts, files, and answers during inference. Account and usage metadata are separate. Your device and connected services remain responsible for the data they hold.

Its security rests on verified hardware and approved software, instead of an operator’s promise not to look.

Go deeper

Phala · Verifying an application Intel · TDX attestation NVIDIA · Confidential AI architecture