How It Works

Most AI providers see every word you send. Solrouter is built so that it cannot — even though it routes your traffic.

When you send a message, your prompt is encrypted on your device before it leaves your application. The Solrouter backend never sees plaintext. It forwards an opaque encrypted blob to an Intel TDX Confidential VM (a Trusted Execution Environment, or TEE — hardware that isolates code and data even from the machine's owner), where only attested enclave code can decrypt and process your request.

The enclave re-encrypts the response and returns it for you to decrypt locally. Unencrypted content never exists outside the enclave boundary.

Encryption Stack

This section walks through the four layers of the pipeline. Each is built so that a breach at any single layer — including Solrouter's own infrastructure — still does not expose your data.

Client-side encryption

Your prompt is encrypted before it leaves your device using Arcium's RescueCipher, a field-element symmetric cipher. The session key comes from an X25519 key exchange with the TEE's attested public key. The TEE generates its X25519 keypair inside the Confidential VM at boot and the private key never leaves the enclave, so only the enclave can derive the shared session secret. No one in the middle can.

Inference isolation

The Solrouter backend acts as a blind relay: it takes the encrypted blob and forwards it to an Intel TDX Confidential VM, a hardware-level Trusted Execution Environment where the host operating system and hypervisor cannot read enclave memory. Decryption, model inference, and response encryption all happen inside that isolated boundary — never on the open server.

Transport

The channel between your client and the enclave is encrypted end-to-end. The backend infrastructure handles only ciphertext, never plaintext content.

Verifiable attestation

You should not have to take our word that the right code is running. The enclave publishes an Intel-signed TDX quote that cryptographically binds its X25519 public key to the exact code measurement of the running image. Fetch the quote from GET /tee/attestation and verify for yourself that the enclave handling your request is the published, unmodified Solrouter code — not something we swapped in.

Request Flow

To make the guarantees concrete, here is the complete path a privacy-mode request travels — and where, at each hop, your data stays encrypted:

You (Browser / SDK)
    │
    ├── Arcium RescueCipher encrypts prompt client-side
    │   with TEE's attested X25519 public key
    │
    ▼
Solrouter Backend
    │
    ├── Cannot decrypt. Routes encrypted blob blindly
    │
    ▼
Intel TDX Enclave
    │
    ├── Hardware-isolated decryption inside the enclave
    ├── Runs the model on plaintext (in-enclave only)
    ├── Encrypts response with the session's ephemeral key
    │
    ▼
Solrouter Backend
    │
    ├── Still can't see anything
    │
    ▼
You
    │
    └── Decrypt with your ephemeral private key

What Is Not (Yet) Encrypted

Privacy claims are easy to inflate, so here is exactly where the guarantee ends today.

The honest summary: your prompt is encrypted in transit and isolated during compute inside a hardware-enforced enclave. The model runs on plaintext inside that enclave. That plaintext is inaccessible to Solrouter, the host, or anyone watching the network — but it is not processed under FHE.

Roadmap

The current TEE pipeline is a starting point, not the ceiling. Here is where the privacy model is headed and why your integration won't have to change to follow it.

Solrouter is built on Arcium's MXE (Multiparty eXecution Environment) substrate, which combines MPC, FHE, and ZK primitives. Choosing RescueCipher — a field-element cipher — was deliberate: the same encrypted payloads that flow through today's TEE pipeline can later be processed under MPC, FHE, or ZK circuits as Arcium's network matures, with no changes to the client encryption layer.

As the MXE network ships in production, more of the inference pipeline moves from TEE-isolated plaintext into cryptographic compute: MPC first, then FHE and ZK primitives where they make practical sense for latency and cost. When that shift happens, your integration stays the same — the encryption layer you use today is already compatible.