> ## 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 > Prem API threat boundaries, confidential-computing controls, attestation evidence, and current limitations. > [!NOTE] > > **Summary:** Prem API combines client-side encryption with confidential-computing hardware and attestation evidence. The strength of any claim depends on the verified evidence, an approved measurement/TCB policy, and the route that processed the request. The current limitations are documented below and on [Attestation](https://docs.prem.io/attestation.md). > [!NOTE] > > **Scope:** This page tells you about the **confidential inference** path only. [Zero Data Retention](https://docs.prem.io/zdr/overview.md) is a different mode with a different boundary. It has no client-side encryption, no Trusted Execution Environment, and no attestation. See [ZDR security boundary](https://docs.prem.io/zdr/security-boundary.md). ## 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 combines hardware isolation with attestation evidence. A complete decision still requires manufacturer trust, approved measurements and TCB policy, route assurance, and deployment-specific controls. ## Trusted Execution Environments: The Foundation A Trusted Execution Environment (TEE) is designed to isolate a workload and its memory from the host operating system and hypervisor. The exact confidentiality and integrity guarantees depend on the hardware architecture, firmware, configuration, and known vulnerability state. > [card] Protected memory > > Confidential-computing hardware protects designated workload memory according to the selected CPU or GPU architecture and configuration. > [card] Host isolation > > A TEE is designed to restrict the host operating system and hypervisor from reading or modifying protected workload memory. > [card] Measured state > > Hardware evidence carries architecture-defined measurements. A verifier must compare them with an approved reference before treating a change as a policy failure. > [card] Provable Integrity > > The TEE can produce hardware-signed evidence that includes measurements and security claims. A verifier must compare those values with an approved policy before concluding that the expected workload is running. ### An Analogy As a mental model, think of a sealed request processed inside a restricted chamber and returned in a new sealed envelope. The model explains the intended data boundary. It does not replace the hardware threat model, attestation policy, or software review. ### The Hypervisor We developed our own hypervisor based on KVM (Kernel-based Virtual Machines), it does manage the virtual machines that host the enclave workload. Our hypervisor code is not open source, but the security model does not require you to trust it. The confidential-computing threat model treats the hypervisor as untrusted by design: the **CPU hardware** — not the hypervisor — enforces the isolation and memory encryption that protect the enclave and its trusted peripherals, such as confidential GPUs and the virtual TPM (vTPM). The attestation report is signed by the hardware and measures the enclave state directly, so a client can verify what is running independently of the hypervisor. A malicious or compromised hypervisor cannot read protected memory or forge that evidence without breaking the hardware guarantees. ### CPU Confidential Computing Prem API enclaves run on **Confidential Virtual Machines (CVMs)** with: * **AMD SEV-SNP**: Protects guest memory with hardware-managed keys and supplies an attestation report for policy evaluation. * **Intel TDX**: Creates an Intel trust domain with protected memory and a quote for policy evaluation. Reticle implements separate evidence-verification paths for SEV-SNP and TDX. Their evidence formats, trusted computing bases, and security properties are not interchangeable. ### GPU Confidential Computing During inference, prompts, model weights, and intermediate results are processed in GPU memory. NVIDIA confidential computing extends the confidential VM's protection to this part of the workload: hardware access controls isolate GPU memory from the host, and transfers between the CVM and GPU are encrypted through a shared staging area called a **bounce buffer**. The GPU computes on plaintext inside its protected boundary. These protections require a supported GPU model, compatible firmware and drivers, and an enabled production confidential-computing mode. See [NVIDIA's description of GPU isolation and encrypted transfers](https://developer.nvidia.com/blog/confidential-computing-on-h100-gpus-for-secure-and-trustworthy-ai/). Reticle verifies the attestation evidence for every GPU included in the response. It checks token signatures against NVIDIA's keys, checks that each token contains the client's fresh challenge (the **nonce**), and requires a passing firmware and configuration measurement result for each GPU. For multi-GPU responses, verification succeeds or fails for the set; the public result does not expose individual GPU verdicts. These checks establish the reported GPUs' attested state, but do not prove that those GPUs served a particular inference request. Protecting the full request also requires routing it to the attested hardware and keeping every component that handles plaintext within the trusted processing boundary. See [Multi-GPU attestation and load balancing](https://docs.prem.io/attestation.md#multi-gpu-attestation-and-load-balancing) for the current verification limits. #### NVIDIA MPT CC on Blackwell Our Blackwell deployments (**HGX**) run the GPUs in NVIDIA's **Multiple GPU Passthrough with a Bounce Buffer (MPT CC)** mode. In this mode, GPU-to-GPU traffic is encrypted: GPUs inside the same CVM communicate peer-to-peer over encrypted NVLink connections. The matrix below compares the confidential-computing modes: | | Single GPU Passthrough (SPT CC) | Hopper Multiple GPU Passthrough (PPCIe) | Blackwell MPT CC | | - | - | - | - | | GPUs per CVM | One | Multiple (Hopper) | Up to eight (Blackwell) | | Host-to-GPU PCIe data | Encrypted via bounce buffer | Encrypted via bounce buffer | Encrypted via bounce buffer | | GPU-to-GPU NVLink data | Not applicable (single GPU) | **Not encrypted** | **Encrypted** | ### The Confidential Runtime The confidential runtime has the measured boot, the operating system, the serving stack, and the model weights. The runtime is in development. We plan to open-source a hardened, read-only confidential-VM base image — minimal packages and dependencies, a reduced attack surface, and a verifiable root of trust — and to publish public transparency logs for CVM images so customers can audit changes. An open-source way to verify the model weights, the serving engine code, and the configuration is part of the same plan. ## The Infrastructure Locations Prem API deployments can use Prem-owned hardware and rented provider capacity. Confirm the exact location, operator, hardware, and policy for the route that your workload uses. TEE evidence can reduce trust in the physical and cloud operator in both owned and rented environments. It does not make their complete operational risk identical. Physical controls, administrator access, firmware supply chain, geography, and incident response remain separate audit inputs. * **Owned infrastructure:** Prem controls more of the physical and operational stack. Attestation evidence does not replace physical-security and change-management review. * **Rented infrastructure:** The provider controls the physical host. Confidential-computing controls are designed to restrict host access, while attestation evidence lets a client inspect hardware claims and freshness. > [!NOTE] > > **For compliance teams:** Manufacturer evidence is one audit input. Current CPU Reticle verification authenticates evidence and freshness but does not yet compare measurements with an approved release reference. Geography and infrastructure ownership remain independent controls. > [!NOTE] > > **Legal scope:** Confidential computing can reduce the plaintext held by infrastructure operators, but it does not eliminate legal obligations, metadata disclosure, endpoint access, or jurisdictional risk. Obtain jurisdiction-specific legal advice for regulated deployments. ## Confidential processing boundary The intended boundary includes every service that decrypts or processes protected content. The Prem API Gateway handles encrypted payloads plus API-key, model, size, timing, routing, and billing metadata. A local Confidential Proxy is a separate plaintext component on the client side. The current public response does not expose a complete route-assurance profile. Verify the selected model path and deployment policy before transferring confidential-compute claims to a specific model. ## KV-Cache and Multi-Tenant Isolation The KV cache (Key-Value cache) is not shared across serving engines or TEEs. Each enclave keeps its own KV cache inside its protected memory, so cached context never crosses the enclave boundary and cannot leak to the host or to another serving engine. This is what enforces multi-tenant isolation: because no cache is shared between tenants, one workload cannot read, reconstruct, or infer the cached context of another workload. Each request is served from a KV cache that lives entirely within a single tenant's confidential-computing boundary. ## Attestation evidence and policy Attestation supplies evidence for selected hardware and workload claims. The client still needs an explicit acceptance policy: ```mermaid theme={"system"} flowchart TD A["Hardware Manufacturer (AMD / Intel / NVIDIA)"] -->|"signs attestation keys at the factory"| B["TEE Hardware (CPU + GPU)"] B -->|"records architecture-defined measurements"| C["Measured Workload State"] C -->|"generates"| D["Attestation Report"] D -->|"you verify"| H["Your Device (SDK or browser)"] ``` **The attestation report tells you:** 1. **Measurements and claims**: The report carries hardware-defined measurements and security-relevant fields. 2. **Evidence authenticity**: The verifier validates the applicable manufacturer certificate or key chain. 3. **Freshness**: The report contains the verifier's nonce. 4. **Policy decision**: A separate policy must decide whether measurements, TCB, debug, and confidential-mode claims are acceptable. Reticle can compile to WebAssembly for supported JavaScript environments. A browser integration can therefore run the verifier locally, but it must still use trusted collateral, approved references, and an explicit failure policy. > [!TIP] > > **For non-technical readers:** Attestation is comparable to a signed hardware inspection record. The signature authenticates the source of the evidence. Your policy still decides whether the reported configuration is acceptable. See [Attestation](https://docs.prem.io/attestation.md) for the full technical detail: CPU reports, GPU EAT tokens, certificate chains, and verification code examples. ## Layers of Defense Prem API uses several controls for different risks. These controls are not interchangeable, and one control does not guarantee that another remains effective after a failure: | Layer | What It Does | Plain-Language Impact | | - | - | - | | **Transport encryption** (TLS 1.3) | Encrypts the network connection | Protects against passive network observation within the TLS threat model | | **Client payload encryption** | Encrypts the request payload from the client to the protected processing path | Limits plaintext exposure at the Prem gateway | | **Post-quantum component** | Uses ML-KEM768 as part of a hybrid key exchange | Reduces reliance on classical public-key exchange alone | | **CPU isolation** (AMD SEV-SNP / Intel TDX) | Protects designated confidential-VM memory | Restricts host access according to the hardware and deployment configuration | | **GPU isolation** (NVIDIA Confidential Computing) | Protects designated GPU processing and memory | Requires supported hardware, firmware, drivers, mode, and verified evidence | | **Attestation** (hardware-signed, Rust/WASM verified) | Authenticates hardware evidence and freshness; policy must approve measurements and TCB | Reduces reliance on operator assertions | | **Client KEK custody** | You generate and retain the Key Encryption Key | Separates client key custody from the Prem API key and server-side routing | ## Common Questions > [accordion] What if someone hacks your servers? > > The intended network-gateway exposure is encrypted content plus operational metadata. A compromise can still affect availability, routing, replay attempts, metadata, and software supply chain. The local Confidential Proxy is a plaintext component and must be secured separately. > [accordion] What if the proxy is compromised? > > Distinguish the Prem API Gateway from the local Confidential Proxy. The gateway is intended to handle ciphertext and operational metadata. The local proxy handles plaintext, the API key, and the KEK on your machine; compromise of that local process can expose content and credentials. > [accordion] What if someone intercepts the network traffic? > > The observed payload is encrypted by TLS and the client payload-encryption layer. Security still depends on correct endpoint authentication, key handling, implementation, and the assumptions of the hybrid key exchange. > [accordion] What about quantum computers? > > Prem API uses a hybrid exchange that combines ML-KEM768 and X25519. The design reduces reliance on X25519 alone for the harvest-now, decrypt-later threat model. It does not support an absolute claim about future cryptographic security. > [accordion] What if a Prem API employee goes rogue? > > TEE isolation is intended to restrict host access, while deployment access controls and change management reduce operator risk. The current CPU verifier does not yet compare measurements with an approved release reference, so operational controls and audit evidence remain necessary. > [accordion] What if someone tampers with the enclave code? > > Hardware evidence contains measurements that can change when measured components change. Detection requires a verifier to compare those values with an approved reference. The comparison happens through the configured OPA policy (published in [prem-research/confidential-policies](https://github.com/prem-research/confidential-policies)). > The shipped golden policy pins no image measurements by default, so expected-code detection requires operator-supplied reference values. > [accordion] What if there's a bug in the verification code itself? > > Reticle is implemented in Rust and can compile to WebAssembly. Rust prevents many memory-safety bugs in safe code, while unsafe code, dependencies, logic errors, policy errors, and runtime vulnerabilities still require review and testing. > [accordion] What if the cloud provider or data center operator is malicious? > > Confidential-computing hardware is designed to reduce trust in the host operator. Manufacturer evidence, approved measurements, firmware policy, physical controls, and incident response must all be evaluated; infrastructure ownership does not make those risks identical. > [accordion] How does Prem protect response integrity? > > For each request, the system does a fresh key exchange with the enclave. The enclave encrypts the response with a secret unique to that request. The proxy cannot change the response. The proxy cannot send a different response. See [Encryption](https://docs.prem.io/encryption.md) for more information. ## Shared Responsibility Model Prem operates the managed infrastructure and protected-runtime controls. Customers remain responsible for their applications, local proxy hosts, keys, tool integrations, and workload policy. ### The responsibilities of Prem * Prem operates the confidential-computing and attestation infrastructure * Prem maintains the documented transport, payload-encryption, and protected-processing controls * Prem maintains the documented model serving and protected-runtime controls * 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. The limitations above define the current assurance boundary and the checks that remain necessary. > [!WARNING] > > **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 Prem gateway handles time, payload size, API key, model, routing, billing, and rate-limit metadata. Payload confidentiality depends on the client encryption path and the selected processing route. > [!NOTE] > > See the [Encryption](https://docs.prem.io/encryption.md) reference for the full cryptographic specification. Continue to [Attestation](https://docs.prem.io/attestation.md) for the attestation detail: reports, tokens, and verification code. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.