The Sandbox Failed. TRACE Tries to Prove What the Agent Actually Did.

This is the natural follow-up to BlackTree’s earlier analysis, When AI Agents Leave the Sandbox. That article examined the weakness of treating the sandbox as the complete security boundary. TRACE starts from the next problem: if the boundary fails, drifts or becomes disputed, what trustworthy record survives?

TRACE is an evidence format, not another sandbox

TRACE stands for Trust, Runtime Attestation and Compliance Evidence. It defines a signed governance record for AI agents and confidential workloads. The record is intended to bind together the runtime environment, model and software identity, policy, data classification and tool activity.

The Linux Foundation announced on 25 August that TRACE had been contributed by OPAQUE and would move under vendor-neutral governance. AMD, Intel, Microsoft, OPAQUE and the Technology Innovation Institute are named as collaborators. The technical workstream will be hosted by the Coalition for Secure AI.

The key distinction is easy to lose in the announcement language. TRACE does not stop an agent from escaping a sandbox. It does not decide whether an action was safe. It creates a cryptographically verifiable claim about the environment and evidence associated with an execution.

What a TRACE Trust Record is meant to answer

The current version, TRACE v0.2, defines claims that can answer a set of operational questions:

• What model and software ran, represented by identifiers and cryptographic digests?
• Where did the workload run, including the hardware platform and runtime measurement?
• Which policy bundle was in force, and what enforcement mode was declared?
• What classification of data did the workload touch?
• Which tools were called, represented through a transcript hash and call count?
• Was the record anchored to an independent transparency service?

The result is intended to travel with a workload across cloud and confidential-computing environments. A relying party can verify the signed record without calling the operator’s proprietary API or accepting a dashboard screenshot as proof.

Hardware roots the claim, but verification remains a chain

TRACE’s stronger trust levels use a signing key generated inside a trusted execution environment and bind that key to a measured runtime. Supported profiles include confidential-computing technologies such as AMD SEV-SNP and Intel TDX.

Hardware attestation is an important root, but it is not a magic verdict. The TRACE documentation is explicit that checking a runtime measurement against a platform’s attestation chain is a separate step that requires platform-specific verification. A signed field is useful only when the verifier can establish who signed it, how the key was protected and whether the measured state was approved.

This creates a chain of questions rather than one universal green check. Was the hardware genuine? Was the verifier trusted? Did the measurement correspond to an approved build? Was the policy hash mapped to the policy the organisation intended to enforce? Was the evidence fresh and anchored?

The project composes existing standards

TRACE is not proposing a completely new security stack. It draws on Remote Attestation Procedures Architecture, Entity Attestation Tokens, Supply-chain Levels for Software Artifacts, Supply Chain Integrity, Transparency and Trust, SPIFFE workload identity and Entity Attestation Result concepts.

That composition is strategically important. Enterprises are already accumulating separate attestations for builds, workloads, identities and confidential-computing platforms. TRACE tries to connect those pieces to an AI-agent execution record instead of creating another isolated vendor format.

The limits matter as much as the claims

TRACE is currently a developer preview, and its own project page tells implementers to read the limitations before relying on it in production. Version 0.2 is not a finalised universal assurance standard.

A valid Trust Record cannot prove that:

• the agent’s decision was correct, ethical or aligned with business intent;
• the declared policy was adequate for the risk;
• every relevant action was captured if the instrumentation boundary was incomplete;
• a physical-world task was completed safely;
• the workload contained no software vulnerability or side-channel exposure;
• the sandbox held, because attestation and containment solve different problems.

The record can prove that a particular set of signed claims verifies under a particular trust chain. It cannot convert incomplete telemetry into complete truth. That limitation is central to any BlackTree reading of the announcement.

Why the Linux Foundation move matters

Runtime evidence only becomes useful across organisations when both sides agree on the format and verification rules. A cloud provider can issue its own attestation today, but customers, auditors and regulators still need a portable way to compare claims across silicon vendors and deployment environments.

Linux Foundation governance gives TRACE a neutral venue for that interoperability work. The project says it recorded nearly 135,000 Python Package Index downloads in the ten weeks after its June introduction. Download counts are not the same as production deployments, but they do suggest meaningful early experimentation.

The open specification, schema, examples, reference implementation and conformance test suite are already available. The test suite covers envelope structure, signatures, trusted-execution-environment claims, policy binding, tool-call transcripts, transparency anchoring and supply-chain provenance.

What security teams should do with TRACE now

• Treat TRACE as an architecture and evidence-model input, not a production control that can replace sandboxing, least privilege or runtime enforcement.
• Map the Trust Record fields to existing incident-response, audit and AI-governance evidence requirements.
• Test whether model identity, policy hashes, data classifications and tool-call evidence can be produced consistently in a real agent workflow.
• Define who will verify each claim and which endorsement sources are acceptable.
• Threat-model the evidence pipeline itself, including signing keys, verifiers, transparency anchoring and gaps between the agent and the capture boundary.
• Keep containment and attestation separate in control assessments. One limits action; the other supports later proof.
• Follow the specification and conformance suite as they mature beyond the developer preview.

The strategic shift is from trust to evidence

The broader significance is not that TRACE solves agent security. It is that the industry is beginning to acknowledge that “the agent ran in our sandbox” is not sufficient assurance for high-impact workloads.

Organisations will need evidence that survives provider boundaries, infrastructure changes and post-incident disputes. If TRACE succeeds, the question will move from whether an operator says a policy was enforced to whether a third party can verify the runtime, policy and action record independently.

That is the right sequel to sandbox security. Prevention still matters. When prevention fails, evidence determines whether anyone can reconstruct the truth.

Sources

• Linux Foundation announcement, published 25 August 2026 at 13:00:02; the page does not state a timezone.
• TRACE specification repository, current developer preview v0.2, accessed 26 August 2026.
• TRACE conformance test suite, current v0.2, accessed 26 August 2026.
• SecurityWeek independent reporting, published 25 August 2026 at 12:23 ET, 18:23 CEST.