Skip to content

E2EE

Guides

End-to-end encryption

Encrypt prompts to a hardware-attested key fetched directly from Venice, so Tokentide only ever relays ciphertext.

For workloads that need a cryptographic guarantee rather than a policy, Tokentide relays Venice’s end-to-end encrypted inference. You encrypt your messages to a public key that lives inside a hardware enclave, and Tokentide only ever sees ciphertext.

ItemValue
EndpointPOST /v1/chat/completions only (not /v1/responses)
Modelse2ee-* model ids (for example e2ee-glm-5-3-p, e2ee-qwen3-6-35b-a3b, e2ee-kimi-k3-p)
StreamingRequired: stream: true
LaneStandard only (Low Tide is non-streaming)
Privacy modeE2EE models count as private, so the default private key mode allows them
Response tierX-Tokentide-Model-Privacy: e2ee; Venice’s X-Venice-TEE and X-Venice-TEE-Provider are passed through

Trust model

  • The key comes from the hardware, through Venice, never through us. You fetch the model’s attestation directly from Venice and verify it against the hardware vendor’s certificate chain. That proves the public key belongs to an enclave running the expected software.
  • A proxy must never be the source of the model public key. If Tokentide (or anyone in the middle) handed you the key, a compromised proxy could hand you its own key, decrypt everything and re-encrypt it to the enclave without you noticing. Fetching and verifying the attestation yourself closes that hole: even a fully compromised Tokentide can only relay ciphertext it cannot read.
  • What Tokentide relays. Tokentide forwards the three E2EE headers verbatim and does not modify the request body. It does not inject anon_user_id, user or prompt_cache_key on E2EE requests, and it never logs bodies.
  • What happens at Venice. Venice’s TEE gateway decrypts inside an attested enclave and forwards to the inference hosts over TLS. Read Venice’s TEE and E2EE documentation for the current details of that trust model; we describe it as Venice publishes it, no more.

How to send an E2EE request

  1. Fetch the attestation directly from Venice

    Use your own random nonce (32 random bytes as 64 hex characters):

    Fetch the attestation from Venice
    NONCE=$(openssl rand -hex 32)
    curl "https://api.venice.ai/api/v1/tee/attestation?model=e2ee-glm-5-3-p&nonce=$NONCE"

    No authentication is needed. Venice limits this endpoint to 10 requests per minute per IP address, so cache a verified attestation for the life of your session.

  2. Verify it before trusting the key

    • the report is bound to your nonce (replay protection);
    • the hardware quote chains to the vendor’s root of trust (for example Intel TDX verified with DCAP, plus the GPU attestation when present);
    • the enclave’s public key is bound to the verified report, and the model matches the one you will call.
  3. Encrypt your messages

    Generate a per-session secp256k1 key pair and encrypt every user and system message to the model’s public key, as specified by Venice (ECDH, then HKDF-SHA256, then AES-256-GCM).

  4. Send the request to Tokentide

    Add the E2EE headers and stream: true:

    Send the encrypted request to Tokentide
    curl https://api.tokentide.app/v1/chat/completions \
      -H "Authorization: Bearer $TOKENTIDE_API_KEY" \
      -H "Content-Type: application/json" \
      -H "X-Venice-TEE-Client-Pub-Key: $CLIENT_PUBLIC_KEY_HEX" \
      -H "X-Venice-TEE-Model-Pub-Key: $MODEL_PUBLIC_KEY_HEX" \
      -H "X-Venice-TEE-Signing-Algo: ecdsa" \
      -d '{"model": "e2ee-glm-5-3-p", "stream": true, "messages": [{"role": "user", "content": "<ciphertext>"}]}'
  5. Decrypt the streamed content

    Decrypt each streamed delta locally with your private key.

Venice injects nothing into E2EE requests either: no Venice system prompt, characters, web search or scraping. file content parts are rejected, and Venice lists function calling as unsupported on E2EE. Without the E2EE headers the same models run in TEE-only mode.

Venice also publishes per-request TEE signatures that you can fetch from Venice for a response id, to check that the enclave produced the response you received. See Venice’s TEE and E2EE guide.

Billing

Pricing is the same as for any Standard request. Tokentide bills from the stream’s final usage and cost chunk when it is readable. If it is not, the request is settled provisionally at its worst-case cost and trued up against Venice’s own ledger for that request id; the difference is credited back automatically.

Whether usage chunks stay readable on E2EE streams is being verified before launch.

Errors

Malformed E2EE headers come back from Venice as 400 (passed through with Venice’s body). A stale attestation shows up as an in-band stream error (for example code: "e2ee_attestation_stale") followed by data: [DONE]: fetch and verify a fresh attestation, then retry. Tokentide’s own errors are listed in Errors.