TRACE Targets the Runtime Evidence Gap in AI Governance
TRACE, contributed to the Linux Foundation by OPAQUE and partners, proposes portable hardware-attested evidence for what AI workloads ran and which policies governed them.
TL;DR
A policy document describes an approved model, classification and owner. TRACE addresses the harder question: what evidence shows that the policy was enforced against a specific workload at a specific moment? The Linux Foundation's announcement of TRACE — Trust, Runtime Attestation and Compliance Evidence, contributed by OPAQUE and developed with AMD, Intel, Microsoft, and the Technology Innovation Institute — is aimed squarely at that second, harder problem.[3] TRACE proposes binding runtime environment, software, policy, data classification, and tool usage into one portable, cryptographically verifiable record.[3] Whether it becomes the standard is an open question. Whether AI governance needs to move from documents to evidence is not. TRACE is an announcement, not yet an interoperable deployment, so the caveats are real: keys, verification, and policy semantics still need to be checked vendor by vendor. The practical move is to start recording runtime, policy, and tool-use evidence for high-risk agent actions now, independent of the standard's timeline, and treat whatever TRACE eventually delivers as a bonus rather than a substitute.
The gap between policy and execution
Ask a typical governance team what model is approved, what data classification applies, and who owns the control, and you will get a confident answer within minutes.[3] Ask which binary actually ran last Tuesday, which policy version was active at that moment, what tools the agent called, and whether the workload stayed inside its intended confidential-computing boundary, and the confidence tends to disappear. TRACE is designed around exactly that missing layer: not "what did we approve" but "what actually happened, and can a third party check that without trusting our word for it."[3] That distinction is the entire point of the specification, and it is worth sitting with, because governance documents alone do not answer the second question.

Why portability is the load-bearing design choice
The announcement positions TRACE as vendor-neutral, and builds it from existing standards rather than inventing a proprietary format from scratch — RATS, EAT, SLSA, SCITT, SPIFFE, and EAR all feed into it.[3] That choice matters more than it looks. A runtime record controlled by one infrastructure vendor is difficult, sometimes impossible, to compare against a workload running somewhere else, and a French or Moroccan company weighing sovereign or multi-cloud deployment cannot build a durable compliance program on evidence that only makes sense inside one platform's dashboard. Evidence that cannot leave the vendor's own environment is closer to a product log than to a compliance artifact anyone else can rely on. Portability is not a nice extra feature here. It is the difference between a record and a receipt nobody else can read.
A useful record is more than an attestation quote
A runtime record worth trusting has to answer four separate questions: what ran, where it ran, which policies were actually enforced, and what data or tools were involved along the way.[3] Hardware attestation can strengthen the "where" and "what ran" claims considerably — that is what the underlying standards are largely built for. But the surrounding metadata still needs an owner, a retention policy, accurate time synchronization, a key rotation schedule, and a verifier that will actually reject stale or incomplete evidence rather than waving it through because rejecting things is inconvenient.
I would not treat an attestation receipt as a magic compliance token that closes the conversation on its own. It is one component in a chain, and a chain is only as strong as the parts nobody bothered to specify.
Why the Linux Foundation's governance choice matters more than the launch itself
The Linux Foundation says TRACE will receive vendor-neutral governance, with the technical workstream hosted by the Coalition for Secure AI.[3] That structural detail may end up mattering more than the announcement it arrived alongside. A runtime evidence format only becomes useful once it has competing implementers who are incentivized to keep each other honest, independent verification tools that do not belong to any one vendor, versioned schemas that do not break every six months, and a clear process for deciding which fields are mandatory versus optional. Skip that governance layer and the likely outcome is not one standard — it is five clouds each producing their own "trusted AI" export that looks similar enough to pass a slide deck and different enough to fail an actual audit.
The founding contributor list is worth reading carefully for the same reason. The announcement brings together AMD, Intel and Microsoft alongside the Technology Innovation Institute, and the Technology Innovation Institute's presence signals interest well beyond the usual US hyperscaler axis.[3] That spread is a reasonable early sign that TRACE is not being positioned as one vendor's attestation format with a neutral-sounding name attached. It is not proof of anything yet — contributor lists change, and early enthusiasm is cheap compared to shipping interoperable verifiers — but it is a more credible starting point than a single-vendor initiative would be, and it is worth checking again in a year to see whether the list grew or quietly shrank.

A practical adoption path that does not wait for the standard to mature
Nothing here requires waiting for TRACE to stabilize before improving your own evidence hygiene. Start by recording, for each high-risk agent action, the model and artifact digest, the runtime identity, the policy version in force, the tool calls made, the data classification touched, the approval decision, and the outcome.[3] Store that record separately from the agent's conversational transcript, because a transcript is optimized for a human to read later, not for a verifier to check automatically. Then run the actual test that matters: can an independent party verify the chain without simply trusting the agent, or the team, that produced it in the first place?
A smaller-scale implementation can apply the same separation: keep the script executed, policy file read and resulting disk changes in an action record separate from the conversation. TRACE pushes that instinct to a hardware-attested, cross-vendor scale, which is a considerably harder problem, but not a different one.
This is aligned with Netics' zero-trust agent boundary: signed writes and deterministic gates already produce useful evidence today, well before any future standard gets around to packaging it.
The limits and the open questions worth asking a vendor
TRACE is an open specification announced on 25 August 2026. That is not proof that every implementation already interoperates, and the announcement does not claim otherwise.[3] Before anyone treats it as settled, ask how keys are provisioned and rotated, how confidential-computing claims are actually verified rather than merely asserted, how policy semantics are represented so "compliant" means the same thing across two different implementations, and how long evidence remains valid once the underlying software has moved on. Also worth separating clearly: evidence that a control was configured is not the same thing as evidence that the control actually blocked an action when it mattered. Vendors will happily supply the first. The second is the one worth insisting on.
None of this is a reason to wait. A specification with real hardware vendors attached and an open governance home is a meaningfully better starting position than the alternative most teams currently have, which may leave teams with fragmented vocabulary and provider-specific records. The right posture is engaged skepticism: track TRACE, ask the interoperability questions above of any vendor who claims support for it, and keep building the narrow evidence chain your own agents need regardless of how the standard evolves.

Where this leaves governance teams before the standard matures
TRACE is a credible direction precisely because it focuses on runtime evidence rather than adding another policy checklist to a stack that already has too many. It will earn trust only if independent parties, not just the founding contributors, can verify records across different clouds, hardware vendors, and agent frameworks without special access. Until that independent verification actually exists in practice, the responsible move is to build your own narrow evidence chain for the handful of agent actions that would actually hurt if they went wrong, and treat everything TRACE eventually standardizes as a bonus rather than a substitute. Netics can help turn agent governance requirements into an operational control map.
Sources
[3] https://www.prnewswire.com/news-releases/linux-foundation-welcomes-trace-to-advance-verifiable-runtime-evidence-for-ai-workloads-302858923.html — Linux Foundation welcomes TRACE
Source: Linux Foundation announcement — 2026-08-25. Netics analysis.