Skip to main content
NEAR AI Cloud runs both the gateway and model inference inside Trusted Execution Environments (TEEs), providing strong hardware-level isolation. End-to-end encryption (E2EE) adds an additional layer of protection by encrypting your messages with the model’s public key before they leave your machine. This guide uses the NEAR model E2EE protocol. The gateway sends client-E2EE requests only to a compatible NEAR-serving path; if none is available, the request is unsupported rather than routed through a different E2EE protocol.

Why Use E2EE?

With E2EE enabled, your messages are encrypted client-side using the model’s public key, which is cryptographically bound to its TEE attestation. This provides:
  • Defense in depth — Multiple independent encryption layers on top of TLS
  • Model-specific encryption — Only model environments holding the attested model key can decrypt your messages
  • Cryptographic binding — Messages are tied to a verified TEE through attestation
  • Forward secrecy — Each request uses ephemeral keys

Via Gateway


Encryption Protocol

E2EE uses Ed25519 keys with the v2 encryption protocol: Wire format for all encrypted fields: [ephemeral_pubkey (32 bytes)][nonce (24 bytes)][ciphertext + tag]

Quick Start

A Python script that demonstrates the E2EE encryption flow after you have obtained a verified model public key: generate a client key pair, encrypt, send, and decrypt. For a gateway report, verify every returned model-attestation candidate before applying your acceptance policy to select a key; the endpoint-specific attestation guides describe those checks. Requirements: pip install requests PyNaCl cryptography
  • PyNaCl — Ed25519-to-X25519 key conversion and XChaCha20-Poly1305 AEAD
  • cryptography — X25519 ECDH key exchange and HKDF-SHA256 key derivation

Step-by-Step Guide

Step 1: Get the Model’s Public Key

Fetch the model’s Ed25519 public key from its TEE attestation report. The public key is generated inside the Model TEE and cryptographically bound to its hardware attestation. Reject a missing or empty model_attestations[], verify every returned candidate and its fresh nonce, then choose one verified report under your application’s acceptance policy. Use that report’s signing_public_key as the X-Model-Pub-Key routing pin. See NEAR model attestations. The gateway endpoint requires an API key (Authorization: Bearer <api-key>); report retrieval is free and never counts against your usage.
Request provider=near with a canonical model ID and x-no-aliasing: true. Reject a missing or empty model_attestations[], verify every returned model-report candidate with the nonce you generated, and retain only reports your application accepts. Select a key only from that verified set, then send its signing_public_key in X-Model-Pub-Key.

Step 2: Generate Client Key Pair

Generate an Ed25519 key pair for your client. The model will use your public key to encrypt the response.

Step 3: Encrypt Your Messages

Encrypt message content using the model’s public key. The protocol uses X25519 ECDH key exchange, HKDF-SHA256 key derivation, and XChaCha20-Poly1305 symmetric encryption.

Step 4: Make the Encrypted Request

Send your encrypted messages with the required headers. The model will decrypt your message, process it, and encrypt the response using your public key.

Required Headers


Step 5: Decrypt the Response

The response content, reasoning_content, and reasoning fields can contain hex-encoded encrypted data. Decrypt each field that is present using your private key.

Encrypting All Fields (Tool Calling)

By default, E2EE covers the message fields content, reasoning_content, reasoning, and audio.data. If you use tool calling, the tool definitions and the model’s tool calls also contain sensitive data. Send X-Encrypt-All-Fields: true to extend encryption to: With the flag set, encrypt each of these fields client-side with the model’s public key exactly like message content (the parameters JSON schema is serialized to a string and encrypted whole), and decrypt the corresponding response fields with your private key:
When continuing the conversation, encrypt the tool_calls you echo back on the assistant message and the tool result content on the tool role message the same way.
When using the server-side web search tool with E2EE, the injected nearai_tool_result.output chunks are always encrypted to your key, regardless of X-Encrypt-All-Fields.

Important Notes

Supported Endpoints

E2EE is supported on the Chat Completions API (/v1/chat/completions), Completions API (/v1/completions), Embeddings API (/v1/embeddings), and Images API (/v1/images/generations). The Responses API (/v1/responses) does not support encrypted input messages.

Message Format

  • Encrypted message content must be hex-encoded
  • The content, reasoning_content, and reasoning fields in responses can be hex-encoded encrypted data
  • Each streaming chunk’s content is independently encrypted

Verification

Before using a model public key for encryption, verify the attestation report and its fresh client nonce against hardware attestation. For a gateway response, verify every returned model-attestation candidate and choose a key only from reports accepted by your policy. See Verification for the Gateway verification flow.

Legacy: ECDSA Encryption

Get the Model’s ECDSA Public Key

Verify every returned model-attestation candidate and its fresh nonce before applying your acceptance policy and using a selected public key, as described in NEAR model attestations.

Generate ECDSA Client Key Pair

Encrypt with ECDSA

Send ECDSA Encrypted Request

Decrypt ECDSA Response


See Also