The Linux Foundation now governs TRACE, short for Trust, Runtime Attestation and Compliance Evidence. OPAQUE contributed the specification, announced on 25 August 2026, and developed it together with AMD, Intel, Microsoft and the Technology Innovation Institute. The idea is one signed artifact, called a Trust Record, that says which model ran, on what hardware, under which policy, against which class of data and which tools it called. The point of signing it inside a trusted execution environment is that the operator cannot write it afterwards. An ordinary audit log is written by the system being audited. This one is not.
That is a real distinction and it is the same distinction my own work rests on. A number someone reports about themselves is a claim. A number a third party can check is evidence. TRACE moves runtime logging from the first category toward the second.
Then I read the project's own documentation instead of the press release, and the interesting part is what the specification refuses to promise.
The level is the claim, not the name
TRACE has three trust levels and they are not close to equivalent.
Level 0 is software-only signing. The project writes that a privileged operator with root access can produce a valid-looking Level 0 record for a run that never happened, or that violated policy. The documentation puts Level 0 in development, internal audit trails and staging environments, and says so plainly.
Level 1 requires the record to be signed by a key generated inside a verified TEE, with a non-zero measurement of the launch state and a verifier that has actually checked the quote. This is where hardware-rooted starts meaning something.
Level 2 adds a SCITT transparency log entry at a resolvable address, so a third party can check later that the record has not been altered since it was logged. It still does not prove that every field in the record was correct in the first place.
So "we use TRACE" is not a statement about assurance. The level is the statement, and a vendor who names the standard without naming the level has told you nothing. Anyone who has read an agent-readiness score without the scanner and the level next to it will recognise the shape of that problem.
Two limits worth knowing before anyone builds on this
The specification is honest about both, which is more than most standards manage.
Revocation is the place where the project's own two documents pull in different directions. They agree on the underlying fact. A signature stays mathematically valid forever, so a record signed by a key that has since been revoked keeps verifying on a machine with no network. The limitations page then says the verifier has to consult current revocation status at verification time and calls that an online step by definition. The specification says close to the opposite and says it by design: revocation statements are anchored in the same transparency log as the records they govern, verifiers cache a signed revocation bundle carrying an expiry, and the text describes this as deliberately replacing a status endpoint that would require a callback. Which behaviour you get depends on which of the two a given implementation followed, so ask. Both documents agree on the fallback, and it is the sane one. A verifier holding no revocation bundle, or only an expired one, reports that instead of treating it as a pass.
Platform state is not appraised. On the AMD path the verification chain checks the report signature and the certificate chain from the VCEK up to a root the operator pins, and it checks the measurement binding. What it has no field for is the state of the machine that produced the report. As the documentation puts it, a verifier reading a conformant claim cannot appraise platform state even when the producer did check it.
Neither of these makes TRACE useless. They make it a layer with edges, and knowing where the edges are is the whole job when you are the one signing off.
The half TRACE does not cover
A Trust Record proves how an agent ran. It says nothing about whether the systems that agent touched were readable to it, whether the tool it called should have been callable at all, or whether the decision boundary around it was written down anywhere.
That is the split I keep running into. Attestation is evidence about execution. Agent-readiness is evidence about the surface: whether your site, your data and your endpoints answer a machine the way they answer a person, and whether the permissions around them are something you can point at rather than something living in one engineer's head. An organisation can have a perfect Level 2 record of an agent doing exactly the wrong thing, correctly, against data it should never have been given.
Both halves are receipts. They are receipts about different questions.
What this is worth today
The specification is a developer preview. Version 0.2 is current and the draft says its fields and conformance requirements may change before v1.0. The download figure in the announcement is the contributing vendor's own number and it counts installs, not deployments, so it is not evidence of adoption. Treat all of that as a snapshot of this month, exactly as you should treat any number I publish about my own site.
The part that is already useful is the vocabulary. If you run agents against production data, the question to ask a vendor is not whether they support TRACE. Ask which level their records reach, whether their verification checks revocation, and what happens to the answer when the network is down. Those three questions are answerable today and they do not depend on the specification reaching v1.0.
For EU buyers there is one more concrete hook. The project states that Level 0 does not satisfy the tamper-evident logging requirement of EU AI Act Article 12, and that DORA Article 9 needs Level 1 or above with transparency log anchoring. If someone shows you a compliance story built on software-only signing, that gap is written down in the specification's own limitations page.
Sources: Linux Foundation press release, 25 August 2026, TRACE v0.2 specification, TRACE trust levels, TRACE known limitations, trace-spec on GitHub.
Related
Originally published at https://turva.dev/blog/trace-runtime-attestation
Top comments (5)
Erik, great breakdown — highlighting the gap between runtime attestation and surface policy is the exact boundary most teams miss right now.
From a practitioner standpoint, this split creates a dangerous illusion of compliance. A Level 2 TRACE record essentially gives you a cryptographically valid receipt of a policy breach. The hardware proves the agent executed cleanly inside a TEE, while the agent itself launderes an unauthorized call simply because the underlying MCP server or index served it without a live boundary check.
Until attestation standards like TRACE bind execution state directly to semantic & state verification at the boundary (e.g., asserting not just which tool was called, but whether the payload state was still valid and authorized at query time), TRACE handles the hardware trust while leaving the application trust entirely exposed.
Are you seeing any early specs trying to bridge hardware attestation down to the MCP / tool call context level, or do you think these will remain two isolated verification layers?
Yes, one exists: the PIC/TRACE authorization bridge, in the integration section of the TRACE docs. It binds a signed pre-execution authorization to the call that followed, and the verifier checks that the executed tool was inside the authorized scope and that the recorded call equals the authorized one. Two catches. It is informative and optional and it does not touch the Trust Record schema, so conformance tells you nothing about whether anyone turned it on. And it binds a decision made before execution, inside a validity window, so your query-time question stays open. The stitching is at the authorization boundary rather than the state one.
Erik, thanks for checking the integration section — that answer is worth more than the press release.
Two catches, two different failure modes.
The optional one is default-off security: the mechanism exists, the guarantee doesn't. Conformance tells you nothing about whether anyone turned the bridge on, so "TRACE-conformant" can silently mean "bridge off".
The second catch is the real one, and it has an old name: TOCTOU. The bridge binds a decision made at T0 to an execution at T1 inside a validity window, and nothing revalidates at T1 — the schema cannot, because it has no field to put the result in. So the completed stack is: authorized tool, recorded call equals authorized call, TEE-signed, anchored in a transparency log — executed against context that went stale before the call. A cryptographically perfect hallucination, now with hardware attestation behind it. You proved the box was locked; nothing checked whether what was inside was still true.
The minimal fix already has vocabulary too: version tokens. If tool responses carry a state token (ETag / compare-and-swap — nothing new) and the record references it, the chain extends from "authorized tool" to "authorized tool against state X", and what no verifier can appraise today becomes checkable at audit time.
Question: does v0.2 have any hook for binding tool responses — anywhere a response commitment could live — or is binding state beyond what the schema can even express?
Two places, and they behave differently. The tool transcript hash is a sha256 over the canonical audit entry list, and the transcript records responses at the gateway boundary, so a response commitment already exists. The references block is the other one: rel is a registry rather than a closed set, so a state token fits there with no schema change. The catch is section 3.1.2, which tells verifiers not to treat a resolved reference as attested evidence and not to reject a record over one. So your version token is expressible today. It just cannot fail anything, and that is a verifier rule rather than a schema limit.
That splits my question into three, and the third is the load-bearing one. Commitment: exists — the transcript hash covers responses at the gateway boundary. Expression: exists — an open rel registry means a state token fits the references block with no schema change. Consequence: forbidden — and you are right that this is a verifier rule rather than a schema limit, which is sharper than my "the schema cannot." The gap is normative, not structural.
The asymmetry that follows is what I'd want v1.0 to answer. The verifier already runs a consistency check with teeth: recorded call equals authorized call. That is a cross-artifact comparison — two signed things must agree — and the spec enforces it for tool identity. 3.1.2 denies the same treatment to state: the authorization's expected state and the response's carried token may contradict each other, and the verifier may not fail the record over it. Double-entry bookkeeping is the old frame: the books agreeing with each other is a closed-form, offline check, categorically different from the books agreeing with the world — which is unrecoverable at audit time anyway. 3.1.2 correctly refuses the second check. Refusing the first is a policy choice that needs a reason, and I cannot construct one that does not also apply to the tool-identity equality check.
So the minimal fix may be narrower than "bind state": not a verifier that knows the world, but a verifier that requires the record to be internally consistent — both values inside the signed boundary, comparison is pure computation, no online step, no claim about whether the state was true. Same shape as the check the bridge already performs on tool identity.
Question: how does 3.1.2 interact with the bridge's equality check? If the signed authorization counts as a reference under 3.1.2, the spec contains both "references cannot fail a record" and "this reference must match or fail" — an internal tension. If the bridge check lives outside the record-verification rules, then a state-consistency check has a precedent path: define it the same way, in the integration section, schema untouched. Which is it?