The manifest

The manifest is central to Privatemode's security architecture. It's a self-contained JSON file that defines the Privatemode service's entire server-side deployment: which workloads may run, on which hardware, and in which configuration. Every trust decision comes down to comparing the deployment the Coordinator enforces against the manifest the Privatemode proxy expects. The proxy proceeds only when the two match. When they don't, the reaction depends on the proxy's configured mode. With a pinned manifest, the proxy refuses the deployment. In the default mode, it adopts the manifest currently published by Edgeless Systems as its new expectation, verifies the deployment against it, and records it to its local audit log.

Because it's the trust anchor, the manifest is also what makes Privatemode independently verifiable: it's derived from reproducibly built components, so anyone can regenerate it from the public source code and confirm exactly what the deployment may run.

What the manifest includes

It has two main parts:

• Policies: a map from each runtime-policy hash to the workload identity it admits. A workload is admitted only if its attestation report carries a policy hash listed here. There's one entry per attested pod, detailed under Attestation scope.
• ReferenceValues: the hardware evidence the Coordinator must enforce, per CPU type: the expected launch measurement, minimum firmware and TCB versions, required platform configuration, and an allow-list of the physical machines Privatemode runs on.

Runtime policies

A runtime policy lets Privatemode use the untrusted Kubernetes API for orchestration without weakening the confidential environment. For each pod, the policy pins the allowed container images by digest, along with each container's command, arguments, environment variables, and mounts. It also restricts which API calls the untrusted host may make into the confidential guest. Its hash is bound into the pod's attestation report at launch and matched against the manifest. So the report proves not just which OS booted, but exactly which workload runs.

Policies are written in the policy language Rego. For their exact structure and how they're generated, see the Contrast documentation on policies.

Attestation scope

The manifest holds one entry per attested pod:

An AI worker bundles several containers, all pinned by the same policy:

The secret service and each AI worker also run the initializer, a Contrast-injected container, pinned by the same policy. It performs the attested-TLS handshake to obtain the pod's mesh certificate from the Coordinator.

Because each image is pinned by digest, a modified container fails attestation.

Model weight integrity

To serve a model, an AI worker must load its weights. Because the weights are large, they aren't baked into the container image. Instead, they're served from a pre-built disk image that's attached to the worker as a block device.

The disk-mounter runs as an init container and mounts that block device read-only under dm-verity, which verifies every block against a cryptographic root hash on each read.

The integrity of the weights is anchored in attestation through the following chain:

1. The expected dm-verity root hash is passed to the disk-mounter as a container argument.
2. The disk-mounter's container image and its arguments, including that root hash, are pinned by the worker's runtime policy.
3. The policy's hash is bound into the worker's attestation report and must match an entry in this manifest.

So the root hash is covered by the same attestation the Privatemode proxy already verifies: a worker can only pass attestation if it mounts the weights with the exact, manifest-approved root hash. Any tampering with the weights changes the data and fails dm-verity verification against the pinned hash.

You can reproduce the expected root hash yourself. See the model verification guide.

How the proxy uses the manifest

The Privatemode proxy obtains its expected manifest, by default from Edgeless Systems or, for stronger guarantees, self-reproduced from source and pinned (see Change visibility). During the attestation flow, it checks that the manifest the Coordinator enforces matches this expected one. The Coordinator, in turn, validates every worker's attestation evidence against the manifest before admitting it to the service mesh.

Change visibility

Changing anything about the deployment (code, configuration, models, or hardware) requires a new manifest, and a new manifest means a new Mesh CA. Any such change therefore invalidates the proxy's pinned Mesh CA and forces a fresh attestation and manifest comparison at the next key exchange. The proxy supports two modes:

• Pinned manifest (strongest): the proxy refuses to operate on any mismatch, so an unaccepted change stops the deployment outright.
• Default mode: the proxy trusts the currently published manifest but records every manifest it accepts to an append-only local log, so operator changes remain auditable.

In neither mode can the operator silently alter the running system.

Manifest format

The following is an abbreviated excerpt of a Privatemode manifest:

{
  "Policies": {
    "180d10463bdec…": { "SANs": ["coordinator", "*"],
                        "WorkloadSecretID": "apps/v1/StatefulSet/continuum-…/coordinator",
                        "Role": "coordinator" },
    "0066c2c29d62c…": { "SANs": ["root", "secret-service", "*", "…"],
                        "WorkloadSecretID": "apps/v1/StatefulSet/continuum-…/secret-service" },
    "e789e2c545ae6…": { "SANs": ["continuum-etcd-client", "workload-gpt-oss-120b", "*"],
                        "WorkloadSecretID": "apps/v1/Deployment/continuum-…/workload-gpt-oss-120b" }
    // …
  },
  "ReferenceValues": {
    "snp": [{
      "Platform": "Metal-QEMU-SNP-GPU",
      "ProductName": "Genoa",
      "TrustedMeasurement": "fad411393754…",
      "APEIP": "0080b004",
      "MinimumTCB": { "BootloaderVersion": 12, "TEEVersion": 0,
                      "SNPVersion": 28, "MicrocodeVersion": 88 },
      "GuestPolicy": { "SMT": true, "MigrateMA": false, "Debug": false,
                       "CXLAllowed": false, "PageSwapDisable": true },
      "PlatformInfo": { "SMTEnabled": false, "ECCEnabled": true,
                        "AliasCheckComplete": true },
      "MinimumMitigationVector": 15,
      "AllowedChipIDs": [ … ]
    }],
    "tdx": [{
      "Platform": "Metal-QEMU-TDX-GPU",
      "MinTCBEvaluationDataNumber": 21,
      "MrTd": "a7568bf0b363…",
      "MrSeam": "489e585f1c54…",
      "Rtmrs": [ "3a57ae743d61…", "f46d46317cfe…", "3b8ecf758fe3…", "000000000000…" ],
      "Xfam": "e702060000000000",
      "AllowedPIIDs": [ … ],
      "MemoryIntegrity": false, "SMTDisabled": false, "StaticPlatform": false
    }]
  },
  "SeedshareOwnerPubKeys": [ "3082020a0282…" ]
}

Within each policy entry, SANs are the identities written into the workload's mesh certificate (how it's addressed and authenticated in the service mesh), and WorkloadSecretID is its stable identity, used by the Coordinator to derive a per-workload secret. Note that Privatemode is stateless and doesn't use the workload secrets.

Allowed machines

As a measure against physical attacks, the manifest pins the exact physical machines Privatemode runs on.

Every attestation report carries a hardware identifier of the machine that produced it: the CPU's chip ID on SEV-SNP (CHIP_ID) and the platform instance ID on TDX. The manifest lists the identifiers of the machines vetted at provisioning time (AllowedChipIDs for SEV-SNP, AllowedPIIDs for TDX). Evidence from any machine outside that list is rejected, even if the report is otherwise valid and correctly signed.

This is what limits the impact of physical attacks such as TEE.fail: an attacker who compromises some other SEV-SNP or TDX machine can't use it to impersonate the Privatemode deployment, because the proxy only accepts evidence from the vetted machines.

You can find the machine IDs currently pinned in the production manifest.

Transparency and reproducibility

The code of all trusted components is public and can be built reproducibly with Nix. Published scripts recompute every container image digest and regenerate the manifest from the public deployment description. Thus, any user can derive the reference values independently, removing Edgeless Systems from the trust chain even as the publisher of reference values. For the step-by-step procedures, see the source verification guide (reproduce the images and regenerate the manifest) and the model verification guide (reproduce the model-weight root hashes).