> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prem.io/llms.txt
> Use this file to discover all available pages before exploring further.

# How It Works

> Architecture overview: how the SDK or local proxy encrypts content for processing in the Prem confidential runtime.

## 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

```mermaid theme={"system"}
flowchart LR
    subgraph You["Your Device"]
        SDK["Prem API SDK"]
    end

    subgraph Platform["Prem API Platform"]
        Proxy["Proxy Gateway"]
        Enclave["Secure Enclave (TEE)"]
        Router["Model Router"]
    end

    subgraph Infra["Supporting Services"]
        S3["Encrypted File Storage"]
        VectorDB["RAG"]
        Redis["Redis Cache"]
    end

    SDK -->|"encrypted payload"| Proxy
    Proxy -->|"encrypted payload"| Enclave
    Enclave --> Router
    Router -->|"LLM inference"| Enclave
    Enclave --> S3
    Enclave --> VectorDB
    Proxy --> Redis
    Enclave -->|"encrypted response"| Proxy
    Proxy -->|"encrypted response"| SDK
```

## 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.

| What the Proxy does                             | What the Proxy cannot do            |
| ----------------------------------------------- | ----------------------------------- |
| Validate your API key and permissions           | Read your prompts or responses      |
| Enforce rate limits for your organization       | Access any encryption keys          |
| Route encrypted payloads to the correct enclave | Log or inspect your data            |
| Track usage for billing                         | Decrypt the files that you uploaded |

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](/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](/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](/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:

```mermaid theme={"system"}
sequenceDiagram
    participant You as Your Device
    participant Gateway as Proxy (sees only encrypted data)
    participant Enclave as Sealed Enclave (CVM)
    participant LLM as AI Model (inside CVM)

    Note over You: 1. Prepare
    You->>Enclave: Request enclave's public key
    Enclave-->>You: Public key

    Note over You: 2. Encrypt
    You->>You: Generate shared secret with enclave
    You->>You: Encrypt your message

    Note over You,Proxy: 3. Send (encrypted)
    You->>Proxy: Encrypted payload
    Note over Proxy: Check API key, rate limits
    Proxy->>Enclave: Forward (still encrypted)

    Note over Enclave: 4. Process (sealed hardware)
    Enclave->>Enclave: Decrypt your message
    Enclave->>LLM: Run inference
    LLM-->>Enclave: AI response
    Enclave->>Enclave: Encrypt response

    Note over Enclave,You: 5. Return (encrypted)
    Enclave-->>Proxy: Encrypted response
    Proxy-->>You: Forward (still encrypted)
    You->>You: Decrypt and display
```

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.

<Note>
  See the [Encryption](/encryption) reference for the full cryptographic details: algorithms, key types, and protocols. Continue to [Security Model](/security-model) for the security guarantees and their limits.
</Note>