> ## 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. # Attestation > CPU and GPU attestation: how Prem API proves what code is running on what hardware, and how you can verify it yourself. **Attestation** is a method to verify that the correct code runs on genuine hardware in a secure configuration. You do not trust this; you verify it. The hardware itself signs a report that you can check independently. The report is comparable to a tamper-proof audit certificate from the chip manufacturer. You can validate the report in real time. ## Available Attestation Today Prem API includes **CPU and GPU attestation** from the first release. Both types are available, and you can verify each type independently. Your browser does the verification directly. There is no server round-trip and no intermediary that you must trust. | Type | Hardware | Status | What It Proves | | ------- | ------------------------- | --------- | ------------------------------------------------------------------------------------ | | **CPU** | AMD SEV-SNP | Available | The enclave runs measured code on genuine AMD hardware with encrypted memory | | **CPU** | Intel TDX | Available | The enclave runs measured code on genuine Intel hardware with Trust Domain isolation | | **GPU** | NVIDIA Hopper & Blackwell | Available | The GPU is in confidential mode on genuine NVIDIA hardware with encrypted memory | ## The Attestation Process This is the core flow for developers, security auditors, and compliance officers who evaluate Prem API: Your device generates a random number (a "nonce"). Your device then asks the enclave for proof. The TEE hardware, not our software, generates a signed report. The report contains a fingerprint of all code in the enclave, the security configuration of the platform, and your random challenge. The challenge proves that the report is fresh. Your device checks the manufacturer's signature to confirm that the report comes from AMD, Intel, or NVIDIA. Your device confirms that the code fingerprint matches the published value. Your device also confirms that your challenge is present, which proves that the report is fresh. If all checks pass, you have mathematical proof that the enclave runs the expected code on genuine hardware in a secure configuration. This proof is not a promise. If a check fails, you know before you send data. This process occurs independently for the CPU and for the GPU. Your browser runs both verifications. You can verify the full processing pipeline without trust in an external service. ## The Rust and WebAssembly Implementation Prem writes the full Prem API attestation stack in **Rust**, and the code compiles to **WebAssembly (WASM)**. This is important for two reasons: Rust removes full classes of security vulnerabilities at compile time: buffer overflows, use-after-free errors, and data races. The code that verifies attestation reports **cannot be exploited through memory corruption**, because Rust makes these bugs impossible. This is a property of the language, not a test result. The WASM build runs directly in your browser. There is no server, no installation, and no trust in an intermediary. The same Rust code also compiles to native binaries for server-side use. One auditable codebase supplies two deployment targets. We publish the attestation libraries as: * **Rust crates**: `nvidia-attest`, `snp-attest`, `tdx-attest`, and the unified `reticle` client * **NPM WASM package**: `@premai/reticle` for browser and Node.js use ### The Organization of the Attestation Code Prem API maintains two attestation codebases with different roles: **[reticle](https://github.com/prem-research/reticle.git)** is the main framework. It is a Rust workspace that contains all verification implementations and a unified client: | Component | Role | | -------------------- | -------------------------------------------------------------------------------- | | `nvidia-attest` | Parses and verifies NVIDIA GPU attestation tokens | | `snp-attest` | Parses and verifies AMD SEV-SNP CPU reports | | `tdx-attest` | Parses and verifies Intel TDX CPU quotes | | `libattest` | Shared primitives: signature verification, nonce handling, certificate utilities | | `attestation-server` | Runs inside the CVM to generate attestation reports on request | | `reticle` | Unified client that abstracts over all attestation types with a single API | **`nvat-rs`** is a low-level library that communicates directly with the NVIDIA GPU hardware to get raw attestation evidence. It operates as the hardware driver layer: `nvat-rs` gets the evidence from the GPU, and `nvidia-attest` verifies the evidence. ```mermaid theme={"system"} flowchart LR subgraph Your_Device["Verification (your side)"] PR["reticle (Rust/WASM)"] PR --> NA["nvidia-attest"] PR --> SA["snp-attest"] PR --> TA["tdx-attest"] end subgraph CVM["CVM"] AS["attestation-server"] NV["nvat-rs"] AS --> NV NV -->|"hardware call"| GPU["NVIDIA GPU"] AS -->|"hardware call"| CPU["CPU TEE (SNP/TDX)"] end PR -->|"request attestation"| AS ``` This separation is a security design choice. The attestation server runs inside the trusted CVM, where it communicates with the hardware. The verification libraries run on **your** device, possibly in a browser. There, the memory safety of Rust and the sandbox of WASM are critical, because the code runs in an untrusted environment. ## CPU Attestation ### AMD SEV-SNP When the enclave boots, the **AMD Secure Processor** measures (fingerprints) each component. The AMD Secure Processor is a dedicated security chip inside the CPU. The host OS cannot access this chip. ```mermaid theme={"system"} flowchart TD A["AMD Secure Processor"] -->|"measures"| B["Firmware"] B -->|"measures"| C["Kernel"] C -->|"measures"| D["Enclave Application"] D -->|"all fingerprints recorded in"| E["Attestation Report"] E -->|"signed by"| F["AMD Platform Key"] ``` **The report contains:** * **MEASUREMENT**: Fingerprint of the full initial VM image * **HOST\_DATA**: Platform configuration data * **REPORT\_DATA**: Your challenge nonce + enclave public key * **TCB Version**: Firmware and microcode versions, so that you can confirm the security patches * **Policy flags**: Debug disabled, migration disabled, single-socket enforced **The verification steps:** 1. Make sure that the report signature chains to the AMD root certificate. This confirms genuine hardware. 2. Make sure that your nonce is present. This confirms that the report is fresh and not a replay. 3. Make sure that the code fingerprint matches the published value. This confirms that the expected code runs. 4. Make sure that debug is disabled and that the firmware versions meet the minimum thresholds. This confirms a secure configuration. ### Intel TDX Intel TDX gives equivalent guarantees through **Trust Domains**. Trust Domains are hardware-isolated VMs with encrypted memory. The Intel TDX Module manages them. ```mermaid theme={"system"} flowchart TD A["Intel TDX Module"] -->|"measures"| B["TD Firmware"] B -->|"measures"| C["Kernel"] C -->|"measures"| D["Enclave Application"] D -->|"fingerprints recorded in"| E["TD Quote"] E -->|"signed via"| F["Intel Quoting Enclave"] ``` **The quote contains:** * **MRTD**: Fingerprint of the initial Trust Domain image * **RTMR registers**: Runtime fingerprints of the components that load after boot * **REPORT\_DATA**: Your challenge nonce + enclave data * **TCB SVN**: Security versions for the TDX Module and the platform firmware Verification follows the same model as SEV-SNP: validation of the signature chain, a check of the nonce, a comparison of the fingerprints, and verification of the TCB state. Both CPU attestation types use the same `reticle` unified client. So the verification interface is identical for each CPU platform that the enclave runs on. ## GPU Attestation (NVIDIA Confidential Computing) NVIDIA GPUs on the **Hopper and Blackwell architectures** produce their own attestation tokens, independent of the CPU. So you can verify the CPU enclave and the GPU separately. ### Token Format GPU attestation uses **Entity Attestation Tokens (EAT)**, a structured JWT format: ``` EAT Token ├── Overall Token (signed JWT) │ ├── Platform-level claims │ │ ├── Issuer (NVIDIA attestation service) │ │ ├── Your challenge nonce │ │ ├── Hardware model │ │ └── Driver version │ └── NVIDIA signature │ └── Per-GPU Tokens (one per GPU) ├── GPU unique ID ├── Firmware fingerprints ├── Confidential compute: enabled └── VBIOS version ``` ### The Guarantees of GPU Attestation * The GPU is a **genuine NVIDIA Hopper or Blackwell GPU**, not an emulated or modified device * **Confidential compute mode is active**: the hardware encrypts the GPU memory and isolates it from the host * **The firmware is intact**: the fingerprints match known-good values * **The report is fresh**: your challenge nonce is present ### Verification 1. Parse the JWT structure (the overall token and the per-GPU tokens). 2. Validate the signature of each JWT against the NVIDIA certificate chain. 3. Confirm that your nonce is present. 4. Make sure that confidential compute is enabled and that the firmware versions are acceptable. 5. Compare with the CPU attestation to confirm that the two reports come from the same session. ### Attestation-Locked Routing Prem API runs production-grade inference engines, such as **vLLM** and **SGLang**, inside the enclave. In a multi-GPU environment, Prem API must make sure that the GPUs you attested are the GPUs that run your inference. The **model router** does this with session-based sticky routing. The router supports **multi-GPU attestation by default**. When a backend uses multiple GPUs, for example for tensor parallelism, the backend attests each GPU. Each GPU produces its own per-GPU token inside the attestation response. Your client sends an attestation request with a nonce and the model that you want to use. The model router selects one of the available GPU backends for that model at random. The router forwards your request to that backend. The selected backend generates an attestation response. The response contains your nonce and a **per-GPU token for each GPU** in the backend. Each token includes the hardware identity, the firmware fingerprints, and the confidential compute status. The backend returns the response to the router. After a successful attestation response, the router creates a **session**. A session is a temporary binding between a unique session ID and the specific GPU backend that produced the quotes. The router returns this session ID to your client in the `X-Session-Id` header. Your client verifies the attestation response. It checks the NVIDIA signature chain, your nonce, the confidential compute status, and the firmware integrity **for each GPU** in the backend. All checks occur on the client side. After the verification passes, your client sends the inference request with the `X-Session-Id` header. The router finds the session and routes your request to the **same GPU backend** that produced the attestation quotes. The router then immediately consumes the session. ```mermaid theme={"system"} sequenceDiagram participant Client participant Router as Model Router participant GPU as GPU Backend (1+ GPUs) Client->>Router: GET /attestation/gpu?model=X&nonce=abc Router->>Router: Select random GPU backend Router->>GPU: Forward attestation request GPU-->>Router: Attestation quotes (per-GPU tokens) Router->>Router: Create session (5 min TTL) Router-->>Client: Quotes + X-Session-Id header Client->>Client: Verify all GPU quotes in browser Client->>Router: POST /v1/chat/completions (X-Session-Id) Router->>Router: Lookup session, route to same backend Router->>GPU: Forward inference request GPU-->>Router: Inference response Router-->>Client: Response Router->>Router: Delete session ``` This design binds attestation to the actual inference request. Attestation is not only a one-time check. You have cryptographic proof that each GPU you verified is a GPU that processed your data. The session is single-use and short-lived. This prevents replay and redirection. ## Combined Attestation: The Full Chain In production, your data passes through the CPU and the GPU. Prem API provides attestation for **both**, so you can verify the full processing pipeline: ```mermaid theme={"system"} flowchart LR subgraph CPU["CPU TEE (AMD SEV-SNP or Intel TDX)"] A["Receive encrypted payload"] B["Decrypt"] C["Prepare inference request"] end subgraph GPU["GPU TEE (NVIDIA Confidential Computing)"] D["Receive over secure channel"] E["Run AI inference"] F["Return over secure channel"] end subgraph CPU2["CPU TEE"] G["Encrypt response"] H["Send back to you"] end A --> B --> C C -->|"encrypted CPU-GPU channel"| D D --> E --> F F -->|"encrypted CPU-GPU channel"| G G --> H ``` The CPU and the GPU produce independent reports. Your browser verifies both reports on the client side. This confirms that the hardware protects each step of the pipeline. ## Verification for Developers ### Use the SDK (simplest method) The SDK does attestation **automatically**. When you create a client, attestation is on by default (`attest: true`). Before each request, the SDK verifies the CPU and GPU attestation with the `@premai/reticle` WASM library. The SDK then gets a session ID from the router and pins to the attested backend. These steps are transparent to you. ```typescript theme={"system"} import createRvencClient from "@premai/api-sdk"; const client = await createRvencClient({ apiKey: process.env.PREM_API_KEY, clientKEK: process.env.CLIENT_KEK, // attest: true is the default. The SDK automatically // verifies CPU and GPU attestation before each request }); // Attestation happens transparently. The SDK verifies // the enclave and pins to the attested backend via X-Session-Id const response = await client.chat.completions.create({ model: "deepseek-v4-pro", messages: [{ role: "user", content: "Hello" }], }); ``` You can also query the attestation types that a backend supports before you request a full quote. Use the `modules` attestation type (a nonce is not necessary): ``` GET /attestation/modules?model= ``` ### Use the Rust/WASM Library (independent verification) Use the `reticle` crate (or its WASM build) directly if your team wants to verify attestation independently: ```rust theme={"system"} use reticle::ClientBuilder; use snp_attest::nonce::SevNonce; use nvidia_attest::nonce::NvidiaNonce; // Build a client pointing at the enclave let client = ClientBuilder::new("https://your-enclave-url") .build()?; // Verify CPU attestation (AMD SEV-SNP) let sev_nonce = SevNonce::new(); let cpu_result = client.request_sev(&sev_nonce).await?; // Verify GPU attestation (NVIDIA) let nvidia_nonce = NvidiaNonce::new(); let gpu_result = client.request_nvidia(&nvidia_nonce).await?; ``` Or use JavaScript/TypeScript via WASM: ```bash theme={"system"} npm install @premai/reticle ``` ```typescript theme={"system"} import { ClientBuilder } from "@premai/reticle"; // Build a client pointing at the enclave const client = await new ClientBuilder("https://your-enclave-url").build(); // Attest everything (CPU + GPU) in one call const result = await client.attest(); const headers = result.headers(); console.log("CPU headers:", headers.cpu()); console.log("GPU headers:", headers.gpu()); // Or attest individual components: // await client.attest_sev(); // await client.attest_nvidia(); ``` ### The Necessary Checks Make sure that the measurement hash matches the published Prem API enclave hash. We publish these values with each release. Make sure that the signature chain roots to AMD, Intel, or NVIDIA, not to a self-signed or unknown authority. Make sure that debug mode is disabled, that the firmware versions are current, and that GPU confidential compute is active. Make sure that your nonce is present in the report. This proves that the report is a response to your specific request. ## Certificate Chains CPU attestation and GPU attestation each use certificate chains rooted in the hardware manufacturer: **AMD SEV-SNP:** ``` AMD Root CA → AMD SEV Signing Key → Chip Endorsement Key → Report Signature ``` **Intel TDX:** ``` Intel Root CA → Intel Signing Key → Quoting Enclave → Quote Signature ``` **NVIDIA:** ``` NVIDIA Root CA → NVIDIA Attestation Key → Platform Token → Per-GPU Tokens ``` The Prem API attestation libraries fetch and cache the certificates automatically. The libraries also check revocation and validate the full chain. ## Next Steps We work to **open-source the reproducible enclave images**. Then anyone can rebuild the images from source. Anyone can then independently verify that the code fingerprints in the attestation reports match the published binaries. This closes the last trust gap. You will be able to confirm that the hardware is genuine and that the configuration is secure. You will also be able to confirm that the exact code inside the enclave corresponds to auditable, publicly available source code. Beyond reproducible builds, we complete the **full DevOps cycle** with full CI/CD integration and **provenance artifacts** for each build. Automated pipelines build, test, and sign each enclave image. The pipelines produce verifiable provenance. So you can trace each deployed artifact back to its source commit, its build environment, and its signing chain. All **non-CVM infrastructure runs fully on our local infrastructure**. No third-party cloud services sit in the path between your request and the enclave. We self-host the build systems, the CI/CD pipelines, the image registries, and the orchestration. This reduces the attack surface and removes external dependencies from the trust model. Attestation is available today for AMD SEV-SNP (CPU), Intel TDX (CPU), and NVIDIA Hopper/Blackwell (GPU). All verification runs through a single Rust/WASM codebase. The codebase is memory-safe and auditable, and it runs in each environment from servers to browsers. See [Platform Status](/platform-status) for the full roadmap.