Clarion Street

The Receipt Proves Who Wrote It, Not What the Chip Did

·14 min read

An open standard for proving what an AI agent did shipped this summer, and the most useful page in the project is the one listing what it cannot prove.

TRACE stands for Trust, Runtime Attestation and Compliance Evidence: a signed record of one agent run, contributed to the Linux Foundation by the confidential-computing vendor OPAQUE and developed with AMD, Intel, Microsoft and the Technology Innovation Institute [1][10]. If you read the August post here on audit trails, the “Trace” in it was Microsoft’s microsoft/trace, a computational-graph tool for optimising prompts and code. Different artifact entirely.

The Foundation announced the contribution on 25 August and described the artifact as binding “the runtime environment, software, policies, data classifications and tool usage into a portable, cryptographically verifiable artifact” [1]. The specification’s own abstract, a few paragraphs into the document, says: “The reference SDK does not verify attestation evidence” [2].

Both sentences are true of the same release, and none of it is a scandal about a draft behaving like a draft. v0.2 is labelled a Developer Preview, the conformance suite ships with it, and the project published a proposal describing its own gap in more detail than a critic would have. The narrower finding is that the marketing line runs ahead of the shipped artifact, and the shipped artifact happens to be the best public description anyone has written of what an agent receipt can actually prove.

What is actually shipping

The PyPI package recorded 162,054 downloads in the thirty days to 31 October and 19,353 in the last week [5]. Nineteen third-party integrations are registered against the format, nine at a Verified tier, meaning their own maintainers ran them end to end against released packages [10]. The spec repository shows 43 stars and 39 forks, and its last push was 30 October [11]. Whatever else is true of it, there is a schema, a conformance suite and a reference library, which is more than most governance announcements carry.

Downloads and stars measure different things, and neither measures reliance. A monthly download count with mirror traffic baked in describes CI pipelines more than deployments, which is why the PyPI stats page carries a With_Mirrors toggle. I read 162,000 as evidence the library is being exercised. I would not read it as evidence that anyone’s auditor depends on the output.

The signature proves who signed

v0.2 closes its record object with additionalProperties: false, and the runtime member holds a platform name, a measurement digest, a RIM URI and a nonce [4]. That is five fields, and none of them has room for the hardware’s own signed report.

The project wrote the clearest account of what that costs a verifier, in a proposal that would add the missing field. It walks a relying party through four claims and what the record offers for each. A TD ran, and the record offers a string the issuer wrote. Something was measured, and the record offers a string the issuer wrote. Someone checked, and the record offers a URI naming a third party. The issuer said all this, and the record offers a signature over the signing key. Only that last row is something a verifier can establish [4].

Four rows, and the conclusion the project draws from them:

The record is signed, and the signature is sound. It attests authorship. Every hardware claim inside it is the issuer’s word, and a verifier that reports “TEE-attested” on that basis is reporting the issuer’s assertion in the verifier’s voice.

The mechanism to close the gap is a draft targeted at v0.3 and marked “Status: Draft proposal. Binds nothing.” It grades a record unattested, platform-attested or attested. Its own account of the top grade is that it has been reached once, on 14 September 2026, by a purpose-built capture program on a GCP TDX trust domain, and not by the reference producer [4].

The honest description of what shipped in August is a signed receipt proving who assembled it. That is worth something. It is not what “hardware-attested compliance evidence” means to the person reading a press release, and the difference stops being academic when the buyer is an assessor.

The schema is what runs

The spec’s claim table maps each record field to the standard it profiles, and maps runtime to “RATS Evidence + vendor RIM” [2]. RATS is the IETF attestation architecture, published as RFC 9334, and EAT is the claim envelope for attestation results at Standards Track in RFC 9711 [6][7]. Neither is in the record. The proposal says so without softening: “The requirement, the mapping, and the schema disagree, and the schema is what runs” [4].

That is how specifications rot, ordinarily. The prose describes what was intended. The schema is what implementations validate against, and it wins, which is why readers who never open the JSON keep acting on the prose.

The proposal also finds a problem I had not seen made this plainly anywhere else, which is that the spec forbids assurance laundering in two places and permits it in a third. Section 3.1.1 forces an importer to declare platform: "software-only" because “an importer holding someone else’s log has no quote to present.” Section 3.1.2 stops a verifier treating a resolved reference as attested evidence. Both rules govern pointers to things outside the record. Neither governs runtime, where rim_uri is a pointer, measurement is a transcription and appraisal.verifier names somebody else’s verdict [4]. Writing a platform string into a record is the same move the spec bans everywhere else.

I have read a lot of specification self-criticism this year, and that is the best of it. It also points at how these formats fail in practice, which is rarely through the cryptography and usually through fields that carry a claim the record cannot support.

What the limitations page admits

The limitations page is the best thing in the repository, and I would rather quote it than summarise it [3].

Level 0 is the entry level, a record signed with an ordinary software key that whoever runs the machine can read. The project’s verdict on it is flat: “suitable for development and audit-trail tooling only, not for third-party verification.”

Policy correctness is out of scope. A record “can show which rules the agent ran under, but not whether those rules were any good,” because the bundle hash attests that a policy was in force, not that it achieved what it was written to achieve.

Model reasoning is out of scope: “TRACE sees what the agent did, not what the model thought.”

Platform state is not appraised, and this is the passage that reads like it cost somebody an argument. An SEV-SNP report carries several machine-level settings in PLATFORM_INFO, including whether SMT is on, whether ECC is enabled, whether ciphertext hiding is enforced, and whether firmware completed the boot-time DRAM alias check. The checks TRACE describes cover only which workload is running. The consequence takes one sentence: “a report from a machine with SMT enabled and the alias check never completed verifies exactly as cleanly as one from a machine with neither condition.” A TRACE claim has no field for platform state, so a verifier cannot appraise it even where the producer checked it.

The sharpest admission is about the portability pitch. A receipt that any third party can check offline is the whole case for a portable evidence format, and it is true as far as it goes. What offline checking cannot do is tell you the signing key is still trusted: “Signature validity is permanent; trust is not.” A key stolen after issuance leaves every record it signed verifying forever, which is why the spec requires an online revocation lookup and verify_record() accepts a revocation store that fails closed when it cannot answer. Without one, the result means the record was validly signed by this key, not that this key should be trusted.

My favourite line in the project is an admission that its own test corpus failed. One vector, limit-substituted-quote-from-the-same-td, was written to be a rejection: two captures from one trust domain, differing only in their guest-controlled binding, and the rules were supposed to catch the swap. They do not. “Rule 4 therefore does not do what it appears to do. It binds a record to a measurement, never to a quote.” Any two quotes from one TD are interchangeable under it. The proposal then admits that a synthetic corpus would have hidden the problem entirely: “Had the corpus been synthetic, both quotes would have been minted with different measurements and the vector would have passed.” The limit was visible only because the artifacts were real and happened to share a trust domain.

That is a project telling readers exactly where its own measurement is thin. I have not seen another project in this space publish a test vector whose result is that its own rule does not work.

The author stopped existing

OPAQUE’s homepage now carries the notice: “Our team is joining Anthropic to carry our work forward, and OPAQUE Systems is winding down its operations” [8]. The company’s post on 13 October says the same thing at more length. SecurityWeek reported on 19 October that OPAQUE had raised a $24 million Series B at a $300 million valuation, listed Anthropic among its customers, and “has not said what the wind-down means for its existing customers” [9].

The standard did not die with the sponsor, and nobody should write that it did. LF Projects holds the series. On 15 October the project lead updated the Foundation proposal to reflect it: “The contributing entity is now TRACE Specification, a Series of LF Projects, LLC, under its 17 August contribution agreement, and I sign as Project Lead. OPAQUE Systems wound down on 12 October, so the body, signatory table and patent terms are updated” [10]. Nine days from corporate wind-down to a corrected governance record is quicker than most projects manage.

The second home is not arranged yet, though. The proposal has carried the Under Review label since 2 October, and that same 15 October comment asks again what the 21 September question asked: whether a Technical Committee sponsor has been identified, and when the Step 1 brief opens the Q&A window [10].

The provenance explains why this looked like an infrastructure story and behaves like a company one. The Agent Governance Toolkit announcement of 2 April 2026 is bylined Imran Siddique, then a Principal Group Engineering Manager at Microsoft [14]. The same person is quoted in the Linux Foundation release as OPAQUE’s Chief Platform Officer [1] and is first of three authors on the v0.2 specification [2]. One engineer’s governance argument moved from a Microsoft blog post to a vendor’s product to a Foundation specification in six months. Then the vendor wound down, and he was still updating the Foundation proposal three days later [10].

I am not suggesting that makes either project wrong. It does mean the convergence you might read as Microsoft, Intel and AMD agreeing independently is closer to one supply chain, which is our October runtime governance post’s territory and not a point I want to re-argue. It also means the delivery of this format depends on a project lead who has just changed employers, at the moment the format needs a committee sponsor.

The frameworks have no slot for it

The spec opens with the question this product category exists to answer. Internal risk teams, external auditors and customer CISOs all ask “how do you prove the agent handled our data according to policy?” [2]. Its §1 table then sets out why nothing currently answers it, and two rows are the argument. Hardware attestation “proves the environment is genuine” but carries “no governance, policy, or data-class binding.” Compliance frameworks are documentation and governance, with “no TRACE cryptographic format specified.” That table is the honest version of the case the press release makes.

The dates on the EU side are later than a lot of material on this beat says. Article 12 requires high-risk systems to support automatic event logging over their lifetime and, as the spec puts it, “does not prescribe tamper-evident logging.” Those obligations were moved by the Digital Omnibus on AI, Regulation (EU) 2026/1744. The spec’s §1 gives the operative dates: Articles 11 and 12 sit in Chapter III Section 2, whose application Article 113(3)(c), as replaced by that regulation, moved to 2 December 2027 for systems high-risk under Article 6(2) and Annex III, and to 2 August 2028 for those under Article 6(1) and Annex I [2][16]. Any material written before July that says these obligations begin in August 2026 was working from a calendar that has since moved; the April Microsoft post is one example [14].

On the CMMC side there is no slot at all. Assessment evidence is produced per requirement through the assessment procedures in NIST SP 800-171A, where each requirement carries a defined assessment method and assessment object [12]. I am reading that model rather than searching it for a prohibition, and the careful statement is that nothing in it describes an artifact type a signed runtime receipt would satisfy. A Federal Register query today returned zero documents for “confidential computing” and zero for “TRACE specification” [13]. That is a query result and not proof of absence, since a rule can publish under a title that uses neither phrase. It is still a fair indication of where the rulemaking has not gone.

The project agrees with all of this about itself. “A TRACE record or verification level does not establish regulatory compliance” [2]. “TRACE levels describe the strength of technical evidence; they say nothing about legal compliance” [3].

Red Hat states the split from the enforcement side better than anyone: the missing piece is “translating governance policy into runtime enforcement” [15]. I covered that argument in the October silicon post and the attestation half at the sandbox layer in the Daytona post, and there is no value in re-deriving either here. Enforcement and evidence are different products sold to the same buyer. A policy that is enforced but never recorded in a form an assessor accepts leaves the audit question where it started.

What would make it worth filing

Only one of the two things this needs is in the project’s hands.

The v0.3 runtime-evidence profile has to land, and the reference producer has to emit the binding the top grade requires. It does not. agent-manifest’s TDX provider binds the manifest digest into the guest-controlled field rather than the record-signing key, so the top grade is “demonstrated by a purpose-built capture program, not by the reference producer” [4]. Two implementations asked the same question gave different answers, which the proposal calls the measurement worth having. Reconciling them is work the proposal creates and does not do.

The other is a policy decision no standards body can make. An assessor has to accept the artifact. Until a regulator or a CMMC assessor says a signed runtime record is evidence of something they were going to check anyway, this is a well-built format with no consumer that needs it yet, and the two-year timeline on the EU obligations means nobody is under pressure to become that consumer.

Bottom line

TRACE is worth watching because it is an open attempt at the artifact an auditor could file, and because its authors published the distance between the promise and the shipped version in more detail than any critic would have. Its own account of the gap is that no open, portable, vendor-neutral standard exists, and this is the most serious candidate I have read. The receipt is real, it is portable, and it proves who wrote it. It does not prove what the chip did, and it will not until a field the hardware signs exists in the schema and the reference producer fills it.

The harder half is not technical. Runtime governance has spent two years building machinery for stopping an agent, and very little for proving afterwards what it was stopped from doing. TRACE is the most serious attempt at the second half. Whether it becomes evidence anyone files depends on a regulator deciding that a receipt counts, and no regulator has.

Sources

  1. Linux Foundation Welcomes TRACE to Advance Verifiable Runtime Evidence for AI Workloads — Linux Foundation, 2026-08-25; contribution, the binding description, the 135,000-download figure, Siddique’s title
  2. TRACE Specification v0.2 — draft spec; abstract, §1 problem table, §3.1 claim table, §3.1.1 origin, Article 12 status and Regulation (EU) 2026/1744 dates, §7 open questions
  3. TRACE Known Limitations — Level 0 scope, policy correctness, model reasoning, PLATFORM_INFO, offline verification and revocation, compliance disclaimer
  4. RFC Proposal: runtime evidence and verifier grades — target v0.3; the four-row table, the authorship sentence, the schema/requirement conflict, the 2026-09-14 capture, the substituted-quote limit
  5. PyPI Download Stats: agentrust-trace — queried 2026-10-31; 162,054 last month, 19,353 last week, package summary string
  6. RFC 9334: Remote ATtestation procedureS (RATS) Architecture — January 2023
  7. RFC 9711: The Entity Attestation Token (EAT) — April 2025
  8. OPAQUE and OPAQUE’s Next Chapter — wind-down notice on the homepage; 2026-10-13 post
  9. Anthropic Acquires Confidential AI Startup Opaque Systems — SecurityWeek, 2026-10-19; Series B terms, customer list, the unanswered question
  10. AAIF project proposal #42: TRACE Specification — opened 2026-09-14, Under Review since 2026-10-02; the 19 integrations and 9 Verified tier; the 2026-10-15 comment
  11. GitHub REST API: repos/agentrust-io/trace-spec — 43 stars, 39 forks, pushed 2026-10-30 (queried 2026-10-31)
  12. NIST SP 800-171A Rev. 3, Assessing Security Requirements for CUI — May 2024; assessment procedures, methods and objects
  13. Federal Register API: documents matching “confidential computing” — count: 0, queried 2026-10-31; same for “TRACE specification”
  14. Introducing the Agent Governance Toolkit — Microsoft Open Source Blog, 2026-04-02, by Imran Siddique
  15. AI agent security with policy-driven access control — Red Hat; the runtime-enforcement quote
  16. Regulation (EU) 2026/1744 (Digital Omnibus on AI) — the deferral the specification’s §1 cites; dates quoted here from that section, not read from EUR-Lex directly