Skip to main content
End-to-end encryption (E2EE) encrypts selected request and response fields between your client and the attested gateway. It sits on top of TLS: TLS still protects the HTTP connection, and E2EE adds field-level encryption whose key is published in the gateway’s attested keyset. This page explains the model. For setup and code, see the E2EE encryption guide.

​
What E2EE adds

  • Key provenance. The encryption key (X-Model-Pub-Key) comes from the attested keyset, so you can prove the field is encrypted to a key bound to a genuine TEE, not an arbitrary endpoint.
  • Field-level encryption. Selected request fields and response fields are encrypted, with the ciphertext bound by AEAD associated data to the request context (listed under Ciphertext format), so it cannot be replayed or moved to another field.
The gateway reports E2EE support in the attestation report: service_capabilities.supported_e2ee_versions includes "2".

​
What E2EE does not change

E2EE is decrypted inside the attested gateway so the gateway can process your request. It does not hide the request from the attested gateway; it proves the decryption key belongs to that gateway. This is the same boundary described in Trust boundary. Use a confidential model when the upstream that runs the model must also be attested.

​
Request headers

HeaderValue
X-E2EE-Version2
X-Client-Pub-KeyYour secp256k1 public key, hex encoded.
X-Model-Pub-KeyThe gateway E2EE public key from the attested keyset.
X-E2EE-NonceA unique per-request nonce.
X-E2EE-TimestampUnix seconds, close to gateway time.
Do not send X-Signing-Algo with E2EE; that header selects the legacy compatibility path.

​
Ciphertext format

Each encrypted field is the lowercase hex encoding of: 
ephemeral_uncompressed_secp256k1_public_key || aes_gcm_nonce || ciphertext_tag
The AEAD associated data binds the ciphertext to the protocol version, direction, algorithm, model, field path, nonce, timestamp, and response identity. Any mismatch fails decryption, so use the official client helpers rather than assembling the bytes by hand.

​
Receipts with E2EE

Receipts attach to E2EE requests exactly as they do to plain TLS requests. The request.received.body_hash is the hash of the gateway-observed decrypted body, not the encrypted bytes you sent. When you verify a response, compare request hashes against the decrypted body your client holds.

​
Next

E2EE encryption guide

Headers, key exchange, and code.

Trust boundary

Where plaintext is visible.