Seven bits the record cannot carry

Byte 0x40 of an AMD SEV-SNP attestation report holds eight bytes called PLATFORM_INFO. Seven of its bits are defined, and between them they describe the machine rather than the workload: whether SMT was enabled, so that hardware threads shared a core; whether transparent secure memory encryption was on; whether the memory had error correction; whether the power-measurement interface was disabled; whether ciphertext hiding was enforced for DRAM; whether SEV-TIO was active; and whether the firmware had finished checking for aliased physical addresses since the last reset. Google's go-sev-guest, which TRACE's own documentation calls the reference verifier, parses all seven into a struct with named fields and readable comments.

Then, by default, it checks none of them. The option that would constrain those bits carries a three-word doc comment: Not checked if nil. Nil is what you get when you do not go looking. The validator function opens by returning success if no platform policy was supplied, which is the state of every deployment that has not thought about this specific question and written code about it.

That is a fine default for a library. What makes it worth an argument is what is now being built on top of it. Attestation is being promoted from a mechanism into an evidentiary base — the thing an organisation will hand an auditor, an insurer, a regulator or a counterparty to show that an AI agent ran the way it said it did. And the vocabulary of that evidence certifies more than the checking underneath it does.

The specific occasion is TRACE — Trust, Runtime Attestation, and Compliance Evidence — whose repository records that the Linux Foundation took it on as its own project series on 25 August 2026, developed with AMD, Intel, Microsoft, OPAQUE and TII. TRACE defines a Trust Record: a signed document stating what model ran, in what runtime, under which policy bundle, touching which data class, calling which tools. The specification's ambition is stated plainly in its own opening — a single signed artifact rooted in silicon attestation, travelling with the workload across hosts, clouds and providers, verifiable offline by any party. Its verification section is emphatic about the payoff: No callback to the issuer. No vendor in the trust path beyond silicon root and transparency log operators. That is the property that makes portable evidence attractive. It is also the property that makes what the record omits permanent.

The record's runtime block is where the hardware claim lives. In the published JSON schema it is an object with additionalProperties: false and exactly five members: platform, measurement, rim_uri, nonce, firmware_version. There is nowhere to say that SMT was off, that ciphertext hiding was enforced, or that the alias check had completed. The appraisal block — the verifier's verdict on the evidence — is closed too, with five members of its own: a status, a verifier URI, a policy reference, a timestamp, and the supply-chain depth that was walked. A verifier that did check PLATFORM_INFO, and found it satisfactory, has no conformant place to write that down.

TRACE says so itself, and says it better than a critic would. Its limitations document walks the four checks the SEV-SNP path performs — report signature, the VCEK-to-ASK-to-ARK chain with the root pinned by the operator, and measurement binding — calls them the right four checks, and then observes that what none of them ask is what kind of machine the report came from. A report from a host with SMT enabled and the alias check never completed verifies exactly as cleanly as one from a host with neither condition. The document then states the consequence for its own format: a verifier reading a conformant claim cannot appraise platform state even where the producer checked it.

This is a specification arguing against itself in public, which is rarer and more useful than most specifications arguing for themselves. Its draft proposal for the next version goes further. A v0.2 record carries no attestation quote at all, so platform: "intel-tdx" is, in the proposal's own table, nothing; a string the issuer wrote. A verifier that reports "TEE-attested" on that basis is, in the proposal's phrase, reporting the issuer's assertion in the verifier's voice. The fix on offer is a ladder of three grades — unattested, platform-attested, attested — and even at the top the proposal is careful: a grade on the record is not a grade on its claims. The named model weights remain self-reported. Genuine silicon is in scope; current firmware is not. The top grade is, by the authors' own admission, currently unreachable from any artifact in the repository.

Here is the difficulty, and it is not a difficulty about TRACE. Every one of those qualifications is correct, published, and free to read. None of them will make the trip. What crosses an organisational boundary is the word. A procurement questionnaire asks whether inference runs in an attested enclave. A control framework asks for tamper-evident records of automated decisions. Someone answers yes, and attaches a signed document whose platform field says amd-sev-snp. Every caveat in the chain — the nil policy, the closed schema, the grade that is narrower than its name — lives in files that the person reading the answer will never open.

The strongest objection is the layering one, and it deserves to be put at full strength. The remote attestation architecture the field has settled on deliberately separates evidence from appraisal policy. Evidence is what the hardware says; policy is what the relying party decides to require. Freezing "SMT must be off" into a record format would be a category error and would age badly: hardening advice changes with each microarchitecture, each mitigation, each new side channel. A library that refused reports from SMT-enabled hosts by default would break most deployments on day one and teach everyone to disable the check. And TRACE does have a place for a verdict — the appraisal block exists precisely so a record can say that some competent party looked. On this reading the seven bits are not missing from the architecture. They are in the layer where they belong, and an operator sophisticated enough to be running confidential computing at all is sophisticated enough to write the policy.

That argument is right about mechanism and wrong about what portable evidence does to it. Separating evidence from policy works when the party appraising the evidence is the party that operated the machine, because they know what they configured and what they required. Portability breaks that. The whole point of a Trust Record is to be read by someone with no relationship to the host — and for that reader, "a policy was applied somewhere" and "no policy was applied" produce the identical artifact. The appraisal block can name a verifier and assert a status; it cannot say what that verifier actually checked, which means relying on it reintroduces exactly the trust in a third party that the no-callback design set out to remove.

There is a second asymmetry, and TRACE's own proposal names it. The specification already reasons carefully about what it calls assurance laundering: a record assembled from someone else's logs must declare its origin and must downgrade its platform to software-only, and a pointer to an external fact may never be counted as attested evidence, because nothing about naming your producer makes unattested evidence attested. Both rules govern pointers out of the record. Neither governs runtime, where a rim_uri is a pointer, a measurement is a transcription, and appraisal.verifier names somebody else's verdict. The doctrine was written and then not applied to the one block that most needed it.

What this points at is larger than one draft specification, and it is the reason to care before v1.0 rather than after. Governance regimes do not invent their own evidence; they discharge their obligations against whatever format exists when the deadline arrives. A schema with additionalProperties: false is not a technical detail at that point — it is the outer boundary of what any institution downstream is able to ask for. Questions that have no field go unasked, then unasked becomes unasked-for, and within a few years the absence reads as consensus that the question did not matter. The honest limitations file does not travel with the record. The schema does.

Everything above is drawn from the two projects' own published files, read in their repositories rather than in coverage of them; I could not reach the Linux Foundation's announcement directly, and take the repository's account of its own governance at its word.

So the practical residue for anyone accepting attestation as evidence is small and unglamorous. Decide what PLATFORM_INFO must say for your workloads, write that policy explicitly, and keep your own record of what you checked, because the format you are handed may not have room for it. And when a signed record arrives with attested on it, read it as a claim about who wrote the document, until something tells you otherwise.

Bit 5 is set when the firmware has finished looking for aliased memory addresses and found none. It is a single bit, it is already in the report, and the code that reads it has been written. What is missing is anywhere to put it and any default that asks. The bit is not absent. It is merely not part of the story the industry has decided to tell about whether a machine can be trusted — and stories, once standardised, are very hard to add a sentence to.