Confidential AI API: Secure LLM Inference at Scale

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:

Send a challenge

Your device generates a random number (a “nonce”). Your device then asks the enclave for proof.

The hardware responds

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.

Verify the report

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.

Make your decision

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:

Memory Safety

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.

Verify Anywhere

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

Make sure that the report signature chains to the AMD root certificate. This confirms genuine hardware.
Make sure that your nonce is present. This confirms that the report is fresh and not a replay.
Make sure that the code fingerprint matches the published value. This confirms that the expected code runs.
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. 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

Parse the JWT structure (the overall token and the per-GPU tokens).
Validate the signature of each JWT against the NVIDIA certificate chain.
Confirm that your nonce is present.
Make sure that confidential compute is enabled and that the firmware versions are acceptable.
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.

Request attestation

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 GPU backend responds with attestation quotes

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.

The router locks the upstream

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.

Verify the quotes in your browser

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.

Send the inference request with the session ID

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.

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

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=<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:

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:

npm install @premai/reticle

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

Code Fingerprint

Make sure that the measurement hash matches the published Prem API enclave hash. We publish these values with each release.

Hardware Authenticity

Make sure that the signature chain roots to AMD, Intel, or NVIDIA, not to a self-signed or unknown authority.

Security Configuration

Make sure that debug mode is disabled, that the firmware versions are current, and that GPU confidential compute is active.

Freshness

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 for the full roadmap.

Get Started

Core Concepts

Handling Errors

Guides

API Reference

Billing

Support

Attestation

Available Attestation Today

The Attestation Process

The Rust and WebAssembly Implementation

Memory Safety

Verify Anywhere

The Organization of the Attestation Code

CPU Attestation

AMD SEV-SNP

Intel TDX

GPU Attestation (NVIDIA Confidential Computing)

Token Format

The Guarantees of GPU Attestation

Verification

Attestation-Locked Routing

Combined Attestation: The Full Chain

Verification for Developers

Use the SDK (simplest method)

Use the Rust/WASM Library (independent verification)

The Necessary Checks

Code Fingerprint

Hardware Authenticity

Security Configuration

Freshness

Certificate Chains

Next Steps

​Available Attestation Today

​The Attestation Process

​The Rust and WebAssembly Implementation

Memory Safety

Verify Anywhere

​The Organization of the Attestation Code

​CPU Attestation

​AMD SEV-SNP

​Intel TDX

​GPU Attestation (NVIDIA Confidential Computing)

​Token Format

​The Guarantees of GPU Attestation

​Verification

​Attestation-Locked Routing

​Combined Attestation: The Full Chain

​Verification for Developers

​Use the SDK (simplest method)

​Use the Rust/WASM Library (independent verification)

​The Necessary Checks

Code Fingerprint

Hardware Authenticity

Security Configuration

Freshness

​Certificate Chains

​Next Steps

Available Attestation Today

The Attestation Process

The Rust and WebAssembly Implementation

The Organization of the Attestation Code

CPU Attestation

AMD SEV-SNP

Intel TDX

GPU Attestation (NVIDIA Confidential Computing)

Token Format

The Guarantees of GPU Attestation

Verification

Attestation-Locked Routing

Combined Attestation: The Full Chain

Verification for Developers

Use the SDK (simplest method)

Use the Rust/WASM Library (independent verification)

The Necessary Checks

Certificate Chains

Next Steps