Skip to main content
Nito returns a common attestation envelope with a versioned encryption transport identifier. The envelope preserves the evidence and key bindings needed for independent verification. Clients choose a transport using encryption_protocol, open the sealed model binding, and use its exact proof_format to select a verifier.

Transport selection

An unknown, empty, or null protocol must stop transport selection. Updated Nito CLI clients accept a known legacy transport alias and use the older provider field only when encryption_protocol is absent on an older gateway. An unknown explicit protocol never triggers that fallback. encrypted_supported reports route support. host_compatibility.codex and host_compatibility.claude_code report whether the resolved route is certified for the corresponding protected session. A recognized protocol alone does not grant session eligibility. The gateway selects signing defaults after resolving the encrypted route. An explicit signing_algo request remains supported and must match the returned signing material. Clients validate the returned algorithm and key shape before encryption.

Sealed model bindings

Generate an ephemeral X25519 key pair for the request. Keep the private key locally and send these headers on GET /api/v1/attestation or POST /api/v1/chat/fusion: A version 2 response carries model_binding with version: "x25519-aesgcm-v2". Its outer proof_format is attestation-evidence-v1, a neutral envelope marker. Open the binding before choosing a hardware verifier or field-encryption variant.
  1. Decode the binding’s hexadecimal ephemeral_public_key (32 bytes), nonce (12 bytes), and ciphertext (including the 16-byte authentication tag).
  2. Compute the X25519 shared secret using your request’s private key and the returned ephemeral public key.
  3. Derive the AES-256 key as SHA-256 of the UTF-8 bytes of nito-attestation-model-binding-v1, one zero byte, then the shared secret. Both envelope versions use this same derivation label.
  4. Open AES-GCM with that key, the binding’s nonce, and additional authenticated data made from the response’s model, one zero byte, and its outer attestation nonce, encoded as UTF-8. Use the outer nonce text exactly as returned.
  5. Decode the version 2 plaintext as UTF-8 JSON. provider_model_id is the exact native model binding; proof_format and attestation_subject carry the exact verifier metadata when present. Keep these values in request-local client state and check them against the unmodified signed evidence.
Reject unsupported envelope versions, malformed fields, failed authentication, and empty native model bindings. The gateway rejects invalid or low-order X25519 keys before provider work or billable Fusion dispatch. A version header without a key is rejected. Opening this gateway-generated envelope preserves transport integrity. Independent verification of the hardware signatures, keys, model binding, and freshness still follows. The requesting client can inspect the recovered metadata, and raw signed evidence and certificates can identify the operator.

Compatibility

Sending the key with version 1, or omitting the version, returns x25519-aesgcm-v1. Its decrypted plaintext is the native model ID as a UTF-8 string; the exact proof format and subject remain in the outer response. Updated clients accept both envelope versions and the older plaintext fields when talking to older gateways. Without a binding key, ordinary public callers receive neutral outer metadata and no native model binding. A temporary compatibility bridge preserves plaintext fields for narrowly identified shipped first-party browser, mobile, plugin, and CLI clients. New integrations should request version 2. The bridge remains until supported installed clients and mixed-version browser sessions can all read sealed bindings.

Public surfaces

Model discovery retains the capability flags clients use to select eligible models. Request-bound subjects and native model bindings come from the sealed attestation binding; signing material remains available in the envelope. Model-maker names remain available for model selection.

Verification

The common envelope preserves raw evidence, proof formats, certificates, native model bindings, signing material, and challenge checks. Hardware verification still depends on the evidence format. An envelope or protocol identifier alone is insufficient to establish a verified result. Check the returned nonce against your challenge. For request-bound evidence, verify the challenge binding inside the signed report. Transport-attested evidence binds the enclave connection; its echoed nonce serves correlation and does not prove per-request freshness. Follow the appropriate verification procedure. Raw evidence, certificates, and decrypted verifier metadata can identify the operator. The Web App keeps exact routed-model and enclave identifiers inside the collapsed Raw evidence section. Existing embedding model IDs also remain compatibility identifiers accepted by the embeddings endpoint. The public envelope does not promise operator anonymity.

Client rollout

Upgrade existing CLI installations before deploying a gateway that omits attestation_provider. Older releases require that field for both Confidential and Encrypted requests. Publishing a new CLI release alone does not update installed clients. The sealed-binding versions support mixed client rollouts through the compatibility behavior above. For ehbp-v1 routing headers, deploy the accepting gateway before clients that send only Nito-Encrypted-Model and Nito-Encrypted-Enclave-Url. Revert those clients before rolling the gateway back. Validate Confidential calls, supported Encrypted calls, and receipt verification against the intended gateway before completing rollout. Client-side encryption and evidence verification must remain active throughout.