Skip to main content
Five steps, in order. The first one is where the key comes from, which is why an Encrypted call begins with an attestation.

​
1. Get the Model’s Key

The sealed hardware holds a private key that never leaves it. Its public key travels inside the hardware’s attestation evidence, the signed statement of what is running there. Your device asks Nito for that evidence, with a challenge you chose, and gets back the raw evidence, the model’s public key, the signing algorithm the key uses, and a proof format that names the evidence layout. Checking the evidence is what tells you the key you are about to encrypt with belongs to sealed hardware running the model you asked for. See Verify It Yourself. On the API this is GET /api/v1/attestation with the :encrypted model and trust_tier=encrypted. The Browser App fetches it for you and shows the same evidence with the reply as the Attestation Report.

​
2. Encrypt on Your Device

Your device generates a key pair for the conversation and, for each message, an ephemeral key. From the ephemeral key and the model’s public key it derives a fresh symmetric key and encrypts the message with an authenticated cipher. The result is a hex envelope holding the ephemeral public key, the cipher nonce, and the ciphertext. Every messages[].content string in the request is replaced by such an envelope. The exact steps are on Protocol. The request carries the Encrypted headers: a flag, your public key, the model’s public key from the attestation, the signing algorithm, and, depending on the variant, a protocol version, a nonce, and a timestamp.

​
3. Nito Relays

Nito checks the headers, that the model is an :encrypted entry, that each content string is nonblank even-length hex, and the request bounds, then forwards the request to the sealed hardware. It never decrypts, logs, or persists the ciphertext. Usage is estimated for the reservation from the length of the envelopes, without reading them, and settled afterwards from the usage the provider reports.

​
4. The Sealed Hardware Answers

Inside the sealed hardware the request is decrypted with the private key, the model runs, and the reply is encrypted to your public key. The provider’s operator runs the machine and cannot read into that memory. See What’s a TEE.

​
5. Decrypt on Your Device

The reply’s content arrives as a hex envelope of the same shape, and your device decrypts it with its private key and the ephemeral public key in the envelope. A reasoning summary, where the model returns one, arrives encrypted the same way. On the API, stream: true returns the provider’s encrypted deltas as a passthrough for your client to reassemble and decrypt. The Browser App uses the non-streaming path, so a reply arrives whole and is decrypted before it is shown.

​
Where the Encryption Runs

In the Browser App, the code that encrypts and the attestation both arrive from Nito over TLS. With your own client on the API, you run the checks and the encryption yourself, with nothing of Nito’s in the loop. Protocol has what a client needs.

What It Protects

What stays private, and what it relies on.

Protocol

Keys, ciphers, envelope, headers.

How Attestation Works

The evidence the key comes with.