> ## Documentation Index > Fetch the complete documentation index at: https://docs.trynito.ai/llms.txt > Use this file to discover all available pages before exploring further. # How It Works > An Encrypted call step by step: the key, encryption on your device, the relay, the sealed hardware, and the reply. 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](/privacy/tee-attestation/verify-yourself-recipe). 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](/privacy/encrypted/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](/privacy/tee-attestation/what-a-tee-is). ## 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](/privacy/encrypted/protocol) has what a client needs. ## Related What stays private, and what it relies on. Keys, ciphers, envelope, headers. The evidence the key comes with. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.