Workload 0xeb2365914c7f6be3399c8d1a3a04f7d2ae87ad671089b0fdd0363b8ce1651fb5

You select the workload ID. This report does not check its current on-chain capability assignment.

Workload ID being checked: 0xeb2365914c7f6be3399c8d1a3a04f7d2ae87ad671089b0fdd0363b8ce1651fb5

Check the provenance record and confirm that its eight measurement values produce the selected workload ID.

• Eight measurements hash to the workload IDverified
  Technical details

  MRTD	0xc1ee9c16e3afc506cfe042c5b846a368528f3b37618eafb27469bc114cf914e9222c91618470e7f2b28ac360968270a5
  RTMR0	0x7ccc8383a31967901f199d4e5bf0ead438492e6ce5f586253580ef024f08af0698e66492c5008856a7bed7078ea9b1ef
  RTMR1	0x2d1f0da6067d854a185f8e8fecbc0c4eb5635247c6fa06f0b011ab72464021c9efe33020b33c6d008bf7d1912fa2c4f0
  RTMR2	0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  RTMR3	0xe5e90eeba2131a8d0e39c3839660870eb7f56c8dedd2b7e31fa30aaee7f68df92c7cc43b3ff141a14029cac46e8de4d2
  MRCONFIGID	0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
  XFAM	0xe702060000000000
  TD attributes	0x0000001000000000

  keccak256(mrTd || rtMr0 || rtMr1 || rtMr2 || rtMr3 || mrConfigId || xFAM || tdAttributes)
= 0xeb2365914c7f6be3399c8d1a3a04f7d2ae87ad671089b0fdd0363b8ce1651fb5 ✓

Use the verified prebuilt OS image, Docker images, Docker configuration, and TDX boot profile to recompute the eight TDX values. Compare each value with the expected measurements from step 2.

Verify the prebuilt OS image

This check links the published OS artifact to its recorded source repository, commit, and build instructions. The service hashes the build instructions and OS artifact, compares them with the provenance manifest, and confirms that the recorded source and artifact values match an immutable platform-profile bundle selected from the service-owned accepted-profile registry. The workload record names the selected profile’s opaque ID; the registry binds that ID to the exact archive. Each check below links the exact files and source used, so you can inspect them or repeat the comparisons.

For GCP/mkosi, the provider profile is accepted in a separate offline phase, where the service rebuilds the recorded ritual-images source commit and confirms that the rebuilt guest disk matches the published image.

• 1. Build instructions match the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the recorded OS build instructions and compares it with the expected digest in the provenance manifest. The evidence link below is the exact file used, available if you want to repeat the comparison.

  Expected SHA-256 digest from the manifest:
  sha256:d55d26598ba57a5aa92cd7415ad9d1b17add3c014d02d65eb79bd11cb79180db

  Related evidence and source:

  • OS build instructions
• 2. OS image matches the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the prebuilt OS image and compares it with the expected digest in the provenance manifest. The evidence link below is the exact image used to reproduce the TDX measurements, available if you want to repeat the comparison.

  Expected SHA-256 digest from the manifest:
  sha256:44c022d8fd894bb8a02b7892509cd2aa112778735dc1a52d40de5697a13d59e5

  Related evidence and source:

  • OS image
• 3. OS artifacts match accepted offline measurementsverified
  Technical details

  This check confirms that the repository, commit, build instructions, and published OS image in the manifest are consistent with the values that were accepted after a reproducible offline OS build. The evidence and source links below show the exact values used, available if you want to inspect or repeat that build.

  Related evidence and source:

  • OS build instructions
  • OS image
  • GCP TDX machine profile
  • ritual-net/ritual-images @ 422ff3db4158201040c63f20f2743447c29e0a73

Verify the Docker workload configuration used in the TDX measurements

This check links the Docker workload inputs to the TDX measurements that commit to them. The service checks the exact measured configuration against its manifest digest, extracts its digest-pinned container images, and confirms that the image list exactly matches the Docker images declared in the manifest. This means the GitHub attestations in step 4 cover the container images committed to the TDX measurements. The provider-specific details below explain which configuration is measured and how it contributes to the TDX values.

For GCP/mkosi, the measured configuration is the exact labeled byte stream containing the environment file followed by the Docker Compose file. Here, we are validating the connection between docker images -> full configuration, which can then be connected to the RTMR3 value. The service publishes the measured byte stream and both component files so you can inspect the exact inputs or repeat the calculation.

• Docker configuration matches the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the Docker configuration bytes from the uploaded evidence bundle and compares it with the expected digest in the provenance manifest. The service publishes the exact verified bytes linked below.

  Expected SHA-256 digest from the manifest:
  sha256:ba1cdca819d2c9b8fda674cffb7a5f747fc2c61870e81f7e1959e6ff89a88057

  Related evidence and source:

  • Docker configuration
• Environment file matches the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the environment file from the uploaded evidence bundle and compares it with the expected digest in the provenance manifest. The service publishes the exact verified file linked below.

  Expected SHA-256 digest from the manifest:
  sha256:c0e688a7082201b4205f4c677479845753defe878696c4560a15ee3efb20fdd7

  Related evidence and source:

  • Measured environment
• Docker Compose file matches the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the Docker Compose file from the uploaded evidence bundle and compares it with the expected digest in the provenance manifest. The service publishes the exact verified file linked below.

  Expected SHA-256 digest from the manifest:
  sha256:50892a7a09767dd8442f6f2e7fc9058563839f681ce9f1f0715524d767f81efd

  Related evidence and source:

  • Measured Docker Compose file
• Container images match the RTMR3 configuration measurementsverified
  Technical details

  This check connects the exact Docker configuration bytes measured into RTMR3 to the container images declared by the provenance record.

  1. The Docker configuration is a binary-safe byte stream containing a labeled copy of the environment file followed by a labeled copy of the Docker Compose file. It uses a .bin extension because it preserves the exact measured bytes rather than representing one standalone text format.

     ritual-container-env\n
     + raw environment bytes
     + ritual-container-compose\n
     + raw Compose YAML bytes

  2. Parse the Compose YAML and inspect every service under the top-level services mapping. This validation requires every service to specify a direct, digest-pinned image and rejects build directives, includes, extends, YAML indirection, and duplicate keys.
  3. Compare the parsed image list with the Docker images declared in the provenance manifest. Recall that the provenance manifest is the central index for this workload. It records the expected TDX measurements, the locator and digest of each verification artifact, and the repository and commit for relevant source code. Missing, additional, or different images cause a mismatch.

  Related evidence and source:

  • Docker configuration
  • Measured environment
  • Measured Docker Compose file

Verify the TDX boot profile

The TDX boot profile is the provider-specific recipe that combines the selected VM image with the cloud platform’s firmware, virtual-machine configuration, VMM behavior, and TDX launch settings to reproduce the boot-related measurements. This check links the boot-related TDX measurements back to the boot profile that produced them. The service verifies the supplied artifacts against the provenance manifest and requires the provider-specific profile values to match an accepted provider profile.

For GCP/mkosi, the accepted boot profile connects MRTD to the exact Google OVMF firmware and machine topology. It also supplies the calibration baseline used with the OS image’s UKI and GPT disk layout to calculate an expected RTMR1. The workload CCEL separately records the boot events observed for RTMR0, RTMR1, and RTMR2. The complete-tuple procedure below performs both calculations and requires the two RTMR1 values to match. A different cloud provider, machine type, or firmware version requires a different accepted boot profile.

Google OVMF firmware + machine topology        → MRTD inputs
workload CCEL                                   → observed RTMR0, RTMR1, RTMR2
OS image UKI + GPT layout + accepted baseline   → expected RTMR1
offline-approved VMM launch configuration       → MRCONFIGID, XFAM, TDATTRIBUTES

• GCP TDX machine profile matches the offline-approved configurationverified
  Technical details

  This check covers the machine and boot-artifact values in the offline-approved GCP profile. The verifier requires the supplied machine type, memory topology, firmware, UKI, baseline, and disk hashes to exactly match the values accepted during offline calibration.

  Expected SHA-256 digest from the manifest:
  sha256:d42b9e698fa731ae8e7a5abcc1e3bc8519863cc94088dc6b19ed7ea276b79b20

  Related evidence and source:

  • GCP TDX machine profile
• GCP TDX VMM launch configuration matches the offline-approved configurationverified
  Technical details

  This check covers MRCONFIGID, XFAM, and TDATTRIBUTES. These values are determined by the VMM’s launch configuration—essentially VM creation flags—rather than derived from guest source code. The verifier requires them to exactly match the values accepted during offline calibration before using them in the reproduced TDX tuple.

  Expected SHA-256 digest from the manifest:
  sha256:d42b9e698fa731ae8e7a5abcc1e3bc8519863cc94088dc6b19ed7ea276b79b20

  Related evidence and source:

  • GCP TDX machine profile
• MRTD matches Google-endorsed OVMF firmwareverified
  Technical details

  This check connects the MRTD value back to the closed-source OVMF firmware binary. During offline profile acceptance, the service verifies Google’s signed launch endorsement and confirms that its endorsed OVMF firmware digest matches this binary. For this workload, the service checks the binary against the manifest and accepted profile, confirms that its SHA-384 identity matches the calibration baseline, and combines it with the recorded machine topology to reconstruct MRTD.

  Expected SHA-256 digest from the manifest:
  sha256:9b874b165572566e7f5e9970c47f0b0ee1dc9f8333861c3b9c1c6f4cf81446ca

  Related evidence and source:

  • Platform firmware
• GCP RTMR1 calibration baseline matches the accepted profileverified
  Technical details

  This check verifies that the calibration baseline file matches its digest in the provenance manifest and the baseline pinned by the offline-approved GCP profile. The baseline supplies the provider-specific measurement context that the pinned tool later combines with the exact UKI and GPT disk layout to calculate the expected RTMR1. That calculation and its comparison with the workload CCEL replay happen under Reproduce TDX measurements.

  Expected SHA-256 digest from the manifest:
  sha256:9034cc6119e9da5e18764312d59d1d37383eae3c969028e11f2250b22f55f00f

  Related evidence and source:

  • Calibration baseline
• CCEL evidence matches the manifestverified
  Technical details

  CCEL stands for Confidential Computing Event Log. It is the complete ordered record of boot events measured into the TDX runtime measurement registers. Google’s OVMF firmware determines which boot events are recorded, while GCP-supplied platform inputs determine some event contents and digests.

  The provenance evidence includes two logs:

  • The calibration CCEL was captured and replayed when the GCP boot profile was approved offline.
  • The workload CCEL is supplied for this workload and replayed during workload verification.

  The accepted offline profile binds the calibration CCEL. The workload CCEL is passed to the measurement tool when it reproduces this workload’s TDX measurements. Each file must match its own manifest digest. In this record, the digests are identical, so successful verification confirms that the measurement tool receives the same CCEL bytes accepted with the offline profile.

  Expected SHA-256 digest for the workload CCEL from the manifest:
  sha256:c162297ca157977cd7868547af8d56b2f81d77dfbb5d10860399961b83f12eeb

  Expected SHA-256 digest for the calibration CCEL from the manifest:
  sha256:c162297ca157977cd7868547af8d56b2f81d77dfbb5d10860399961b83f12eeb

  Related evidence and source:

  • Workload boot event log
  • Calibration boot event log

  We provide the calibration CCEL as an additional reference showing the boot-event structure observed when the TDX profile was accepted. Because parts of Google’s firmware and GCP platform are closed source, Google-controlled inputs such as ACPI data may change without advance public notice and produce different event digests, so workload events are not required to equal the calibration events. Strong evidence that the measurements came from a genuine Google TDX launch should instead come from provider-backed platform attestation bound to the specific TDX quote. The CCEL has a narrower role here: it preserves the ordered event chain and helps connect the resulting TDX measurements back to components and inputs that can be independently inspected or reproduced.

Reproduce TDX measurements

With the OS image, Docker configuration, and TDX boot profile established above, this section runs the provider-specific measurement procedure that ties them together. We use pinned binaries that calculate the resulting TDX measurements without needing to run a TDX machine, and link to their source code.

verified OS image + Docker configuration + TDX boot profile
                              ↓
                   pinned measurement tool
                              ↓
              recomputed eight-field TDX tuple
                              ↓
          canonical output digest matches manifest

For GCP/mkosi, the pinned cvm-measure implementation and Ritual adapter calculate MRTD from the endorsed firmware and machine topology, replay RTMR0, RTMR1, and RTMR2 from the workload CCEL, independently cross-check RTMR1 against the exact UKI and GPT disk layout, and extend RTMR3 with the SHA-384 digest of the Docker configuration.

• Measurement tool build instructions match the manifestverified
  Technical details

  This check calculates the SHA-256 hash of the measurement tool’s build instructions and compares it with the expected digest in the provenance manifest. The evidence link below is the exact file identified by the manifest, available if you want to inspect how the tool is built or repeat the digest comparison.

  Expected SHA-256 digest from the manifest:
  sha256:4bd287c1907a731dbc0c198e828aa41ff51ee125c63abfe051b2e8092a280492

  Related evidence and source:

  • Measurement tool build instructions
  • cvm-measure source commit
• Measurement tool identity matches the accepted profileverified
  Technical details

  This check confirms that the measurement tool recorded in the manifest—its name, version, source repository, commit, executable digest, build instructions, and execution image—matches the tool selected by the accepted profile. The measurement worker is restricted to the approved executable when it runs the procedure.

  Related evidence and source:

  • Measurement tool build instructions
  • Measured environment
  • Measured Docker Compose file
  • Platform firmware
  • Calibration baseline
  • Calibration boot event log
  • Workload boot event log
  • GCP TDX machine profile
  • cvm-measure source commit
• Recompute the complete eight-field TDX tupleverified
  Technical details

  This check runs the provider-specific measurement procedure with the verified OS image, Docker configuration, and TDX boot-profile inputs from the preceding sections.

  1. Extract the GCP disk and embedded UKI from the verified prebuilt OS image, then confirm their hashes match the accepted profile.
  2. Calculate MRTD from the Google-endorsed OVMF firmware and the accepted machine topology.
  3. Replay the workload CCEL to reconstruct the RTMR0, RTMR1, and RTMR2 values produced by its recorded boot-event chains.
  4. Independently calculate the RTMR1 expected from the exact UKI, GPT disk layout, and offline-approved calibration baseline, then require it to equal the RTMR1 produced by the workload CCEL replay. This is the check that binds the observed boot log to the OS artifacts verified above; without it, the OS artifact checks and CCEL replay would only be separately consistent with the manifest.
  5. Start RTMR3 at 48 zero bytes. The accepted GCP boot CCEL contains no RTMR3 events, so there is no boot-time RTMR3 event chain to replay. The profile records the same zero value, which the verifier checks as a consistency guard.

     initial_RTMR3 = 48 zero bytes

  6. Hash the exact Docker configuration with SHA-384, then extend the initial RTMR3 with that digest to produce the final workload-specific RTMR3.

     configuration_digest = SHA-384(Docker configuration)
     final_RTMR3 = SHA-384(initial_RTMR3 || configuration_digest)

  7. Take MRCONFIGID, XFAM, and TDATTRIBUTES from the accepted machine profile to complete the eight-field TDX tuple. Note: these values are determined by the VMM's launch configuration—essentially VM creation flags—rather than derived from guest source code.
  8. Serialize the tuple as canonical JSON, calculate its SHA-256 digest, and compare that digest with the measurement-tool output digest recorded in the provenance manifest.

  Expected SHA-256 digest for the canonical eight-field output from the manifest:
  sha256:76e947edfab0e145e8d1bd0212cd5807c9becd2ea5962a721e3325ffde809619

  Related evidence and source:

  • OS image
  • Docker configuration
  • Measured environment
  • Measured Docker Compose file
  • Platform firmware
  • Calibration baseline
  • Calibration boot event log
  • Workload boot event log
  • GCP TDX machine profile

All eight values match?

• Reproduced TDX measurements matchverified
  Technical details

  Recomputes all eight TDX measurements from the OS image, workload configuration, and platform inputs, then compares them with the values shown in Source info.

  provider reproduced all eight declared TDX fields

  Related evidence and source:

  • OS image
  • Docker configuration
  • Measured environment
  • Measured Docker Compose file
  • Platform firmware
  • Calibration baseline
  • Calibration boot event log
  • Workload boot event log
  • GCP TDX machine profile

Does each exact container image connect to the claimed source code and build workflow?

• claw-spawner — GitHub source and build attestationverified
  Technical details

  Checks that GitHub’s signed build attestation connects this exact Docker image to the linked source commit and build workflow.

  Related evidence and source:

  • claw-spawner — Docker image metadata
  • Source commit
  • GitHub attestation run
• docker-socket-proxy — GitHub source and build attestationverified
  Technical details

  Checks that GitHub’s signed build attestation connects this exact Docker image to the linked source commit and build workflow.

  Related evidence and source:

  • docker-socket-proxy — Docker image metadata
  • Source commit
  • GitHub attestation run
• executor-go — GitHub source and build attestationverified
  Technical details

  Checks that GitHub’s signed build attestation connects this exact Docker image to the linked source commit and build workflow.

  Related evidence and source:

  • executor-go — Docker image metadata
  • Source commit
  • GitHub attestation run
• hermes-instance — GitHub source and build attestationverified
  Technical details

  Checks that GitHub’s signed build attestation connects this exact Docker image to the linked source commit and build workflow.

  Related evidence and source:

  • hermes-instance — Docker image metadata
  • Source commit
  • GitHub attestation run
• openclaw-instance — GitHub source and build attestationverified
  Technical details

  Checks that GitHub’s signed build attestation connects this exact Docker image to the linked source commit and build workflow.

  Related evidence and source:

  • openclaw-instance — Docker image metadata
  • Source commit
  • GitHub attestation run
• ritual-pii — GitHub source and build attestationverified
  Technical details

  Checks that GitHub’s signed build attestation connects this exact Docker image to the linked source commit and build workflow.

  Related evidence and source:

  • ritual-pii — Docker image metadata
  • Source commit
  • GitHub attestation run
• sovereign-agent — GitHub source and build attestationverified
  Technical details

  Checks that GitHub’s signed build attestation connects this exact Docker image to the linked source commit and build workflow.

  Related evidence and source:

  • sovereign-agent — Docker image metadata
  • Source commit
  • GitHub attestation run
• zeroclaw-instance — GitHub source and build attestationverified
  Technical details

  Checks that GitHub’s signed build attestation connects this exact Docker image to the linked source commit and build workflow.

  Related evidence and source:

  • zeroclaw-instance — Docker image metadata
  • Source commit
  • GitHub attestation run

An independent OS rebuild is an offline step for the user. Matching the recorded OS to an approved profile in step 3 does not mean this request rebuilt it.

Reviewing whether the source is safe and appropriate for its capability is a human judgment. This report does not perform that audit.