Most AI privacy controls begin after a prompt reaches the cloud. Solrouter, built by Router Labs, starts one step earlier: the prompt is encrypted on the user’s device, before the application backend receives it.
That design solves a specific problem. A useful AI assistant may need cloud-scale models, while the service operator keeps its application backend outside the plaintext path. Solrouter’s answer is device-to-enclave encryption: the client encrypts to a key held inside an attested Confidential VM, the backend relays ciphertext, and the protected workload opens the request only when inference begins.
This case study examines that path, how its privacy boundary changes by model, and what other AI teams can learn from Solrouter’s implementation on Phala Cloud.
The challenge: private prompts still need cloud-scale inference
Running every model on the user’s phone or laptop would keep data local, while model size and performance remain constrained by the device. Solrouter serves open-weight models ranging from 20B to 122B parameters, including a Qwen3.5 122B deployment on an NVIDIA H200. Those workloads require remote compute.
Standard transport encryption protects traffic between the device and a server. The server terminates that connection and processes the plaintext. Solrouter chose a stronger operating model: its application backend handles accounts, metering, and routing while remaining outside the prompt’s decryption boundary.
The resulting architecture separates the service operator’s backend from the key that opens the request.
The core decision: encrypt to the enclave
Solrouter currently supports two client encryption suites:
- Mobile on iOS and Android: X25519 ECDH, HKDF-SHA256, and XChaCha20-Poly1305.
- Web app, published SDK, and MCP server: X25519 with Arcium RescueCipher.
The enclave accepts both formats. Solrouter is migrating the web, SDK, and MCP paths to XChaCha20-Poly1305.
A sealed request follows this path:
- The client creates an ephemeral X25519 keypair and encrypts the prompt with the suite used by that client.
- The client sends ciphertext, its ephemeral public key, and a nonce to Solrouter.
- Solrouter’s backend authenticates and meters the call while acting as a blind relay.
- An Intel TDX Confidential VM on Phala Cloud derives the shared secret and decrypts the prompt inside hardware-isolated memory.
- The enclave runs orchestration and sends only the model inference call to the selected route.
- The enclave encrypts the response for the client before returning it through the backend.
The X25519 private key is generated inside the Confidential VM when it boots and stays inside the enclave. The application server carries ciphertext in both directions while it routes the request and returns the result.
The protected orchestration boundary includes tool calls, retrieval, agent steps, and task execution. Those operations run inside the Intel TDX CVM. Only the forward pass crosses to a model node when a route uses an external GPU.
Solrouter uses this pattern across its web chat, mobile apps, the @solrouter/sdk TypeScript package, and the @solrouter/mcp-server integration for AI clients such as Claude Code, Cursor, and Claude Desktop. Encryption is enabled by default on the SDK’s client.chat() path.
The defining design choice is the encryption destination: a workload key held by the enclave.
Read the detailed Solrouter request flow.
Proving which key the client is using
Client-side encryption protects the prompt when the destination key belongs to the intended confidential workload. Solrouter publishes the enclave’s X25519 public key together with a live Intel TDX attestation quote so that clients can verify that relationship.
Two report-data bindings establish two different claims:
- Attestation endpoint:
sha256(X25519 public key)shows that the enclave controls the sealing key used by the client. - Per-request receipt:
sha256(X25519 public key || Ed25519 public key)shows that the enclave also controls the Ed25519 key that signed the receipt.
Each receipt carries a bindingFormula field naming the formula used. Verifiers can read that field and recompute the corresponding binding.
Solrouter’s in-browser verifier focuses on the first binding check: it confirms that the key presented to the client is the key committed in the quote. Full validation of the quote against Intel’s signature chain is a separate DCAP step, available through the Phala verifier flow.
Phala’s dstack guest agent obtains the quote from the Confidential VM. During preparation of this case study, Solrouter’s live endpoints returned a version 4 TDX quote with TEE type 0x81. The public key matched the key in the attestation response, and the documented endpoint binding recomputed successfully.
The current verification scope covers genuine TDX hardware through DCAP validation and the enclave-key binding. Public reference measurements for comparing the complete application image remain on Solrouter’s roadmap. Publishing those values would let independent verifiers evaluate the exact workload identity in addition to the hardware and key.
Try the browser-based Solrouter enclave verifier, and read the Phala Cloud attestation overview.
Following the plaintext into the GPU
The enclave eventually provides plaintext input to a model. That makes the inference endpoint part of the privacy boundary.
The confidential H200 route
For Qwen3.5 122B, Solrouter runs vLLM on an NVIDIA H200 in confidential-computing mode on Phala. The Intel TDX enclave connects to an H200 CVM running TDX and NVIDIA confidential computing, extending the protected path into model execution.
This route is sealed-only. The Solrouter backend holds neither the H200 endpoint URL nor its credential; only the enclave can reach it. The request therefore remains inside confidential hardware from decryption through the model forward pass.
Rented Nosana routes
Solrouter also routes smaller open-weight models to rented Nosana GPU nodes. The TDX enclave still performs decryption, orchestration, retrieval, tool calls, agent steps, and task execution. The application backend remains a ciphertext relay and holds no decryption key.
The selected Nosana node receives the plaintext input needed for one inference call. It receives one forward pass rather than the user’s conversation history, surrounding context, retrieval state, or tool activity. Jobs have a 100-hour timeout and renew onto fresh hardware, limiting how much activity persists on any single node.
Solrouter documents this difference in a model-by-model privacy boundary matrix. That disclosure helps users choose among speed, model capability, and confidential-computing coverage.
The Qwen3.5 122B route represents Solrouter’s direction of travel. As usage grows, the team intends to move larger models onto Phala confidential GPUs and operate a Phala-only path, removing the remaining plaintext exposure at a conventional GPU node.
The broader lesson for AI builders is to follow plaintext through every component that processes it. CPU isolation protects orchestration; confidential GPU infrastructure can extend that boundary through inference.
Adding request-level evidence
Every sealed request across web, SDK, MCP, and mobile attempts to create a signed receipt. Inside the enclave, an Ed25519 key signs a tuple containing the encrypted prompt hash, client and enclave keys, nonce, model, and provider. A per-request TDX quote uses the combined X25519 and Ed25519 binding to associate the sealing and signing keys with attested hardware.
Solrouter can anchor that record to Solana as a Light Protocol compressed account. The chain stores evidence tied to the ciphertext while keeping the prompt itself private. A verifier can inspect the record, check the enclave signature, recompute the binding formula, and identify the model route.
Receipt availability is deliberately decoupled from inference. A Solana outage can degrade the receipt while the user’s request completes. The privacy path fails closed; the receipt path fails open.
The response carries an explicit attestationVerifiable boolean so callers can distinguish a verifiable receipt from a result whose on-chain commit is unavailable. Applications can require that flag, retry the commit, or accept the result according to their policy.
Read the Solrouter proof format.
What other AI teams can reuse
Solrouter’s implementation offers five practical design rules for cloud AI privacy:
- Start encryption in the client. Plaintext should first appear inside the workload selected to process it.
- Generate decryption keys inside confidential compute. Keeping the private key inside the enclave separates the application backend from prompt access.
- Bind every public key to a precise attestation claim. Endpoint and receipt keys establish different properties and require distinct formulas.
- Trace the privacy boundary through orchestration and inference. CPU isolation and GPU isolation protect different stages of the request.
- Publish each route’s guarantees and limits. Model-specific boundaries, reference measurements, and receipt availability belong in the security model users evaluate.
This architecture gives teams a practical path between small on-device models and conventional hosted AI. The device performs the encryption, while confidential cloud infrastructure supplies the compute needed for larger models.
Phala’s role in the system
Phala Cloud provides the Intel TDX Confidential VM that holds Solrouter’s sealing key and coordinates the protected request flow. dstack exposes the guest attestation interface used to bind that key to hardware evidence. For the Qwen3.5 122B route, Phala also provides the confidential H200 environment that extends isolation into model execution.
Solrouter builds the user-facing privacy layer on top: client encryption, backend routing, protected orchestration, SDK and MCP integrations, model selection, verification tools, and Solana receipts.
The division of responsibility is clear. Solrouter defines how users create and verify sealed requests. Phala and dstack provide the confidential-computing and attestation substrate behind the protected workloads.
From private chat to private agents
Solrouter now exposes this design through web chat, mobile clients, its TypeScript SDK, MCP, and x402 pay-per-call inference. The same architecture can support AI agents that handle source code, research, financial data, credentials, or operational context while using remote models.
The key insight extends beyond one product: AI privacy can preserve cloud-scale model access when the device controls where plaintext first appears. Client-side encryption, attested workload keys, protected orchestration, and confidential inference move that point from the application backend into a verifiable execution environment.
Try Solrouter at solrouter.com, explore the developer documentation, or add sealed AI calls with @solrouter/sdk.
