The GenAI Field Guide · Trending
An open specification for a signed record that says which model an AI agent ran, where, under which policy, on what class of data and with which tool calls.
TRACE (Trust, Runtime Attestation and Compliance Evidence) defines a Trust Record: a signed, portable piece of evidence about one agent run that a third party can check later without trusting the operator. The Linux Foundation took on its governance on 25 August 2026; it was contributed by the confidential computing vendor OPAQUE and developed with AMD, Intel, Microsoft and the Technology Innovation Institute. It is a v0.2 developer preview, so it is worth reading now if you have to prove to auditors, customers or regulators how your agents handled sensitive data, but not yet something to build compliance on.
Agent logs and traces today are written by the same operator they are meant to hold to account, so an auditor has to take them on trust. TRACE tries to turn the key facts of a run into evidence that can be checked independently. Its README frames a Trust Record as answering five questions: what model ran (model id and a digest of the weights), where it ran (runtime platform and a measurement), under which policy (a hash of the policy bundle and whether it was enforced or only monitored), what data it touched (a data classification) and which tools it called (a hash of the tool transcript and a call count).
It is mostly a profile of existing standards rather than a new framework. Under the hood it uses the IETF Entity Attestation Token format (RFC 9711) as the claim envelope, the RATS architecture (RFC 9334) for the attester, verifier and relying party roles, and SCITT transparency logs for anchoring, with SPIFFE identities for the agent, SLSA build provenance and EAR appraisal results. The press release and coverage describe the record as hardware enforced and portable across clouds, confidential computing platforms and sovereign infrastructure.
The package is a specification plus a Python reference library, agentrust-trace, a conformance test suite and integration guides for OPAQUE-related tools (an MCP variant called cMCP, a toolkit called AGT and sandboxed runtimes). The spec is under the Community Specification License 1.0 and the code under Apache 2.0. The press release says the library passed about 135,000 PyPI downloads in the ten weeks after it was shown at the Confidential Computing Summit in June 2026; that figure comes from the announcement and we did not check it independently.
A producer, ideally running inside a trusted execution environment (TEE), assembles a JSON record with fields such as subject (a SPIFFE id for the agent), model, runtime, policy, data_class, tool_transcript, build_provenance, appraisal and transparency, plus an issued-at time. The record is canonicalised with JSON Canonicalization Scheme (RFC 8785) and signed, either as a JWT with ES256, ES384 or EdDSA, or as a COSE structure. In the hardware-backed form, the runtime measurement and a platform quote from the TEE tie the signature to attested hardware; in the software-only form it is just a key signature.
The tool transcript is not stored in the record. The record carries a SHA-256 or SHA-384 hash of the full transcript of MCP or A2A calls, a call count and a pointer to where the transcript lives, so a verifier fetches it separately and checks the hash. Calls that cross a protocol boundary are covered; functions embedded inside the agent process are out of scope.
Verification checks the signature, the schema and freshness. By default a record older than 24 hours is rejected and clock skew of 5 minutes is tolerated; a verifier can also issue a nonce that the record must echo, which helps against replay. The appraisal field reports a verifier's result as affirming, warning, contraindicated or none. Each record should point to a SCITT transparency log entry, and revocation of a signing key is ordered by log position rather than by timestamp so a compromised key cannot be used to backdate records.
How strong the evidence is depends on what backs it. The project's limitations document calls the software-only form Level 0 and says a privileged operator can forge a valid-looking Level 0 record for a run that never happened. The project site says a proposed v0.3 runtime evidence profile grades inlined hardware quotes as platform-attested or attested, and that the attested grade is specified but not yet demonstrated. Read signatures as a producer's claim, which is how the site itself puts it.
Anyone can read the spec and run the reference library; there is no account or price. You need Python 3.11 or later (per PyPI). The quickstart produces software-only records signed with a local key, which is enough to learn the format; hardware-backed records need a TEE platform such as Intel TDX, and the site offers a page that checks a real TDX quote.