In the previous article, I argued that autonomous systems need portable cryptographic receipts: evidence that a deterministic enforcement point evaluated consequential actions against a boundary that someone approved.
But having a receipt raises another question: what exactly does it prove?
As AI agents begin taking actions across different systems, proving that an action was authorized or compliant becomes more complicated. An agent might run in one cloud, access confidential data in another environment, call third-party tools, and ultimately trigger an action in a bank, healthcare system, or other sensitive infrastructure.
No single assurance mechanism answers every question about that chain.
A zero-knowledge proof can establish that an identified computation evaluated committed inputs correctly, without revealing the private data behind the computation. It does not establish where those inputs came from. Hardware attestation can establish that a measured workload ran inside a protected environment. It does not establish that the policy implemented by that workload was correct. A transparency system can preserve evidence and make tampering detectable. It does not strengthen the underlying claim contained in that evidence.
What we need is a way to describe these different guarantees clearly—and combine them without treating them as interchangeable. That is the problem TRACE is beginning to address.
What is TRACE?
TRACE stands for Trust, Runtime Attestation and Compliance Evidence. It is an open specification for portable runtime and compliance evidence for AI agents and confidential workloads.
In August, the Linux Foundation announced the contribution of TRACE. OPAQUE contributed TRACE, which it developed collaboratively with AMD, Intel, Microsoft, and the Technology Innovation Institute. The Linux Foundation now provides a vendor-neutral home for its governance.
A TRACE Trust Record can bind claims about the workload, runtime environment, governing policy, data classification, build provenance and tool activity into one signed artifact. At its hardware-attested levels, the record can also carry evidence rooted in the hardware platform.
TRACE builds on existing standards for attestation, identity, software provenance and transparency. Its current version, TRACE v0.2, is a Developer Preview with evolving format and conformance rules.
At o1Labs, we have been exploring how zero-knowledge proofs can become one part of this broader assurance stack. As part of that work, I authored an RFC proposing composable zero-knowledge assurance in TRACE. The proposal has now been merged into the TRACE documentation as an informative RFC.
The goal is not to position ZK as a replacement for hardware attestation or other assurance mechanisms. It is to define how different forms of evidence can work together while keeping the guarantees and limitations of each explicit.
Why verifiable AI execution needs shared evidence
Consider that AI agent that runs in one cloud, calls tools hosted by other companies, accesses confidential information, and sends a request to a bank or healthcare system.
Every participant in that chain may need to answer questions such as:
- Which workload produced the record and which policy governed it?
- Which inputs, session and action does it cover?
- Which claims does the verified evidence support?
A proprietary receipt can be cryptographically valid and still be difficult to use elsewhere. Vendors may use different identifiers, signing rules and verification semantics. A shared specification gives these records a common structure and meaning. Each verifier can then apply its own trusted keys, hardware roots, appraisal policy and evidence requirements.
The harder problem is that assurance itself has multiple dimensions.
What does “assurance” actually mean?
Here, assurance means the evidence that a verifier has for a particular claim.
An organization evaluating an agent may need answers to several different questions:
These properties rely on different mechanisms and different trust assumptions. A single trust score loses those differences. Instead, a verifier should understand exactly which evidence supports which claim.
Zero-knowledge proofs vs. trusted execution environments
Two mechanisms that can play complementary roles are zero-knowledge proofs (ZK proofs) and trusted execution environments (TEEs).
A TEE is a hardware-backed isolated execution environment. It can protect runtime secrets, bind credentials to a measured workload and provide evidence about where code ran. Its guarantees depend on factors including the hardware platform, attestation chain, workload measurement and deployment.
A zero-knowledge proof provides a different type of assurance. It allows a verifier to check a defined statement without learning the private witness beyond what the statement itself reveals.
In the context of the TRACE RFC, that statement can concern whether an identified computation evaluated committed inputs and produced a bound result. Its guarantees depend on the soundness of the proof system, correct verification, correct identification of the program and correct binding between the proof and its inputs.
These mechanisms therefore answer different questions.
A TEE can provide runtime integrity and confidentiality.
A ZK proof can provide computation assurance and privacy-preserving verification.
A system can use either independently, or combine them when both sets of properties are required.
Moving from assurance levels to composable assurance
TRACE v0.2 currently represents assurance mainly through runtime-oriented levels: software-signed evidence, TEE-attested evidence and TEE-attested evidence anchored through SCITT. That structure cannot naturally express a software runtime that also carries an independently verified ZK computation proof.
Our RFC proposes a non-linear, composable assurance model instead.
Rather than assuming that one mechanism represents a higher or lower overall level of trust, a deployment selects the mechanisms needed to support its particular claims.
ZK can supply computation assurance, while a TEE can supply runtime integrity and confidentiality assurance subject to each mechanisms assumptions. A deployment can use them independently or combine them when it needs both sets of properties. Transparency evidence can compose with either approach.
This matters because adding more evidence does not automatically create a stronger claim. The verifier needs to know both what evidence exists and what that evidence actually establishes.
Our merged RFC therefore separates three stages that are easy to conflate:
- Evidence presence: A record contains or references an assurance artifact.
- Evidence verification: A verifier successfully checks that artifact under a defined policy and context.
- Claim support: The verified artifact is cryptographically and semantically bound to the exact claim being evaluated.
The presence of a proof artifact establishes very little by itself! The verifier must check it and establish that it refers to the relevant program, policy, inputs and result.
If a deployment requires both TEE evidence and a ZK proof both checks must succeed. If its verification policy permits either mechanism to support the particular claim being evaluated, one successful check can be sufficient. Those AND and OR rules must be explicit.
What composable assurance looks like in practice
Consider an AI agent that prepares and submits payments under two rules:
- Every payment must remain below USD 10,000.
- The agent may use only approved tools.
The organization wants to enforce those rules without exposing every payment amount or the agent's complete execution transcript to an external verifier.
One possible composition works like this:
- A TEE-backed tool gateway records the agent actions that cross its instrumented boundary and protects the credentials used to access the payment system.
- The gateway creates and signs a commitment to the execution transcript. A commitment is a cryptographic value that binds its creator to specific data without publishing that data.
- A ZK program receives the transcript as private input. It checks that the transcript opens the TEE-authenticated commitment and that every payment recorded in the transcript satisfies the approved policy.
- An external gateway verifies the proof, its connection to the current request and freshness data such as a nonce or expiry time.
- The gateway submits the payment only when every required check succeeds.
The external verifier can now confirm that every payment recorded in the committed transcript remained below USD 10,000 and used only approved tools. It does not need to receive the payment amounts, complete transcript or sensitive tool responses.
Each mechanism contributes something different. The TEE authenticates and protects the runtime boundary. The signed commitment binds the evidence to that execution. The ZK proof establishes the policy claim without revealing the underlying private data.
A future TRACE ZK profile could carry this composition as portable evidence, while a transparency mechanism could make later removal, replacement or rewriting of the issued evidence detectable.
From verification to proof-gated execution
Verification becomes particularly useful when it is part of the authorization path itself.
In the payment example, the external gateway does not need to run inside the TEE. Instead, it checks that the proof is bound to the intended action or audience, authorization scope, destination, relevant session or state, and freshness. Missing, invalid, stale or unsupported proofs cause the gateway to reject the action.
This creates a proof-gated action: the evidence is not merely an audit artifact generated after the fact. It becomes a requirement for execution. This distinction matters for AI agents and other autonomous systems. If cryptographic evidence is going to constrain consequential actions, the system must enforce the rule at a boundary the agent cannot bypass.
The guarantee therefore depends on coverage. Every authorized path to the payment system must pass through the proof-verifying gateway. If another path bypasses it, activity on that path falls outside the proven boundary.
The binding problem: proving the evidence belongs together
Composable assurance introduces another important challenge: two individually valid pieces of evidence do not necessarily describe the same execution.
Imagine that an attacker obtains a valid ZK proof from a compliant payment session and attaches it to a valid TRACE record from another session.
The TRACE record could pass verification. The ZK proof could also pass verification. But together, they would support no useful claim because they describe different events.
Verifying the artifacts independently is therefore not enough. They need to prove something about the same execution. The RFC addresses this through same-value binding. The proof's public inputs and commitments must bind to the corresponding TRACE claims relevant to the proven statement. Depending on the composition, those values can include the program, policy, inputs and result.
What zero-knowledge proofs do not prove
A ZK proof establishes only the statement encoded in its program. Separate evidence is required for several other claims.
- Input authenticity: A proof over an exchange rate or tool response does not establish that the value came from the claimed source. That link requires signed receipts or an authenticated transcript.
- Runtime protection: A ZK proof does not protect credentials or private state from the host. A TEE or another isolation mechanism must provide that property.
- External effects: A proof that an agent produced an approved request does not establish that a bank executed the payment or that a physical event occurred.
- Coverage: A proof says nothing about actions that can bypass the measured or proof-gated path.
- Policy quality: A valid proof can show that committed inputs satisfy an encoded policy or that an identified program evaluated that policy as specified. It cannot show that the policy was sensible, complete or aligned with the organization's intent.
- Model correctness: Neither a policy proof nor TEE attestation establishes that an AI generated answer was factually correct or that the model made a good judgment.
These are not edge cases. These limits are part of the security model and a useful trust record makes them visible instead of hiding them behind one badge or score.
What comes next for ZK and TRACE?
The merged RFC proposes an assurance model, but it does not change TRACE v0.2 conformance.
TRACE v0.2 currently has no normative representation for ZK evidence. Its schema is closed, so a conforming v0.2 verifier should reject an unknown ZK evidence field instead of silently ignoring it.
Follow-up work includes a signed ZK evidence structure, a new Entity Attestation Token profile, proof-system identifiers, binding rules, verifier behavior, conformance tests and reference implementations.
The RFC is deliberately proof-system neutral. A deployment can select a system that fits its performance, setup, privacy and verification requirements best. It must declare the assumptions and identifiers that another verifier needs.
Toward composable assurance for AI agents
As AI systems move from generating information to taking consequential actions, simply knowing that some cryptographic evidence exists will not be enough.
We need to know what was verified, what evidence supports the claim, where that evidence came from and where its guarantees end.
Zero-knowledge proofs can be an important part of that stack, particularly when organizations need to verify policy compliance or computation without exposing sensitive underlying data. Trusted execution environments can provide complementary guarantees about the runtime in which those systems operate. Authenticated data can establish provenance. Transparency mechanisms can help preserve the resulting evidence.
The important step is making those guarantees composable without collapsing them into a generic notion of “trust.”
That is the direction behind this RFC: moving from isolated proofs and attestations toward portable, explicit and composable assurance for systems that increasingly act on our behalf.