INDEPENDENT VERIFICATION

Inspect the receipt.
Verify the evidence.

Check the hardware, application and signature behind a TokHive execution. Add the original request or response to check its contents, too.

Your evidence

01 — INPUT

Receipt file Request ID

Choose an execution receipt Canonical CBOR · up to 2 MiB No file selected Trusted application identity Required for trust

Use the identity from a release you independently trust. The receipt’s own identity is not a trust anchor.

Response body OptionalExact upstream bytes · up to 64 MiBNo file selected Hardware evidence If neededFor hash-only receipts · up to 4 MiBNo file selected

Request integrity & additional expectations

To bind the input model and request content, provide both the task specification and the original request body.

Task specificationCanonical CBOR · up to 2 MiBNo file selected Request bodyExact upstream bytes · up to 16 MiBNo file selected

Expected upstream host Expected policy hash Expected execution ID

This is the receipt’s job ID, not a buyer-facing request ID.

Maximum receipt age, in seconds

0 disables the age limit. Hardware certificates must still be valid now.

File mode is offline after loading. Request-ID mode downloads your evidence using your buyer API key. Local files are never uploaded.

Verification report

02 — RESULT

Starting the shared Go / WebAssembly engine…

Evidence before confidence.

Your checks will appear here. A valid signature alone does not establish trusted hardware or the application that ran.

Receipt signature
AMD + AWS attestation
Trusted application
Request / response integrity

ONE CORE, TWO INTERFACES

The same checks in your terminal.

tokhive-verify verify \
  --expected-app snp-app:<trusted-hash> \
  --response response.raw receipt.cbor

Add --job-spec and --request to check the input, or --json for a machine-readable report.

KNOW THE SCOPE

Integrity, with clear limits.

The receipt commits to the task specification and response bytes. Model and usage fields inside those bytes are indirectly bound when the supplied content matches.

Transformed API responses may differ from the upstream bytes the TEE signed. Historical evidence with expired certificates is refused. Request-ID lookup uses the public buyer evidence API; only your own requests are accessible.