Skip to main content
What is attestation? It’s a way to verify — not trust — that the right code is running on genuine hardware in a secure configuration. The hardware itself signs a report that you can check independently. Think of it as a tamper-proof audit certificate, issued by the chip manufacturer, that you can validate in real time.

​
What Ships Today

PCCI ships with CPU and GPU attestation from day one. Both are available, independently verifiable, and both are verified directly in your browser — no server round-trip, no intermediary you need to trust.
TypeHardwareStatusWhat It Proves
CPUAMD SEV-SNPAvailableThe enclave is running measured code on genuine AMD hardware with encrypted memory
CPUIntel TDXAvailableThe enclave is running measured code on genuine Intel hardware with Trust Domain isolation
GPUNVIDIA Hopper & BlackwellAvailableThe GPU is in confidential mode on genuine NVIDIA hardware with encrypted memory

​
How Attestation Works — The Big Picture

Whether you’re a developer, a security auditor, or a compliance officer evaluating PCCI, here’s the core flow:
1

You send a challenge

Your device generates a random number (a “nonce”) and asks the enclave to prove itself.
2

The hardware responds

The TEE hardware — not our software — generates a signed report. This report contains a fingerprint of all code running in the enclave, the security configuration of the platform, and your random challenge (to prove the report is fresh).
3

You verify the report

Your device checks the hardware manufacturer’s signature (is this really from AMD/Intel/NVIDIA?), confirms the code fingerprint matches the published value (is this the code we expect?), and validates your challenge is present (is this report fresh?).
4

You decide

If everything checks out, you have mathematical proof — not a promise — that the enclave is running the expected code on genuine hardware in a secure configuration. If anything fails, you know before sending any data.
This process happens for both the CPU and the GPU independently, and both verifications run in your browser. You can verify the entire processing pipeline without trusting any external service.

​
Built in Rust, Runs as WebAssembly

The entire PCCI attestation stack is written in Rust and compiles to WebAssembly (WASM). This matters for two reasons:

Memory Safety

Rust eliminates entire classes of security vulnerabilities — buffer overflows, use-after-free, data races — at compile time. The code that verifies attestation reports cannot be exploited through memory corruption because those bugs are impossible to introduce in Rust. This is a property of the language, not a testing claim.

Verify Anywhere

The WASM build runs directly in your browser — no server, no install, no trust in any intermediary. The same Rust code also compiles to native binaries for server-side use. One auditable codebase, two deployment targets.
The attestation libraries are published as:
  • Rust crates — nvidia-attest, snp-attest, tdx-attest, and the unified prem-rs client
  • NPM WASM package — @premAI-io/prem-rs for browser and Node.js use

​
How the Attestation Code Is Organized

PCCI maintains two attestation codebases with different roles: pcci-attestation-stack is the main framework — a Rust workspace containing all verification implementations and a unified client:
ComponentRole
nvidia-attestParses and verifies NVIDIA GPU attestation tokens
snp-attestParses and verifies AMD SEV-SNP CPU reports
tdx-attestParses and verifies Intel TDX CPU quotes
libattestShared primitives — signature verification, nonce handling, certificate utilities
attestation-serverRuns inside the CVM to generate attestation reports on request
prem-rsUnified client that abstracts over all attestation types with a single API
nvat-rs is a low-level library that talks directly to NVIDIA GPU hardware to retrieve raw attestation evidence. Think of it as the hardware driver layer: nvat-rs retrieves the evidence from the GPU, and nvidia-attest verifies it. This separation is a security design choice. The attestation server runs inside the trusted CVM where it talks to hardware. The verification libraries run on your device — potentially in a browser — where Rust’s memory safety and WASM’s sandboxing are critical because you’re running in an untrusted environment.

​
CPU Attestation

​
AMD SEV-SNP

When the enclave boots, every component is measured (fingerprinted) by the AMD Secure Processor — a dedicated security chip inside the CPU that the host OS cannot access. What the report contains:
  • MEASUREMENT — Fingerprint of the entire initial VM image
  • HOST_DATA — Platform configuration data
  • REPORT_DATA — Your challenge nonce + enclave public key
  • TCB Version — Firmware and microcode versions (so you can confirm security patches)
  • Policy flags — Debug disabled, migration disabled, single-socket enforced
What you verify:
  1. The report is signed by a key chain rooted in AMD’s root certificate — confirming genuine hardware
  2. Your nonce is present — confirming freshness (not a replay)
  3. The code fingerprint matches the published value — confirming the expected code is running
  4. Debug is disabled and firmware versions meet minimum thresholds — confirming a secure configuration

​
Intel TDX

Intel TDX provides equivalent guarantees through Trust Domains — hardware-isolated VMs with encrypted memory, managed by Intel’s TDX Module. What the quote contains:
  • MRTD — Fingerprint of the initial Trust Domain image
  • RTMR registers — Runtime fingerprints of components loaded after boot
  • REPORT_DATA — Your challenge nonce + enclave data
  • TCB SVN — Security versions for TDX Module and platform firmware
Verification follows the same model as SEV-SNP — signature chain validation, nonce checking, fingerprint comparison, and TCB state verification. Both CPU attestation types use the same prem-rs unified client, so the verification interface is identical regardless of which CPU platform the enclave runs on.

​
GPU Attestation (NVIDIA Confidential Computing)

NVIDIA GPUs on Hopper and Blackwell architectures produce their own attestation tokens — independent of the CPU. This means you can verify both 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

​
What GPU Attestation Proves

  • The GPU is a genuine NVIDIA Hopper or Blackwell GPU — not emulated or modified
  • Confidential compute mode is active — GPU memory is encrypted and isolated from the host
  • Firmware is intact — Fingerprints match known-good values
  • The report is fresh — Your challenge nonce is present

​
Verification

  1. Parse the JWT structure (overall token + per-GPU tokens)
  2. Validate each JWT’s signature against NVIDIA’s certificate chain
  3. Confirm your nonce is present
  4. Verify confidential compute is enabled and firmware versions are acceptable
  5. Cross-reference with the CPU attestation to confirm they’re from the same session

​
Attestation-Locked Routing

PCCI runs production-grade inference engines such as vLLM and SGLang inside the enclave. In a multi-GPU environment, PCCI needs to guarantee that the GPUs you attested are the same GPUs that run your inference. The model router handles this through session-based sticky routing, and supports multi-GPU attestation by default — when a backend uses multiple GPUs (e.g. for tensor parallelism), every GPU in the backend is attested and each produces its own per-GPU token inside the attestation response.
1

You request attestation

Your client sends an attestation request with a nonce and the model you want to use. The model router randomly selects one of the available GPU backends for that model and forwards your request to it.
2

The GPU backend responds with attestation quotes

The selected backend generates an attestation response containing your nonce and a per-GPU token for every GPU in the backend — hardware identity, firmware fingerprints, and confidential compute status for each. The response is returned to the router.
3

The router locks the upstream

On a successful attestation response, the router creates a session — a temporary binding between a unique session ID and the specific GPU backend that produced the quotes. This session ID is returned to your client in the X-Session-Id header. The session expires after 5 minutes.
4

You verify the quotes in your browser

Your client verifies the attestation response — checking NVIDIA’s signature chain, your nonce, confidential compute status, and firmware integrity for every GPU in the backend. This happens entirely client-side.
5

You send the inference request with the session ID

Once verification passes, your client sends the inference request with the X-Session-Id header. The router looks up the session, routes your request to the exact same GPU backend that produced the attestation quotes, and immediately consumes the session.
This design means attestation is not just a one-time check — it is bound to the actual inference request. You have cryptographic proof that every GPU you verified is a GPU that processed your data. The session is single-use and short-lived, preventing replay or redirection.

​
Combined Attestation — The Full Chain

In production, your data passes through both CPU and GPU. PCCI provides attestation for both, so you can verify the entire processing pipeline: Both produce independent reports. Your browser verifies both — CPU and GPU attestation are checked client-side, confirming every step of the pipeline is hardware-protected.

​
How to Verify — For Developers

​
Using the SDK (simplest)

The SDK handles attestation automatically. When you create a client, attestation is enabled by default (attest: true). Before each request, the SDK verifies CPU and GPU attestation via the @premAI-io/prem-rs WASM library, obtains a session ID from the router, and pins to the attested backend — all transparently. 
import createRvencClient from "@premai/pcci-sdk-ts";

const client = await createRvencClient({
  apiKey: "your-api-key",
  clientKEK: "your-master-key",
  // 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: "openai/gpt-oss-120b",
  messages: [{ role: "user", content: "Hello" }],
});
You can also query what attestation types a backend supports before requesting a full quote by using the modules attestation type (no nonce required): 
GET /attestation/modules?model=<model>

​
Using the Rust/WASM Library (independent verification)

For teams that want to verify attestation independently, use the prem-rs crate (or its WASM build) directly: 
use prem_rs::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 in JavaScript/TypeScript via WASM: 
npm install @premAI-io/prem-rs

​
What to Check

Code Fingerprint

Does the measurement hash match the published PCCI enclave hash? We publish these values with every release.

Hardware Authenticity

Does the signature chain root to AMD, Intel, or NVIDIA — not a self-signed or unknown authority?

Security Configuration

Is debug mode disabled? Are firmware versions current? Is GPU confidential compute active?

Freshness

Is your nonce present in the report? Was it generated in response to your specific request?

​
Certificate Chains

Both CPU and GPU attestation rely on 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 PCCI attestation libraries handle certificate fetching, caching, revocation checking, and full chain validation automatically.

​
Next Steps

We are working on open-sourcing the reproducible enclave images so that anyone can rebuild them from source and independently verify that the code fingerprints in attestation reports match the published binaries. This closes the last trust gap — you will be able to confirm not just that the hardware is genuine and the configuration is secure, but that the exact code running inside the enclave corresponds to auditable, publicly available source code. Beyond reproducible builds, we fulfill the complete DevOps cycle with full CI/CD integration and provenance artifacts for every build. Every enclave image is built, tested, and signed through automated pipelines that produce verifiable provenance — so you can trace any deployed artifact back to its source commit, build environment, and signing chain. All non-CVM infrastructure runs entirely on our local infrastructure — no third-party cloud services sit in the path between your request and the enclave. Build systems, CI/CD pipelines, image registries, and orchestration are self-hosted, reducing the attack surface and eliminating 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 — memory-safe, auditable, and executable in any environment from servers to browsers. See Platform Status for the full roadmap.