Encryption

When you send a prompt to an AI provider, you normally trust that provider to read it, store it, and not misuse it. Solrouter removes that trust requirement. Your prompt is encrypted on your own device before it leaves, and Solrouter's backend never holds the key to read it.

Solrouter encrypts your prompts and responses with Arcium's RescueCipher cipher and X25519 key exchange (a fast, modern way for two parties to agree on a shared secret without ever transmitting it). The ciphertext travels through Solrouter's backend untouched, and is decrypted only inside a hardware-isolated Intel TDX Confidential VM — a TEE (Trusted Execution Environment: hardware that isolates code and data even from the machine's owner). Solrouter's backend is a blind relay: it routes encrypted blobs it cannot read, and the private key that could decrypt them never leaves the enclave.

Encryption components

Here are the three building blocks that make the guarantee work, and what each one does.

Client-side encryption

The first line of defense is simple: encrypt before you transmit. Your prompt is encrypted locally — in the browser or in your server process — before it is sent anywhere.

• RescueCipher — Arcium's field-element symmetric cipher. Arcium chose it for compatibility with MPC, FHE, and ZK computation, so the same encrypted payload can be processed under any of those paradigms as Arcium's network matures.
• X25519 key exchange — your SDK session generates an ephemeral (single-use, per-session) X25519 keypair. The shared secret is derived from your ephemeral private key and the TEE's attested public key.
• TEE-generated keypair — the TEE's own X25519 keypair is generated inside the Confidential VM at boot time. The private key never leaves the enclave — not even to Solrouter's own infrastructure.

Inference isolation

Your data has to be decrypted somewhere to run the model. The question is where, and who can see it. With Solrouter, decryption and inference happen exclusively inside an attested enclave.

• Intel TDX Confidential VM — a hardware-enforced TEE. Memory is encrypted by the CPU and inaccessible to the host OS, hypervisor, and any Solrouter process running outside the enclave.
• Plaintext exists only inside attested enclave memory — the moment the model finishes generating a response, it is re-encrypted with your session's ephemeral key before it exits the enclave.
• No host access — no Solrouter employee, server process, or privileged operator can read your prompt or response. This is a hardware guarantee, not a policy promise.

Transport

Encryption only helps if there is no gap where plaintext leaks in transit. There is none.

• All traffic between your client and the enclave is encrypted end-to-end. There is no TLS termination point where plaintext is visible to an intermediary.
• The Solrouter backend is a blind relay — it forwards encrypted blobs without being able to decrypt them. It never has the keys.

You (Browser / SDK)
    │
    ├── 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 with plaintext (in-enclave only)
    ├── Encrypts response with your ephemeral session key
    │
    ▼
Solrouter Backend
    │
    ├── Still cannot see anything
    │
    ▼
You
    │
    └── Decrypt with your ephemeral private key

Why RescueCipher?

You might wonder why Solrouter does not just use a familiar cipher like AES. The answer is about where your data can go next.

Most symmetric ciphers (AES-GCM, ChaCha20) are designed for classical computation. They are efficient on CPUs and GPUs but are not naturally compatible with the algebraic structures that MPC, FHE, and ZK proofs operate over.

RescueCipher is a field-element cipher — it operates natively over the same finite-field arithmetic that MPC, FHE, and ZK systems use. That gives you three things:

• The same encrypted payload you send today can, in principle, be processed directly under MPC or FHE computation without re-encryption.
• As Arcium's MXE (Multiparty eXecution Environment) network ships support for more cryptographic compute primitives, Solrouter's encryption layer does not need to change.
• You get a smooth upgrade path: stronger cryptographic compute guarantees over time, zero migration work on your side.

This is why Arcium chose RescueCipher as the cipher for its MXE substrate — and why Solrouter uses it today, even before full MPC/FHE inference is live.

What encryption does NOT cover (yet)

Privacy claims in this space are often inflated, so here is the honest line on what Solrouter does and does not do today.

To be precise about what is and is not guaranteed today:

Encryption options in the SDK

Encryption is on by default — you do not have to do anything to get it. You can turn it off for a faster plaintext path, but you give up every privacy guarantee on this page when you do.

// Default — fully encrypted (recommended)
const response = await client.chat('Your prompt', { encrypted: true });

// Plaintext path — faster, no encryption guarantees
const response = await client.chat('Your prompt', { encrypted: false });