Sealed processing
Verify a Sealed receipt yourself
Every Sealed run ends in a receipt. You, or your auditor, can check it with open-source tools we do not control.
About 3 minutes on a sample file. Your email and name open it. We never ask for your ACE login or bank details.
Plain roles
Who does what in a check?
Checking a receipt involves five roles. The names come from the internet standard for remote attestation (IETF RFC 9334).[1]
Read the diagram as steps
- The sealed machine asks AMD's chip for a signed report.
- Your verifier checks the report and receipt against AMD's certificates and the expected measurement in our public log.
- You, the relying party, decide whether to trust the receipt.
For the parts the hardware proves, you do not need to trust us. You trust AMD, the verifier you choose, and your own reading of our published code.
The five roles, in plain words
| Role | Who | What they do |
|---|---|---|
| Attester | The sealed machine that ran the job | Asks AMD's chip for a signed report about itself |
| Endorser | AMD | Vouches for the chip through a chain of certificates |
| Reference value provider | NexQloud | Publishes each release's expected measurement in a public log |
| Verifier | The tool you run: snpguest or go-sev-guest | Checks the report and receipt against AMD's keys and our published values |
| Relying party | You | Decide whether to trust the receipt |
Sample receipt
Where can you see a sample receipt?
In the demo, on sample data. Turn on Sealed, and the claim package ends with a receipt you can check.
In the demo, the AMD signature check is simulated. The document and claim-file checks run in your browser.
What a receipt holds
A receipt has three parts. The Sealed page lists each field and how to check it.
| Part | What it holds |
|---|---|
| The AMD report | Signed by AMD's chip. The launch measurement, the guest policy (debugging off), the platform's patch levels and flags, and report data that ties the report to the receipt key |
| The statements our code signed | The run, the release, and the model with its weights hash. A hash of every document read and of every file sent to your broker. The access paths, what could leave, and when the working copy was erased |
| The receipt key and signature | A public key our code creates inside the sealed machine for each run, and its signature over the statements |
Step by step
How do you check a receipt, step by step?
In a Sealed run, your browser runs these checks before it releases your key. Anyone can run them again.
You need snpguest (open source), OpenSSL, jq, and sha256sum or shasum, on Linux or macOS.[2]
-
Step 1. AMD signed the report, with keys that chain to AMD's root
Fetch AMD's certificates with snpguest: the root (ARK), the intermediate (ASK) and the certificate of the chip that signed the report (VCEK).
Check that ARK signed ASK, ASK signed VCEK and VCEK signed the report. Then check AMD's revocation list.
Pass: the certificate chain and the report signature both check, and neither the ASK nor the VCEK is on AMD's revocation list.
If our hosts use VLEK
If our hosts use VLEK, a key the cloud provider loads instead of the chip's own VCEK, fetch the VLEK chain instead (snpguest's
--endorser vlekoption).[3] -
Step 2. The platform was patched and debugging was off
Display the report with snpguest. Check three fields, and copy two values for later:
- Guest policy: debugging is not allowed.
- Reported TCB: bootloader, TEE, SNP firmware and microcode are each at or above our minimum (section 5).
- Platform info: the memory alias check is complete.
- Copy the measurement (for step 3) and the report data (for step 4).
-
Step 3. The code matches a published release
Find the release in our public log. Its expected launch measurement must equal the one from step 2, character for character. To rebuild it yourself, see section 4.
-
Step 4. The receipt key belongs to that machine
Take the receipt's public key and the run's nonce from the receipt. Hash the two together with SHA-512.
Pass: the 128-character result equals the report data from step 2. So the machine AMD measured named this key as its own. Our published code creates it there and never lets the private half out.
-
Step 5. The receipt's signature is valid
Check the signature over the signed statements with the receipt key, using OpenSSL.
Pass: OpenSSL prints
Verified OK. -
Step 6. The files match the receipt
Hash the files you uploaded and the files your broker received, with SHA-256.
Pass: each hash matches the one the receipt lists for that file.
-
Step 7. The release has not been revoked
Look up the release in our public log (section 8 explains revocation). A revoked release fails, even if every other step passes.
Prefer Go?
Google's open-source go-sev-guest library does the same job in code. Its verify package checks the report's signature and certificate chain. Its validate package checks fields such as the measurement, report data, guest policy and minimum patch levels.[4]
The public log
Where does the expected measurement come from?
From a public, append-only transparency log.[5] No entry can be changed or removed without that showing.
Your browser releases your key only to a logged release, so we cannot run unlogged code on your documents.[6]
Rebuild the value yourself
We publish each release's expected measurement in a public, append-only transparency log. Anyone can see every release we have shipped.
The release record lists every input. Download them, then run sev-snp-measure (open source, from the VirTEE project) with the settings the record lists.[7]
Pass: the output equals the measurement in the report and in the log.
The kernel command line carries the root hash of the read-only disk the agent and model run from. So the measurement covers that disk too, not only the start-up code.
Where the files came from
Each release record links its build provenance: the source commit and the build that produced the files.
Minimum patch levels
Why do patch levels matter?
AMD fixes most SEV-SNP issues with firmware and microcode updates.[8] Our checks reject any platform below our minimum patch levels.
The AMD bulletins we track
AMD publishes security bulletins for SEV-SNP and fixes most issues with firmware and microcode updates. A receipt from an unpatched machine should not count.
| Date (per AMD) | Bulletin | Issue | Who could exploit it | AMD's fix |
|---|---|---|---|---|
| Nov 2023 | AMD-SB-3005 | CacheWarp (CVE-2023-20592) | A malicious hypervisor | Microcode |
| 2024 | (research, not a bulletin) | Heckler and WeSee: malicious interrupts sent into the guest[9] | A malicious hypervisor | Hardening in guest software |
| Dec 2024 | AMD-SB-3015 | BadRAM (CVE-2024-21944) | Physical access, or BIOS or kernel control | Firmware, plus an alias-check flag in the report |
| Feb 2025 | AMD-SB-3019 | Microcode signature bypass (CVE-2024-56161) | A local admin | Microcode and firmware |
| Sep 2025 | AMD-SB-3024 | Battering RAM: physical memory aliasing[10] | Brief physical access plus privileged host access | None. AMD: out of scope |
| Oct 2025 | AMD-SB-3020 | RMP initialization race (CVE-2025-0033) | An admin-level hypervisor | SNP firmware and microcode |
| Oct 2025 | AMD-SB-3040 | TEE.fail: DDR5 bus interposition | Physical access | None. AMD: out of scope |
| Jan 2026 | AMD-SB-3027 | Guest stack-pointer corruption (CVE-2025-29943) | An admin | Microcode and firmware |
| Feb 2026 | AMD-SB-3043 | SNPeek: software side channels | A malicious hypervisor | Out of scope; newer chips add Ciphertext Hiding; constant-time code |
| Apr 2026 | AMD-SB-3034 | MMIO routing misconfiguration (CVE-2025-54510) | An admin | Firmware |
| Aug 2026 | AMD-SB-3032 | PowerHooK: power side channel | A hypervisor with access to power readings (RAPL) | Restrict RAPL; constant-time code |
| Aug 2026 | AMD-SB-3033 | SEV firmware code execution | Physical access | Firmware, as defense in depth |
| Sep 2026 | AMD-SB-3048 | DDR5 fault injection | Physical plus privileged access | None. AMD: out of scope |
How we keep this current
We check AMD's product security page regularly. When a new SEV bulletin appears, we assess it, raise the minimum if a fix exists, re-attest our hosts and log the change.
Tamper test
What happens if someone changes the receipt?
The checks fail. Here is what each change breaks:
Change a statement.
Change the document count. Step 5 fails: OpenSSL prints
Verification failure.Change the AMD report.
Change one byte of the AMD report. Step 1 fails: its signature no longer verifies.
Change an output.
Add one space to a claim file. Step 6 fails: its hash no longer matches the receipt.
The demo runs the third test on sample data.
Get started
Prove it on every claim.
Run the demo in Sealed mode. About three minutes.
-
01
Choose Sealed.
Pick Sealed mode when you upload your records.
WhoYou
-
02
The agent works inside the enclave.
Your records are read inside AMD SEV-SNP hardware.
WhoThe agent
-
03
You get a signed receipt.
The working copy is erased. Anyone you share the receipt with can verify it.
WhoYou
Your email and name open the demo. We never ask for your ACE login or bank details.
Ready now? Start a claimWhat this proves
What does a passing check prove?
What a passing check proves
- The report came from a genuine AMD processor, signed with a key that chains to AMD's root
- The sealed machine started from the code we logged for its release
- Debugging was off, and the platform met our minimum patch levels when the report was made
- The receipt was signed with the key that machine named in its AMD report
- The files you hold are the files the receipt names
What it does not prove
- That our code is free of bugs, or does only what we say. That needs published code and outside review
- Anything the machine loaded later that the measured code did not check
- Resistance to physical attacks or side channels. AMD calls both out of scope
- That data never left through the code's own allowed outputs. You rely on the published code for that
- Where the machine was located, or that it stayed up
Hardware facts and code statements
The measurement, guest policy, patch levels, platform flags and report data are attested by AMD hardware.[11] Everything in the signed statements (documents read, model, outputs, access paths, what could leave, the erase time) is a statement by our measured code. A passing check proves those statements were signed with the key that measured machine named, and have not changed since. It does not prove the code told the truth. That is why the code is published and reviewed.
You still trust AMD's chips, firmware and keys. The full list of limits is on the Sealed page.
Read all ten limitsRevocation
What happens when a release goes bad?
If we find a flaw in a release, or AMD publishes a bulletin our minimum does not cover:
We mark the release revoked in the public log, with the date and the reason.
Key release stops for that release: your browser's check and our key service both refuse it.
We tell every client whose runs used it, and their brokers.
Receipts from that release still verify as authentic. The verifier also shows the revocation date, so you can judge runs made before it.
Security contact
Found a security problem with a receipt?
Tell us. Our vulnerability disclosure policy and security.txt file cover how to report, scope, safe harbor and what happens next.[12]