Chutes Introduces End-to-End Encrypted AI Inference with Post-Quantum Cryptography

Every interaction with an AI system carries an implicit assumption that most users rarely question, which is that the provider can see everything.

For low-stakes use cases, this assumption feels harmless. However, as AI becomes embedded in real-world workflows, the nature of the data being shared changes significantly, and so does the risk attached to it.

A physician reasoning through patient symptoms is transmitting protected health information. An attorney summarizing a deposition is working with privileged communication. A quantitative analyst testing a trading strategy is exposing proprietary intellectual property where even a small leak could carry significant financial consequences. Beyond professional environments, companies querying internal tools are surfacing sensitive business data, while individuals discussing personal matters are sharing information they would expect to remain private.

In each of these cases, the expectation is not convenience alone, it is confidentiality.

The challenge is that most AI systems today do not enforce confidentiality at an architectural level. Instead, they rely on trust.

Why Trust Fails in Practice

The reality of modern AI infrastructure is more complex than a simple request-response interaction. When a prompt is sent to an AI provider, it typically passes through multiple layers of infrastructure before reaching the model, including:

a. API gateways and load balancers,

b. Logging and monitoring systems,

c. Safety filtering and abuse detection pipelines,

d. Internal debugging workflows, and

e. External contractors involved in data labeling and quality assurance.

Each of these layers introduces additional exposure, often across organizations and jurisdictions that the end user has no visibility into.

Even when providers state that they do not train on user data, the infrastructure itself still has access to it. Prompts may pass through systems that log, inspect, or retain information, and in some cases, those systems can be accessed by employees or third-party contractors. The result is a situation where sensitive data may be visible to parties the user neither knows nor explicitly trusts.

The issue is not necessarily malicious intent, it is that the system is designed in a way that makes access possible.

Chutes’ Approach: Making Access Impossible

Chutes (Bittensor Subnet 64) addresses this problem by shifting the model from trust-based privacy to architecture-based guarantees.

Rather than relying on policies or assurances, Chutes ensures that user data cannot be read by any intermediary, including Chutes itself, by implementing true end-to-end encryption for AI inference.

This means:

a. Prompts are encrypted on the client before transmission,

b. Data moves through the API as unreadable ciphertext,

c. Decryption occurs only inside a hardware-isolated environment,

d. Responses are re-encrypted before leaving that environment, and

e. Final decryption happens only on the client side.

At no point in this flow can Chutes, the hosting provider, or any network intermediary access the plaintext.

How the Chutes E2EE Architecture Works

The Chutes system is designed as a complete, verifiable pipeline that preserves encryption from end to end while still enabling full AI inference.

The End-to-End flow goes thus;

a. Client Preparation and Encryption: The client retrieves available instances, along with public keys and single-use nonces, then encrypts the request locally using ML-KEM-768 and ChaCha20-Poly1305.

b. Secure Transmission Through the API: The encrypted payload is sent through the Chutes API, which validates the nonce and routes the request, but cannot decrypt or inspect its contents.

c. Execution Inside a Trusted Execution Environment: The request is delivered to a GPU instance running inside an Intel TDX Trusted Execution Environment, where it is decrypted and processed.

d. Response Encryption: The result is encrypted within the same enclave before leaving the environment.

e. Client-Side Decryption: The client receives and decrypts the response locally, restoring the original output.

This flow ensures that encryption is never broken outside of a controlled, hardware-isolated environment.

The Cryptographic Stack Behind Chutes

Chutes’ design relies on a combination of post-quantum and modern symmetric cryptographic primitives, each serving a specific role within the pipeline. The core component of this stack includes:

a. ML-KEM-768 (Kyber): Used for key encapsulation, enabling secure exchange of shared secrets that are resistant to both classical and quantum attacks.

b. HKDF-SHA256: Used to derive distinct symmetric keys for request, response, and streaming contexts from shared secrets.

c. ChaCha20-Poly1305: Provides authenticated encryption, ensuring both confidentiality and integrity of all payloads.

d. Gzip Compression: Applied before encryption to reduce payload size and normalize entropy distribution.

This design ensures that each request uses a fresh ephemeral keypair, ensuring complete isolation between interactions, shared secrets are never reused directly and are transformed into purpose-specific keys, and encryption guarantees include both confidentiality and tamper detection.

This structure ensures that compromising one request does not expose any other, and that all communication remains cryptographically isolated.

Why Post-Quantum Cryptography Matters

Chutes explicitly adopts post-quantum cryptography to address a long-term but well-understood threat model.

Encrypted data transmitted today can be recorded and stored by adversaries, with the intention of decrypting it in the future once more powerful computational methods, including quantum computing, become available.

This “harvest now, decrypt later” model is particularly relevant for sensitive data such as:

a. Medical records,

b. Legal communications, and

c. Proprietary business strategies.

By using ML-KEM-768, Chutes ensures that even if future advances in computing occur, captured data remains secure because the underlying cryptographic assumptions are not vulnerable to known quantum attacks.

Combined with ephemeral keys, this means that no long-lived key exists whose compromise could expose historical traffic.

Verifying the Environment: TEE Attestation

A critical component of the system is ensuring that encryption endpoints are genuine and have not been replaced by an attacker. Chutes achieves this through hardware attestation using Intel TDX.

What this attestation confirms is that

a. The public key used for encryption was generated inside a genuine TEE,

b. The environment is running the expected, verified software stack,

c. The system is not operating in debug mode, and

d. GPU resources are genuine and operating in confidential compute mode.

The attestation process binds a client-generated nonce to the enclave’s public key, ensuring that the verification is both fresh and specific to the current session.

This allows users to independently verify that their data will only be decrypted within the intended secure environment.

Replay Protection Through Nonce Design

To prevent replay attacks, Chutes enforces strict nonce usage across all encrypted requests. Nonces are used:

a. Each request includes a single-use nonce tied to a specific instance,

b. Nonces are validated and consumed atomically by the API, and

c. Invalid, expired, or reused nonces are rejected immediately.

This guarantees that captured requests cannot be replayed, requests cannot be redirected to unintended instances, and each interaction remains unique and isolated

Clear Trust Boundaries Across the System

One of the strengths of the Chutes architecture is its precise definition of what each component can and cannot access. Its visibility model consists:

a. Client: Full access to plaintext input and output,

b. Chutes API: Access only to ciphertext, routing data, and usage metadata,

c. Network Infrastructure: Encrypted traffic only,

d. TEE Instance: Temporary access to plaintext during execution, and

e. Host System and Provider: No access to decrypted data.

The API can observe usage metrics such as token counts for billing, but cannot read the content of prompts or responses.

Integration Without Complexity

Chutes provides two integration approaches that abstract away the underlying cryptographic complexity while preserving full security guarantees.

Available integration paths are:

a. Python HTTP Transport: A drop-in transport layer for OpenAI-compatible SDKs that automatically handles encryption, key exchange, nonce management, and decryption.

b. Local E2EE Proxy: A Docker-based reverse proxy that enables encrypted inference across different languages and SDKs without requiring code changes.

Both approaches maintain identical security properties, allowing developers to adopt end-to-end encryption without restructuring their existing workflows.

Raising the Standard for AI Privacy

The current default for AI systems assumes that users are willing to trust providers with their most sensitive data.

Chutes challenges this assumption by demonstrating that trust is not necessary when systems are designed correctly.

By combining end-to-end encryption, post-quantum cryptography, hardware attestation, and strict nonce enforcement, Chutes creates an environment where:

a. Data is never exposed outside secure boundaries,

b. Access is technically impossible rather than policy-restricted, and

c. Security remains intact even against future computational threats.

This is not a marginal improvement in privacy, but a fundamental shift in how AI systems can be trusted, not by belief, but by design.

As AI continues to move into domains where confidentiality is critical, architectures like this are not optional enhancements.

They are the baseline.