How It Works

​

The Simple Version

This is the core idea, before the architecture diagrams:

1. You type a prompt.
2. Your device encrypts the prompt before it sends data over the network.
3. Our gateway receives the encrypted payload. The gateway handles authentication and billing, but it cannot read your data.
4. The encrypted payload enters a sealed hardware environment (a Confidential Virtual Machine). There, the enclave decrypts the payload, the AI model processes it, and the enclave encrypts the response again.
5. The encrypted response travels back to your device. Your device decrypts the response and shows it.

Your data is plaintext in your application and, when used, the local Confidential Proxy. The protected runtime must decrypt it to process the request. The network-facing Prem gateway handles ciphertext plus authentication, routing, size, timing, and billing metadata.

​

Architecture Overview

​

The Components

​

Your Device: The Prem API SDK

The SDK runs on your side: your laptop, your server, your application, or your browser. It is the only location, besides the sealed enclave, where your data exists in readable form. The functions of the SDK:

• Encrypts all data before the data leaves your device, with modern, quantum-resistant cryptography
• Holds your master encryption key: a key that you generate and that never leaves your device
• Decrypts responses when they come back

From the perspective of your code, the SDK operates like the standard OpenAI SDK. The encryption is invisible. The SDK does the encryption automatically.

​

PREM API: The Blind Gateway

The proxy is the entry point of the platform. The proxy handles the operational tasks: it checks your API key, enforces rate limits, tracks usage for billing, and routes requests. The critical point: the proxy never sees your actual data. The proxy processes only encrypted payloads and metadata, such as API keys and timestamps. It has no encryption keys and no method to decrypt the data that passes through it. If an attacker compromises the Prem API Gateway, the intended exposure is encrypted content plus operational metadata. A local Confidential Proxy is different: it is a client-side plaintext termination point and belongs inside your local trust boundary.

​

Prem API Enclave: The Sealed Processing Environment

The enclave is the location where your data is processed. The enclave runs inside a Trusted Execution Environment (TEE), a sealed area of the processor with its own encrypted memory. The rest of the system cannot access this memory. The enclave is comparable to a bank vault inside a building. The building owner has keys to every room. But the vault has its own lock, and the building owner cannot open this lock. In this analogy, the “building” is the server. The “building owner” is the operator of the server: us, or our infrastructure provider. The “vault” is the TEE. The steps inside the enclave:

1. Your encrypted payload arrives.
2. The enclave decrypts the payload with a secure key exchange.
3. The AI model processes your request.
4. The enclave encrypts the response before the response leaves.
5. The enclave wipes all plaintext from memory.

The enclave runs on AMD SEV-SNP or Intel TDX processors, with NVIDIA Hopper and Blackwell architecture GPUs in confidential compute mode. The hardware enforces the isolation. The isolation is not a software setting that admin privileges can turn off.

​

Model Routing

Model routing selects a backend for the requested alias, applies health and capacity decisions, and associates an attestation session with the subsequent request. The public API does not currently expose a machine-readable provider-backed or Reticle-verifiable assurance profile. Do not infer the complete backend trust boundary from an alias. See Platform Status for the current limitation.

​

Confidential boundary

The intended confidential boundary contains the components that decrypt or process protected content. The network gateway remains outside and handles encrypted payloads plus operational metadata. A complete assurance decision needs attestation evidence, approved measurements, and a route profile. The current API does not expose all three, and the reviewed CPU verifier still has TODOs for expected measurement comparison. See Attestation.

​

The Infrastructure Locations

Prem API runs on a hybrid infrastructure, a mix of hardware that we own and capacity that we rent:

• Owned infrastructure is in Switzerland, under Swiss data protection law
• Rented infrastructure is primarily in Europe, with some deployments in the United States

TEE hardware is designed to reduce trust in the host operator. Deployment access controls, geography, and unattended-operation claims are operational controls that must be audited separately. Attestation explains what the current client verifies and what remains policy work.

​

The Lifecycle of a Chat Request

This is the full lifecycle of a chat request: For streaming responses (word-by-word output in the style of ChatGPT), the enclave encrypts each chunk individually before it sends the chunk. The proxy forwards the chunks and does not buffer or inspect them.

​

The Tasks That the SDK Does for You

The SDK does all these tasks automatically. You do not need to:

• Understand or manage encryption algorithms
• Do key exchanges manually
• Encrypt or decrypt data in your application code
• Handle streaming decryption

From the perspective of your application, you make standard API calls and get standard responses. The encryption layer is fully invisible.