Technical report / Version 3
TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)
OPAQUE Systems
Abstract
TRACE (Trust, Runtime Attestation, and Compliance Evidence) proposes a portable record for claims about AI agent runtimes: workload identity, model, policy, data class, tool transcript, build provenance, and appraisal. It composes RATS/EAT, signatures, and transparency evidence into a format that a relying party can evaluate against its own trust policy. A valid signature establishes integrity and possession of the signing key; hardware origin additionally requires verified attestation and a binding from that evidence to the key. This technical report describes the original design and preserves the recorded software evaluation of agentrust-trace (trace-spec revision 523f8cc, whose signing code is release 0.3.0) and trace-tests 0.2.0. The evaluation measures canonicalization, Ed25519 signing and verification, record size, and fixture outcomes. It does not measure silicon certificate-chain appraisal or establish that the recorded runtime claims are true. The current normative specification and its implementation limits are maintained separately.
What this report contributes
A portable format for runtime claims, with recorded measurements of signing, verification, record size, and conformance fixtures.
Evidence and limits
- The recorded run of July 1, 2026 measured trace-spec revision 523f8cc, whose signing code is release 0.3.0, and trace-tests 0.2.0. It did not measure silicon certificate-chain appraisal.
- The missing-runtime fixture passes at Level 0 in the saved results. The cMCP fixture fails at all three levels. Those outcomes limit what the historical conformance checks establish.
- The evaluated checker canonicalized with sorted JSON rather than RFC 8785, so a record with a non-ASCII subject that the SDK signs and verifies fails its signature check.
- A signature proves integrity and signing-key possession. Hardware origin requires verified attestation and key binding; inclusion in a log does not prove that every event was recorded.
The source package preserves the recorded inputs and results. The benchmark was rerun at the identified revisions and at current main on October 1, 2026; the report keeps the original numbers. No independent replication is claimed.
Read the current specification and implementation guidance. This report describes an earlier design and evaluation; the current specification governs implementation.
Cite this report
Rishabh Poddar; Aaron Fulkerson; Imran Siddique. TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance). AgenTrust technical report, version 3, 2026.
Download BibTeX / Download CITATION.cff
@techreport{agentrust2026trace,
title = {TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)},
author = {Rishabh Poddar and Aaron Fulkerson and Imran Siddique},
institution = {AgenTrust},
year = {2026},
type = {Technical report},
note = {Version 3; not peer reviewed},
doi = {10.5281/zenodo.23091275},
url = {https://agentrust-io.com/research/trace/v3/}
}
Version history
Version 3, October 1, 2026: Corrects the identification of the evaluated SDK and five bibliography entries, narrows the conformance-module descriptions, states that the evaluated vectors use the v0.1 profile URI, fixes the install command and restores bold and italic type. Results unchanged.
Version 2, September 28, 2026: Corrects the related-work statement that transparency-log registration makes omitted events detectable, which contradicted the conclusion, and removes three en dashes. Results unchanged.
Version 1, September 27, 2026: Clarifies the signature and hardware-evidence boundary, corrects the description of saved conformance outcomes, and preserves the historical measurements.
Based on a manuscript originally dated June 23, 2026, with later recorded experiments. That manuscript date is not presented as a verified publication date.
File checksums. Published version files are retained; substantive revisions receive a new version.
Questions and corrections
Open an issue in the project repository and identify the report version and section.