Overview

Attestation is a cornerstone of Privatemode's security architecture. Before any data is processed or any key is exchanged, it lets the client-side Privatemode proxy independently verify that only code matching the published reference values runs in the intended confidential environment. Together with the isolation and runtime encryption features of our confidential computing architecture, this is what underpins the confidentiality and integrity of your data.

How attestation works

Every trust decision in Privatemode follows the same pattern:

1. Collect hardware-signed evidence about a component's code and configuration.
2. Verify that evidence against the expected reference values for Privatemode's server-side deployment.
3. Release trust (certificates, encryption keys, GPU access) only on an exact match.

The evidence is a signed attestation report produced by the CPU (and, for AI workers, an additional report by the GPU). The report is signed with a key derived from a secret fused into the hardware, whose signature chains to the CPU or GPU vendor's public key infrastructure (PKI). Thus, neither the infrastructure provider nor Edgeless Systems as the service provider can forge it.

An attestation report proves two things about a confidential VM (CVM):

• What initially booted within the CVM. The hardware computes a launch measurement, a cryptographic digest over the firmware, kernel, initramfs, and kernel command line (including the dm-verity root hash of the read-only root filesystem). A single reference measurement therefore covers the entire boot chain, firmware, and guest OS of every CVM in the deployment.
• Which containers run in it. The launch measurement alone doesn't pin the workload, so Contrast binds a runtime policy into the report, pinning the container images by digest, their arguments, mounts, and the permitted host-to-guest API calls. The policy's hash is written into the report at launch and can't change afterward. See Runtime policies.

Throughout these pages, a component presents or produces attestation evidence about itself, a verifier verifies that evidence, and a component is called attested once a verifier has checked its evidence against the expected reference values.

For the underlying mechanism, see the Contrast attestation docs. The Attestation evidence page covers the exact report contents and formats.

Attestation flow in Privatemode

Privatemode automates all attestation steps. On the client-side, it embeds the verification logic in the Privatemode proxy (referred to below as "the proxy"). Attestation is governed by a manifest, a JSON file that defines the evidence the Coordinator must enforce. The Coordinator is the server-side attestation authority: it verifies each component's evidence against the manifest and issues the certificates that identify verified components. As part of attestation, the proxy verifies that the manifest the Coordinator enforces matches the one it expects.

The steps to verify the Privatemode API:

1. Proxy verifies the Coordinator. The proxy fetches the expected manifest (by default from a file service managed by Edgeless Systems) and verifies the Coordinator's evidence against the AMD/Intel vendor roots. It confirms the enforced manifest matches the expected one, then pins the Coordinator's Mesh CA. A certificate chaining to this Mesh CA now proves "attested component of this exact deployment." (See Validation details.)
2. Workers and GPUs are verified. The secret service (Privatemode's server-side key-management service, which holds the prompt encryption keys) and each AI worker present their attestation evidence to the Coordinator, which verifies it and, on success, admits them to the service mesh. Inside each worker, the attestation-agent additionally verifies the GPU and activates it via NVML. A GPU that isn't activated stays inaccessible, so only attested GPUs are usable.

This completes attestation. The following steps build on it to establish the encrypted request path:

1. Secret provisioning. The proxy performs a key exchange with the secret service to establish the prompt encryption key.
2. Key distribution. Inside the worker, the inference-proxy reads the prompt encryption key from the secret service over mutual TLS, authenticated by its mesh certificate. Because keys are released only to attested workers, only a verified worker can decrypt the data.
3. Secure processing. The worker decrypts and processes the request entirely inside the attested CVM, isolated from the infrastructure.

Attestation runs when trust is first established, not on every request: workers attest to the Coordinator at startup and on restart, and the proxy verifies the Coordinator's attestation when it starts. From then on, communication runs on the issued mesh certificates. The periodic key refresh reuses the pinned Mesh CA rather than re-running attestation. Any change to the deployment invalidates the pinned Mesh CA and forces the proxy to re-attest. See Change visibility.

Chain of trust

The result is a chain of trust running from the user to the GenAI backend, each link enforced by the previous one:

• The CPU signs each CVM's launch measurement and runtime-policy hash, and each GPU signs its own evidence. These signatures chain to the AMD, Intel, and NVIDIA hardware roots of trust.
• The proxy verifies the Coordinator
• The Coordinator verifies that evidence against the manifest and issues mesh certificates only to workloads that pass.
• When the proxy exchanges keys with the secret service, the secret service authenticates itself with one of these certificates, so the encryption keys are established only with a genuine, attested secret service. As a result, your data exists in plaintext only on your machine and inside attested confidential environments.

flowchart LR
  A[User]-- "verifies" -->B[Privatemode proxy]
  A[User]-. "can reproduce and pin" .->C([Manifest])
  D[Edgeless Systems]-- "builds and publishes" -->B[Privatemode proxy]
  D[Edgeless Systems]-- "publishes" -->C([Manifest])
  C([Manifest])-. "expected reference values" .->B[Privatemode proxy]
  B[Privatemode proxy]-- "verifies evidence" -->E[Coordinator]
  subgraph INFRA["Untrusted infrastructure"]
    E[Coordinator]
    G[Secret service]
    F[AI worker]
    H[GPU]
  end
  C([Manifest])-. "enforced by" .->E[Coordinator]
  E[Coordinator]-- "verifies evidence" -->G[Secret service]
  E[Coordinator]-- "verifies evidence" -->F[AI worker]
  F[AI worker]-- "verifies GPU evidence" -->H[GPU]
  classDef cce fill:#59eaa1,color:#0a271c,stroke:none
  class E,G,F,H cce

The proxy runs on the user's machine. Each dark green component runs within a confidential computing environment, shielded from the untrusted infrastructure it's hosted on. The GPU is part of the AI worker's environment.

Every link is independently verifiable: the code is public, the builds are reproducible, and the reference values in the manifest can be derived by anyone. See Transparency and reproducibility.