> ## 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.
# Security Model
> How Prem API enforces privacy at the hardware level: Trusted Execution Environments, attestation, and what it means for you.
**Summary:** The privacy of Prem API is not based on promises. It is based on hardware isolation and cryptographic proof. The processors from AMD, Intel, and NVIDIA seal your data so that nobody can access it. You can verify this independently. This page explains the mechanism and the limits.
## The Problem With Trust
Each AI API provider tells you that your data is safe. But traditional security relies on **trust**:
* Trust that employees do not access server memory
* Trust that the infrastructure provider does not inspect VMs
* Trust that the privacy policy matches the actual implementation
* Trust that a breach did not already occur
Prem API takes a different approach: **"don't trust, verify."** Hardware-enforced isolation and cryptographic attestation support each security claim that we make. You can check each claim independently.
## Trusted Execution Environments: The Foundation
A Trusted Execution Environment (TEE) is a sealed area inside a processor with its own encrypted memory. The key property: **no component outside the TEE can read or change the contents of the TEE**. The operating system cannot. The hypervisor cannot. The server administrator cannot. A person with physical access to the machine also cannot.
The hardware encrypts all data inside the TEE. A direct read of the RAM chip gives only scrambled data.
The TEE locks out the host OS, the hypervisor, and all other software on the machine. Only the code inside the TEE can access its memory.
The hardware measures (fingerprints) each piece of code that loads into the TEE. If one byte changes, the fingerprint changes. This makes tampering detectable.
The TEE can produce a hardware-signed report. The report proves exactly what code runs and that the isolation is intact. This mechanism is **attestation**.
### An Analogy
This example shows the principle. You send a sealed, tamper-evident envelope to a bank vault. The bank cannot open the envelope. The vault processes your request inside a sealed chamber. The vault then puts the result in a new tamper-evident envelope and sends it back. You examine the manufacturer's stamp to verify that the seal of the vault is genuine. If a person opened the vault or changed the contents, the stamp would be different.
A TEE does the same at the silicon level. Physics enforces the seal, not policy.
### CPU Confidential Computing
Prem API enclaves run on **Confidential Virtual Machines (CVMs)** with:
* **AMD SEV-SNP**: This technology encrypts VM memory with per-VM keys. A dedicated security processor inside the AMD chip manages the keys. The hypervisor cannot read or change guest memory.
* **Intel TDX**: This technology gives equivalent isolation with Intel Trust Domain Extensions. It provides memory encryption, integrity protection, and its own attestation system.
Both are industry-standard technologies that cloud providers use globally. Prem API supports both and can attest to either.
### GPU Confidential Computing
AI inference runs on GPUs, so CPU isolation alone is not sufficient. Prem API uses **NVIDIA GPUs (Hopper and Blackwell architectures) in confidential compute mode**:
* The hardware encrypts the GPU memory and isolates it from the host
* Data moves between the CPU and the GPU over an encrypted channel
* The GPU produces its own attestation report, which you can verify independently
* The host driver cannot access the contents of the GPU memory
Your data stays encrypted on the CPU and on the GPU. There is no gap where the data is exposed.
## The Infrastructure Locations
Prem API operates a **hybrid infrastructure**: hardware that we own, and capacity that we rent from providers. This is intentional. It gives us geographic flexibility and prevents lock-in.
**The security is the same in both environments.** The reason:
All machines are **unattended**. There is no operator access: no SSH, no console, no debug interfaces. The TEE hardware enforces isolation, independent of the owner of the physical server. Attestation gives identical cryptographic proof for our machines and for provider machines.
* **Owned infrastructure (Switzerland)**: The hardware is in Switzerland and operates under Swiss data protection law. We control the physical supply chain. The physical tampering risk is lower, but attestation proves the enclave state in each case.
* **Rented infrastructure (Europe, US)**: The hardware is primarily in Europe, with some deployments in the United States. The provider controls the physical hardware, but the TEE guarantees are identical: encrypted memory, measured boot, and hardware-signed attestation. The provider cannot access what runs inside the CVM.
**For compliance teams:** The attestation report is the same for each infrastructure owner. The report does not say "trust this machine." The report says that this specific code runs in a hardware-isolated environment with these exact measurements, and the hardware manufacturer signs it. This holds for our Swiss facility, for a European provider's data center, and for a US deployment.
**The CLOUD Act and foreign subpoenas:** A foreign government subpoena, for example under the US CLOUD Act, can only compel a cloud provider to supply what the provider possesses. In this case, the provider possesses encrypted memory dumps and ciphertext. Hot data stays inside the TEE, and the host and the provider never see it. So compelled disclosure gives no usable data.
## Everything Runs Inside CVMs
The sealed environment is not only the main enclave. **Each service that touches your unencrypted data runs inside Confidential Virtual Machines:**
| Service | Purpose | In CVM? |
| -------------------------------------- | --------------------------------------------------------- | :-----------: |
| **Prem API Enclave** | Decryption, encryption, request orchestration | Yes |
| **Model Router** | Directs requests to the correct AI model | Yes |
| **LLM Inference** | Runs the AI model on your prompt (all models self-hosted) | Yes (GPU TEE) |
| **Speech-to-Text** (Deepgram, Whisper) | Audio transcription | Yes |
The only component outside the CVM is the proxy gateway. The proxy gateway handles **only encrypted data** and has no access to the decryption keys. There is no point in the processing chain where your data exists in plaintext outside a CVM.
## Attestation: "Don't Trust, Verify"
Attestation is the mechanism that makes each claim above **provable, not promissory**. The process:
```mermaid theme={"system"}
flowchart TD
A["Hardware Manufacturer (AMD / Intel / NVIDIA)"] -->|"signs attestation keys at the factory"| B["TEE Hardware (CPU + GPU)"]
B -->|"measures everything loaded"| C["Enclave Code"]
C -->|"generates"| D["Attestation Report"]
D -->|"you verify"| H["Your Device (SDK or browser)"]
```
**The attestation report tells you:**
1. **What code runs**: The report contains a cryptographic fingerprint of each component, from firmware to application. If one byte changes, the fingerprint changes.
2. **That the hardware is genuine**: Keys rooted in the manufacturer (AMD, Intel, or NVIDIA) sign the report. Software cannot fake the report.
3. **That the isolation is active**: The debug interfaces are off, the security patches are applied, and confidential compute is enabled.
4. **That the report is fresh**: The report contains your random challenge (nonce). This proves that the report is a response to your specific request and not a replay from an earlier session.
The verification can run **directly in your browser**. Our attestation libraries compile to WebAssembly. So you do not need to trust a server to verify the proof.
**For non-technical readers:** Attestation is comparable to a notarized audit report for a server. The silicon of the hardware manufacturer does the audit instead of a human auditor. A cryptographic signature replaces a signature on paper, and it is mathematically impossible to forge this signature. You can check the signature yourself, instantly, from your browser.
See [Attestation](/attestation) for the full technical detail: CPU reports, GPU EAT tokens, certificate chains, and verification code examples.
## Layers of Defense
Prem API does not rely on a single security mechanism. Multiple independent layers protect your data. If one layer fails, the other layers hold:
| Layer | What It Does | Plain-Language Impact |
| ----------------------------------------------------- | ---------------------------------------------- | ---------------------------------------------------------------------------------- |
| **Transport encryption** (TLS 1.3) | Encrypts the connection | Prevents network eavesdropping |
| **End-to-end encryption** | Encrypts data from your device to the enclave | Our own servers cannot read your data in transit |
| **Quantum-resistant cryptography** | Uses algorithms that resist quantum computers | Your data stays safe, even if quantum computing matures |
| **CPU isolation** (AMD SEV-SNP / Intel TDX) | Seals enclave memory at the hardware level | Server operators and cloud providers cannot access data during processing |
| **GPU isolation** (NVIDIA Confidential Computing) | Seals GPU memory during inference | The hardware also protects the AI model processing |
| **Attestation** (hardware-signed, Rust/WASM verified) | Proves that the enclave runs the expected code | You can verify our security claims yourself |
| **Key sovereignty** | You hold the master encryption key | Your encrypted data stays unreadable, even after a full compromise of our platform |
## Common Questions
The proxy holds only encrypted data: no keys, no plaintext. The enclave runs inside hardware-sealed memory that the host OS cannot access. An attacker with full root access to the server sees only ciphertext.
The proxy handles billing data and authentication, but it has no cryptographic materials and no mechanism to read message content. The proxy stores authentication credentials as hashes. The proxy sees only encrypted payloads and metadata, such as API keys, timestamps, and request sizes. A compromised proxy is an availability risk, not a data exposure risk.
With end-to-end encryption, an intercept of the traffic gives only encrypted bytes. To break the encryption, an attacker must defeat a quantum-resistant algorithm (ML-KEM768) and a classical algorithm (X25519) at the same time.
Prem API uses hybrid encryption that combines quantum-resistant and classical algorithms. If a future quantum computer breaks the classical part, the quantum-resistant part keeps your data safe. This also protects against "harvest now, decrypt later" attacks. In this attack, a person stores your encrypted traffic today and tries to decrypt it with a quantum computer in the future.
The enclave images contain no operator access mechanism: no SSH, no debug ports, no admin backdoor. The hardware measures and attests the enclave code, so a modification is detectable. A rogue employee cannot access what runs inside the TEE.
Attestation detects this. Each component that loads into the enclave gets a cryptographic fingerprint. If a single byte changes, the fingerprint changes, and the verification fails on your device. You would know before you send data.
We write the full attestation verification stack in Rust. Rust removes full classes of security vulnerabilities (buffer overflows, memory corruption) at compile time. The stack runs as WebAssembly in a sandbox. An exploit of memory bugs in the verification code is not possible, because these bugs cannot exist in Rust.
All machines are unattended, and no operator access exists. The CPU and GPU hardware enforce the TEE isolation, not the data center operator. Attestation proves the enclave state with the same hardware-signed proof for our Swiss facility and for a rented data center.
## Shared Responsibility Model
Security is a partnership. Prem secures the infrastructure and the data lifecycle. Customers keep control of their applications and keys.
### The responsibilities of Prem
* Prem maintains the hardware isolation (TEEs) and the attestation infrastructure
* Prem secures data in transit, in use (in the CVM), and at rest
* Prem makes sure that models execute deterministically and securely
* Prem manages the physical infrastructure security and the platform availability
### Your responsibilities
* **Key management:** Generate, store, and rotate your encryption keys, for example the Key Encryption Key (**KEK**). Do not lose your master key. If you lose it, Prem cannot recover your data.
* **Application security:** Secure the endpoints and devices where the Prem API SDK runs. The SDK decrypts data on your local hardware.
* **Prompt and model level security:** Defend against prompt injections and jailbreaks in your specific AI workflows.
## Limitations
No security system is absolute. We think that transparency about limitations builds more trust than a claim that they do not exist.
**Prem API does not protect against:**
* **Hardware-level side-channel attacks**: Researchers found theoretical and practical side-channel vulnerabilities in TEE hardware. The manufacturers patch these vulnerabilities. The attestation reports include the firmware versions, so you can check the patch levels and we can enforce minimum requirements. Side-channel attacks could be possible in theory. But Prem API selects deployment locations that meet strict security criteria and can apply counter mechanisms to detect invalid states. This is an industry-wide challenge, not a challenge unique to Prem API.
* **A compromised hardware manufacturer**: If the root signing keys of AMD, Intel, or NVIDIA are compromised, the attestation guarantees become weaker. This is the shared root of trust for the full confidential computing industry.
* **Model behavior**: Prem API protects the privacy of your data during processing. Prem API does not control what the AI model itself does with context during a single inference pass. For example, model memorization is a model-level concern, not an infrastructure concern.
* **Metadata**: The proxy can see some metadata: the time of your requests, the size of the payloads, the API key that you use, and the rate limit counters. The content of your requests and responses is always encrypted.
See the [Encryption](/encryption) reference for the full cryptographic specification. Continue to [Attestation](/attestation) for the attestation detail: reports, tokens, and verification code.