AI 安全與標準
TRACE Joins the Linux Foundation: Using Hardware Attestation to Prove Where an Agent Runs, but Not That Its Behavior Is Correct
The Linux Foundation has accepted the TRACE specification, which creates portable cryptographic evidence for AI agents’ models, execution environments, policies, and tool calls. The current v0.2 remains a Developer Preview: it can prove that records are linked to an attested environment, but not that an agent completed its task or that the policy itself is secure.
After first being made public in June, TRACE (Trust, Runtime Attestation and Compliance Evidence) officially moved under the Linux Foundation’s stewardship on August 25, with technical work to be incorporated into the Coalition for Secure AI. The point of this change is not to introduce another agent permission system, but to provide a common “evidence format” across clouds, trusted execution environments, and governance products.
A Trust Record can capture a model identifier and weights digest, workload identity, hardware measurements, policy bundle hash, data classification, tool-call counts, and a summary of execution traces. Records use the EAT/RATS roles and claims model, are packaged as JWT or CWT/COSE, and can receive receipts through a SCITT transparency ledger; workload identity can use SPIFFE. Verifiers can therefore check signatures, policy versions, and execution environments offline without having to directly trust the cloud operator that generated the record.
For engineering teams, TRACE is most valuable for cross-provider auditing: even when the same agent moves between AMD SEV-SNP, Intel TDX, or other attested environments, it can still produce governance records with a consistent structure. The specification also includes a Python SDK, JSON Schema, test suite, and reference implementation, lowering the barrier to integration.
However, TRACE v0.2 is explicitly labeled a Developer Preview. Hardware attestation can only link a signing key, a measured environment, and the contents of the claims; it cannot guarantee that policy rules are sound, that tool outputs are truthful, that an agent completed a physical action, or that the trusted execution environment itself is free of vulnerabilities. Engineers should next watch whether fields and platform identifiers stabilize, whether SCITT anchoring services are genuinely interoperable, and whether records generated by different runtimes can pass the same compliance test suite.