Introducing TRACE, an open specification for hardware-attested AI agent governance records, built on IETF RATS, EAT, SCITT, and SLSA.
Every regulated AI deployment hits the same wall.
The security or compliance review asks: how do you prove the agent handled our data according to policy? And the answer comes back in the form of documentation. Policy documents. SOC reports. Vendor self-attestation. Mutable application logs.
None of that proves what actually happened during execution. None of it is verifiable by the relying party without trusting the operator who produced it. So review cycles that should take days stretch into months, and the deployment sits waiting for sign-off on evidence that was never designed to provide it.
TRACE is the missing piece. It launched publicly on June 23 at the Confidential Computing Summit, and the specification and reference implementation are available now.
What Auditors Are Actually Asking
When a bank’s internal risk team, an external auditor, or a customer CISO asks “how do you prove the agent handled our data according to policy,” they are asking three specific questions:
What actually ran? Not what was deployed. Not what the manifest says. What was loaded into memory and executed at the moment the customer’s data was processed: model weights, agent code, dependency tree, runtime image, and policy bundle, bound together cryptographically and verifiable by an outside party.
What did it actually do? Which tools the agent called. With what parameters. Against what data class. In what sequence. Across how many agent hops. Software-layer telemetry is self-reported and mutable. It can be reconstructed after the fact by anyone who holds the signing key.
What rules were actually in force? Not the policy on the document. The policy bundle hash bound to the workload at execution time, with the enforcement mode it ran under, verifiable independently of the workload that ran it.
TRACE is an open specification for a Trust Record: a signed, hardware-attested artifact that answers all three questions in a form any third party can verify offline without trusting the operator.
The Evidence Gap
Here is the state of the art before TRACE:
Every regulated AI deployment re-litigates trust at every host boundary. Each cloud, each model provider, each agent framework ships its own evidence shape. Auditors cannot compare. Verifiers cannot federate. Workloads cannot move.
The EU AI Act mandates tamper-evident logging for high-risk AI (Article 12). DORA for financial entities and HIPAA for healthcare carry equivalent audit-trail requirements today. Autonomous agents inside critical infrastructure are landing before the standard exists to govern them.
The Trust Record
A TRACE Trust Record is the unit of evidence. It answers all three auditor questions in a single signed artifact.
Each field is independently verifiable. The claims map directly to the three auditor questions:
- model + runtime + build_provenance answer what ran
- tool_transcript answers what it did
- policy + data_class answer what rules were in force
The cnf (confirmation) key is the TEE-bound signing key. It never left the enclave. The transparency URI resolves to an SCITT receipt proving the record was submitted to an append-only log before the verifier ever saw it. The runtime.measurement is the hardware attestation measurement chain, verifiable against the vendor’s Reference Integrity Manifests (RIMs).
What TRACE Is Built On
TRACE is a profile, not a parallel stack. It binds existing IETF and industry primitives into one coherent artifact.
RATS / EAT (RFC 9711): the wire envelope and claim model. NVIDIA NRAS, Intel Trust Authority, and Azure MAA all produce attestation tokens that map into this envelope.
SLSA Provenance v1.0: build-time provenance. Build Level 2 is the minimum for v0.1-conformant records, and Level 3 is the target for production reference implementations.
SPIFFE / SPIRE: workload identity. The SVID is bound to the TEE measurement, so identity is rooted in hardware, not in software keys the operator controls.
SCITT: the append-only transparency log. TRACE defines a SCITT profile for Trust Record inclusion, covering Signed Statement registration, Receipt format, and key rotation semantics. Once a record is in the log, neither the issuer nor the operator can delete or modify it.
EAR (draft-ietf-rats-ar4si): verifier output format. The appraisal field separates what was claimed from what was accepted by an independent verifier. A “null verifier” that accepts everything is structurally different from an “affirming” verifier that checked the RIMs.
MCP / A2A: the agent execution surface. TRACE adds cryptographic binding of the transcript hash into the EAT envelope and per-call data_class classification.
The Threat Model
TRACE is sound only against named adversaries under named assumptions.
In scope:
- An agent itself, acting under autonomy, prompt injection, goal hijack, or alignment drift. TRACE makes misbehavior crossing a protocol boundary visible at the moment it happens.
- A cloud or infrastructure operator with root access. This adversary cannot forge a TRACE record for a run that violated policy, because the signing key never left the TEE.
- A compromised orchestration layer (kubelet, container runtime). This adversary cannot substitute the workload without invalidating the hardware measurement.
- A compromised dependency. This is caught by build_provenance at SLSA Level 2+.
Permanently out of scope:
- TEE side-channel attacks (cache, timing, speculative execution)
- Compromise of the silicon root vendor or transparency log operator
- Model behavior inside the TEE, including prompt injection, hallucination, and alignment drift. TRACE proves what ran and which countermeasures were in force. It does not adjudicate whether the model’s output was correct.
This scope boundary matters. TRACE is not a magic seal. It is a hardware-rooted evidence layer. A bad model that runs under a valid TRACE record still produces bad output. What TRACE gives you is the proof of which policy was enforced and which tools were called, which is what regulators and auditors actually need.
Hardware Roots
TRACE supports all major TEE platforms:
The key hierarchy is: silicon root key (vendor-managed, hardware-bound) → platform attestation key → workload attestation key (TEE-bound, ephemeral) → record signing key. The record signing key is what appears in cnf. It is the only key that touches the record, and it never leaves the enclave.
Generating a Trust Record
The record is a JWT with the EAT profile URI tag:agentrust.io,2026:trace-v0.1. In constrained environments (high-throughput inference, edge deployments), TRACE also supports CBOR-COSE encoding.
Verifying a Trust Record
Verification does not require calling back to the issuer. The verifier checks:
- Signature binding. Verifies against the key in cnf. A record with no verifiable binding is rejected.
- Freshness. iat is within the maximum record age (default 24 hours). Challenge nonces are checked when issued.
- Hardware root. The signature chain resolves to a known silicon root (NVIDIA, Intel, AMD, or cloud equivalent).
- Measurement integrity. Runtime measurements match published Reference Integrity Manifests.
- Policy hash. Matches the policy bundle the verifier expects.
- SCITT receipt. Resolves on the named transparency log.
- SLSA provenance. Resolves to a trusted builder.
No vendor in the trust path beyond the silicon root and the transparency log operators.
Standards Alignment
TRACE is on the standardization track at:
- CoSAI WS4 (OASIS Coalition for Secure AI): active track
- AAIF (Agentic AI Foundation, Linux Foundation): targeting submission alongside Agent Manifest
- RATS WG (IETF): built on RFC 9711 (EAT) and RFC 9334 (RATS). Vendor profile annexes co-authored with NVIDIA, Intel, AMD, Microsoft, and Google are planned for v1.0.
The reference implementation is Confidential MCP (cMCP), which produces TRACE Trust Records as its primary output on every session.
Why This Matters Now
The EU AI Act Article 12 requires tamper-evident logging for high-risk AI systems. The provisional compliance timeline lands around December 2027. That sounds distant. The problem is that regulated organizations deploying AI agents today are building the audit infrastructure now, and the decisions made in the next twelve months about what evidence to collect and how to structure it will determine whether the 2027 deadline is a paperwork exercise or a genuine compliance posture.
TRACE gives the industry a shared, open, standards-aligned format for that evidence. Not a vendor lock-in, not a proprietary format, not documentation. Cryptographic proof, rooted in silicon, verifiable offline by anyone.
Get Started
Specification: trace.agentrust-io.com GitHub: github.com/agentrust-io/trace-spec Schema: schema/trace-claim.json Discord: discord.gg/grgzFEHgkj
Originally published at https://www.linkedin.com.
Top comments (0)