Every Sealed run ends in a receipt. Some lines come from AMD's hardware. Others are statements by our code, signed inside the sealed machine. We mark which is which, because they deserve different levels of trust.
Attested by AMD hardware
These lines sit inside the AMD report. The chip signs the report with a key that chains to AMD's root certificate. If anyone changes a line after signing, including us, the signature check fails.
| Field | What it tells you | How to check |
| Launch measurement | What it tells youExactly which code the sealed machine started with: firmware, kernel, start-up files and settings | How to checkCompare it with the release's entry in our public log, or recompute it (Verify, section 4) |
| Debug | What it tells youThe host could not use AMD's debug feature to read or change the machine's memory | How to checkRead the policy field in the AMD report |
| Platform patch levels | What it tells youThe AMD firmware and microcode versions on the machine | How to checkCompare with our minimum patch levels (Verify, section 5) |
| Platform flags | What it tells youThe memory check AMD added after the 2024 BadRAM research has run on this machine[4] | How to checkRead the platform info field |
| Binding | What it tells youTies this receipt to this AMD report. It is a hash of the receipt's signing key and a random value your browser made for this run | How to checkRecompute the hash (Verify, step 4) |
| AMD signature | What it tells youAMD's chip signed the report. Its key chains to AMD's root | How to checksnpguest or go-sev-guest (Verify, step 1) |
Stated by our code
These lines are signed by a key our code creates inside the sealed machine for each run. The AMD report names that key and shows which code was running. AMD's hardware does not check what these lines say.
| Field | What it tells you | How to check |
| Run ID | What it tells youWhich run this was | How to checkMatches the run in your account |
| Release | What it tells youThe release the measurement belongs to | How to checkIts entry in our public log |
| Model | What it tells youWhich model read your documents | How to checkCompare it with the release's entry in our public log |
| Documents read | What it tells youHow many files went in, and exactly which | How to checkHash your own files and compare |
| Outputs | What it tells youThe exact files sent to your broker | How to checkHash the files you received |
| Access paths | What it tells youWhat this release allows | How to checkA property of the published code; read the release notes |
| What could leave | What it tells youEverything the machine was allowed to send out | How to checkSame |
| Working copy | What it tells youThe keys to the working copy were destroyed | How to checkA statement by our code; see limit 7 |
| Times | What it tells youWhen the run happened | How to checkFrom the server clock; not attested by hardware |
| Receipt signature | What it tells youThe sealed machine signed every line above | How to checkCheck it with the key bound in the AMD report (Verify, step 5) |
Why trust a line our code states?
Because the AMD report shows which code was running when the receipt key was made, and that code is published. You, or a reviewer you hire, can read what it does. These lines are only as good as that code. That is why we publish every release and seek outside review.
What the receipt does not show
It holds no document content: only hashes, counts, versions and times. It does not show where the machine was, or what your broker did with the claim after receiving it.
Each Sealed claim, and how to check it
With those tools, you confirm that:
- AMD signed the report, with keys that chain to AMD's root.
- The platform's patches meet our published minimum.
- Debugging was off.
- The code matches a release in our public log.
- The receipt was signed with the key that sealed machine named in its AMD report.
- The files match the hashes in the receipt.
| Claim | Backed by | How you check | Limits |
| In Sealed mode, no one sees your documents without your consent | Backed byThe four conditions in section 3; the published machine image | How you checkReceipt: debug off, measurement matches the logged release. Release notes list the access paths | LimitsPhysical access (limit 2). You still trust AMD (limit 1) |
| Each run ends in a receipt anyone can check against AMD's keys | Backed byThe AMD report inside the receipt, bound to the receipt key | How you checkThe verify page, with open-source tools such as snpguest | LimitsShows which code ran, not that the code has no bugs (limit 5) |
| The working copy is erased at the end | Backed byCryptographic erase in the published code | How you checkThe receipt's "Working copy" line; the release's code | LimitsA statement by our code, not by AMD. NIST's conditions apply (limit 7) |
| Your documents never train any model | Backed byThe model runs inside the sealed boundary; its weights hash is published; only encrypted files to you and your broker, claim totals and the receipt can leave | How you checkThe receipt's Model line names the weights that ran | LimitsRests on the outbound block in the published code (limit 5) |