How to verify AI enclave attestation: the seven checks, and who should run them

The Morse teamPublished October 25, 20268 min read

As of October 2026, you verify an AI enclave's attestation by checking its signed report on your own device in seven steps: send a fresh nonce, follow the signature to the chip maker's root, check the patch level, compare the measurements to pinned values, confirm debug mode is off, confirm your encryption key is bound into the report, and only then send. Attestation is the enclave's report, signed by keys in its processor, of exactly what software it's running; our guide to the trusted execution environment has the full definition.

We read the IETF's attestation architecture (RFC 9334), Intel's TDX documentation, AMD's SEV-SNP attestation talk, NVIDIA's attestation service docs, and the verification pages of Brave, Maple, Confer, and Venice on October 20, 2026. The checklist below is built from those documents, and how much it protects you depends on who runs it.

Who takes part in remote attestation for AI?

Three parties pass one report between them. RFC 9334 calls the machine being checked the Attester, "typically a device", whose Evidence "must be appraised." The Verifier "appraises the validity of Evidence," and the Relying Party "depends on the validity of information about an Attester" to decide what to do (IETF). In an AI chat, the enclave is the Attester and your app is the Relying Party. The Verifier can be your app, the company's server, or the chip maker's cloud service.

The RFC describes two layouts. In the passport model, the Attester takes its Evidence to a Verifier and carries the result to whoever asks. In the background-check model, the Attester gives Evidence to the Relying Party, which "treats it as opaque and simply forwards it on to a Verifier." The starting point is distrust: "By default, the Relying Party does not believe the Attester to be compliant" (IETF).

AMD's talk on SEV-SNP says attestation "delays and delegates the security decision of whether a guest is trustworthy to the guest owner" (AMD, September 2022).

What's in the report you're checking?

Measurements, versions, and one field the requester controls. The names differ by vendor:

• Intel TDX. The TDX module builds a fixed-size TDREPORT. Measurements of the guest's initial configuration and firmware go into a register called MRTD, and the kernel, command line, initrd, and similar items go into runtime registers (RTMRs). "A user-provided 64-Byte REPORTDATA is used as input and included in the TDREPORT" (Linux kernel).
• AMD SEV-SNP. The report carries a MEASUREMENT of the guest's memory at launch, the guest POLICY (whether debugging is allowed, for example), image IDs, a unique CHIP_ID, and several TCB fields giving firmware and microcode versions. REPORT_DATA is a 64-byte field the guest supplies, "not interpreted by firmware" (AMD).
• NVIDIA GPUs. The GPU's evidence includes measurements of its firmware and driver, which are checked against NVIDIA's reference integrity manifests (RIMs). NVIDIA's SDK fails when "the driver version in attestation report is not matching with the driver version fetched from the driver" (NVIDIA).

That 64-byte field is how a report vouches for a key. AMD's slides suggest the guest generate a key pair, hash the public key, and place the hash in REPORT_DATA, so the signed report covers that key, and anyone with the public key can open a channel only that guest can read (AMD).

How do you verify an AI enclave, step by step?

Here is one full appraisal, built from the vendors' own documents. Each step closes a specific gap, and a verifier that skips one leaves that gap open.

1. Send a fresh nonce. The verifier sends a random value and expects it back inside the signed report. RFC 9334 describes it as "an unpredictable nonce" that is "signed and included along with the Claims," and lists timestamps and epoch IDs as the other ways to prove freshness (IETF). NVIDIA's service wants 32 bytes and rejects a report when the "nonce from request is not matching with evidence nonce" (NVIDIA). Without it, an old, valid report could be replayed by a server that has since changed.
2. Check the signature chain to the vendor's root. On Intel, the TDREPORT "can only be verified on the local platform as the MAC key is bound to the platform," so Intel's quoting enclave converts it into a quote that can be checked remotely (Linux kernel). On AMD, a key called the VCEK, derived from a chip-unique secret and the reported firmware versions, signs the report; the AMD SEV CA certifies the VCEK, the AMD Root CA certifies the SEV CA, and the certificates come from AMD's Key Distribution Service (AMD). NVIDIA's SDK expects five certificates and fails a chain that "does not belong to NVIDIA PKI" (NVIDIA).
3. Check revocation and patch level. A genuine chip can still be running old, vulnerable firmware. Intel defines the TCB level as "the combination of all patch versions of all the components that are part of the TCB," and its verification collateral expires "30 days from the time of download," so it has to be refreshed (Intel). AMD's slide asks of the committed version, "Does this TCB address all the vulnerabilities you care about?" (AMD). NVIDIA checks certificates against its OCSP service and, if one is revoked, recommends that you "stop the use of the current device" (NVIDIA).
4. Compare the measurements to pinned values. This is where the verifier learns what software is running, rather than just that the chip is real. RFC 9334 calls the expected numbers Reference Values: "a set of values against which values of Claims can be compared" (IETF). NVIDIA's verifier fails on "a mismatch between one or more measurements in the attestation report and the reference values from the RIMs" (NVIDIA). The pinned list has to come from somewhere the verifier trusts, ideally a build anyone can reproduce.
5. Check the policy. Debug mode has to be off, because a debuggable enclave can be read by its host. Venice's guide tells developers to "verify the TDX attestation doesn't have debug flags set" (Venice), and AMD's report exposes the POLICY field for exactly this question.
6. Check the key binding. The public key you're about to encrypt to must be the one whose hash sits in the 64-byte report field. Venice's guide says "the signing key should be bound to the TDX REPORTDATA field" (Venice). Without this step, a valid report from one machine could be paired with a key from another.
7. Decide, then send or don't. Only after every check passes does the app encrypt to that key. If any fails, nothing should leave the device.

None of this needs the chip maker's permission. Intel says TDX quote verification "can be done by any party at an arbitrary location" (Intel). AMD's talk points to open-source tools such as sev-tool that validate the report's signature and certificate chain (AMD). NVIDIA's SDK has a local verifier that appraises GPU evidence "in the current process," as an alternative to sending it to NVIDIA's Remote Attestation Service (NVIDIA).

What does remote attestation prove, and what doesn't it?

The 2025 memory-bus attacks needed physical access to the server, so they don't undo attestation, but they show its proof is only as strong as the keys behind it and the data center around them.

Who runs the check in AI apps today?

For any app, ask where the check runs, and against what. Here is how four AI apps that use enclaves describe it on their own pages, read October 20, 2026:

Confer ties the attestation to the same handshake that carries your messages and extends its measurement "to cover the entire root filesystem" (Confer). Brave's oracle "confirms the attested model is the one requested," and Brave plans for the browser to check the hardware attestation directly (Brave); we compare these designs in Maple vs Confer and Duck.ai vs Lumo vs Brave Leo.

How Morse checks the enclave in your browser

When a server verifies the enclave and tells your app it passed, you're trusting that server. In Morse's E2EE mode, your browser verifies the enclave's cryptographic proof itself before anything leaves your device. It compares what's running against versions pinned in the app, and an OS image hash that differs from the pinned one fails the check.

Every E2EE reply carries a lock you can open to see each check that passed, and a full report you can download. The guarantee depends on the enclave hardware and attestation working as designed. We follow a message from your keyboard to the enclave and back in how end-to-end encrypted AI chat works.

E2EE chats come with Pro, at $19 a month, so you can start free, upgrade, and open the lock on your first reply.