RFC Proposal: Composable Zero-Knowledge Proofs for TRACE

[Trivo25]

Spec section affected

§2.3 Trusted Computing Base, §3.3 Verification, §4 Standards Composition (§4.1–§4.3)

This proposal is initially provided as an informative RFC rather than a direct modification of the normative TRACE wire format.

Problem

TRACE currently centers execution assurance around TEE-backed attestation. This provides strong guarantees about the measured runtime, execution boundary, host confidentiality and protected credentials.

However, TRACE does not currently describe zero-knowledge proofs as an alternative or complementary assurance mechanism.

ZK and TEEs establish different properties:

• A TEE can establish properties about the measured runtime and execution boundary.
• A ZK proof can establish properties about a defined computation, including computation over committed or private inputs.
• ZK can also provide privacy-preserving verification, where a verifier confirms a claim without receiving the complete underlying transcript or sensitive values.
• The two mechanisms can be composed when both runtime assurance and independently verifiable computation are required.

Treating these mechanisms as a single linear trust hierarchy would therefore be misleading. Implementations can require different combinations depending on their threat model, privacy requirements, and deployment constraints.

Proposed change

Introduce a proof-system-neutral, composable assurance model for TRACE.

Under this model, ZK and TEE are peer assurance mechanisms rather than levels above or below each other. An implementation can select and combine mechanisms according to the properties it requires.

Example assurance profiles include:

• TRACE + ZK
• TRACE + TEE
• TRACE + TEE + ZK
• TRACE + TEE + SCITT
• TRACE + TEE + ZK + SCITT

The proposed RFC defines the relevant assurance dimensions, including:

• computation integrity;
• runtime integrity and confidentiality;
• input authenticity;
• proof-gated downstream actions;
• external verification and evidence durability;
• privacy-preserving verification.

For example, a ZK proof can be verified by an external gateway before it permits a downstream action, without requiring the verifier or gate to execute inside the TEE.

ZK can also operate over evidence authenticated by a TEE. A TEE can commit to an execution transcript, while a ZK proof can establish selected policy claims over that commitment without disclosing the complete transcript.

The RFC does not require a specific ZK proof system. Selection of the proving system remains an implementation detail.

This RFC defines the assurance model and trust assumptions first. Exact wire-format fields, proof-system identifiers, verification rules, and conformance requirements can be proposed separately after the model is agreed.

Backward compatibility

• Non-breaking (new optional field, informative addition)
• Breaking (removes or changes required field, changes wire format, changes algorithm set)

The proposed RFC does not redefine existing TRACE Trust Records, TEE verification, or existing conformance requirements. Existing implementations can continue to operate unchanged.

Any future normative ZK evidence fields or verification requirements should be proposed separately and evaluated for compatibility at that point.

Motivation

TRACE aims to provide portable, independently verifiable evidence about governed agent execution.

TEE attestation is one mechanism for establishing this evidence, but some deployments may require different trust assumptions or may not have access to suitable trusted hardware. ZK provides a hardware-independent mechanism for proving properties of a defined computation.

ZK also adds a privacy-preserving mode when combined with authenticated TRACE evidence: a verifier can validate selected claims about an execution or external receipt without receiving all of the underlying data.

Supporting these mechanisms as composable assurance options gives TRACE a broader model that can accommodate different security, privacy, verification, and deployment requirements without weakening the existing TEE-based profile.

Related issues or PRs

Detailed RFC: #162

[lywinged]

I read the RFC in full and I think the model is right — TEE and ZK answer different questions, so a single ladder cannot order them. Two notes, both from running it rather than reading it, and one of them is a moving target that changed under you.

The compatibility claim stopped being true yesterday. The RFC says it introduces no schema change and that a verifier without ZK support "should continue to evaluate the existing TRACE evidence". #156 landed schema enforcement inside verify_record a few hours ago, and the record schema is additionalProperties: false with no extension point anywhere in it. Same signed record, two trees:

576507b (before #156)   accepted   - an additive path existed
dd1b6e6 (after #156)    ValueError: record does not conform to the TRACE v0.2
                        schema at <record>: Additional properties are not
                        allowed ('zk_assurance' was unexpected)

So there is no additive path today, and no graceful degradation: a verifier that does not understand ZK does not ignore the block, it rejects the whole record.

The good news is that the repo already has the pattern this needs, and it works. delegation and tool_transcript are optional named members added to the schema in v0.2 (#107). I tried the same shape for ZK evidence — zk_assurance as an optional named member with proof_system, program_id, input_commitment, proof — and the result is what you would want:

existing suite                345 passed
record without the block      verifies
record with the block         verifies
malformed program_id          rejected (fails closed)
tampered zk block             rejected - the signature already covers it

That last line is the argument for a named member over a generic extension bag: because the signature is computed over the JCS form of the whole record minus signature, anything inside the schema is integrity-protected for free. Evidence carried outside it would not be.

One implementation note if you take that route: schema/trace-claim.json and src/agentrust_trace/schema/trace-v0.2.json must be changed together — test_packaged_schema_matches_the_normative_schema fails otherwise. It caught me.

On the trust levels, I think "existing trust-level definitions remain unchanged" is the sentence to revisit rather than the one to keep. Profile B (TRACE + ZK, no TEE) has to set runtime.platform: software-only, and that is enforced, not conventional:

$ trace-tests verify --record zk-record.json --level 1
TR-RTE  FAIL  TR-RTE-001: runtime.platform 'software-only' is development-mode
              and not acceptable for hardware-attested levels

So a record whose whole claim is independently verifiable computation integrity gets capped at Level 0, whose documented meaning is "an attacker with access to the signing key can forge records". The ladder is the only thing a relying party compares on, and it is linear by construction — one enum field. A composable model does not fit in it. That is not fatal to the proposal, but it is a change to §7 conformance and to the TR-RTE module, and it seems better to say so than to inherit an understatement.

Smaller, same theme. program_id is listed with encoding deferred to follow-up work. This repo spent #146, #149 and #157 on exactly that class of thing — how a key is identified turned out to be the security property, not a formatting detail, and two verifiers in one tree ended up comparing the same key two different ways. program_id is the identity of the proven computation. Whatever else stays open, I would pin that one early.

Finally, §2.3 is named as affected in #161 but the RFC proposes no replacement text, and it currently reads "TRACE Records are sound only when: the silicon root of trust ... is uncompromised". A ZK profile needs its own TCB sentence — proof-system soundness, verifier correctness, and setup integrity where the system requires a ceremony. Worth noting that this is the one place proof-system neutrality is hard to hold: a STARK has no trusted setup, Groth16 has a per-circuit one, PLONK a universal one, and the TCB statement is not the same sentence across them.

None of this argues against the proposal. The model reads correct to me and the non-goals section is more honest than most — naming "the operator could not bypass the proven path" as not proven is the thing that usually goes unsaid. It is the Compatibility section that needs the rewrite, not the model.

[imran-siddique]

I agree with the core direction: ZK and TEE are orthogonal mechanisms, and the proposal is stronger for refusing to turn them into one scalar ordering.

Beyond the compatibility and TCB points already raised above, I think the issue needs one more explicit acceptance criterion before follow-up wire-format work: define what an assurance profile means to a relying party. At present it is described as “the set of assurance mechanisms that support the claims,” but that leaves three materially different things conflated:

1. evidence is present (for example, a proof blob);
2. that evidence was successfully verified under a named verification policy/context;
3. a particular claim is supported by the verified evidence.

Mechanism presence alone cannot safely imply claim support. A valid proof for program A, inputs X, and output Y says nothing about a record claim unless the verifier can determine that the record’s claim, identifiers, commitments, and verification context are exactly those public inputs. The same applies to a TEE quote or SCITT receipt.

Could the RFC make the future model’s required relationship explicit—something along the lines of claim -> evidence reference -> verification result/policy—and state how relying parties handle:

• an advertised mechanism they do not implement;
• a mechanism they understand whose evidence fails verification;
• a valid mechanism that does not cover the claim being evaluated;
• multiple mechanisms supporting one claim, including whether they are AND or OR requirements?

This can remain proof-system-neutral and wire-format-neutral, but it is part of the assurance model rather than an encoding detail. Without it, two conforming consumers could assign different assurance to the same record even if they agree on the validity of every cryptographic artifact.

[Trivo25]

Thanks @imran-siddique @lywinged for your feedback!

I think the feedback clusters into five concrete changes to the RFC:

1. Rewrite Compatibility to reflect the current schema enforcement. A ZK assurance block cannot currently be added as an unknown extension; implementation would require a named schema member and corresponding verifier support.

2. Revisit the current trust-level/conformance model. A ZK-only profile is currently forced into software-only/Level 0, which does not express independently verifiable computation assurance. The RFC should acknowledge that the composable model likely requires follow up changes to §7 / TR-RTE, rather than claiming the existing trust levels can remain entirely unchanged.

3. Define the ZK trust assumptions/TCB explicitly, including proof-system soundness, verifier correctness, program identification and setup integrity where applicable. This can remain proof-system neutral at the model level while stating that concrete profiles may have additional system-specific assumptions.

4. Make computation identity and binding requirements explicit. In particular, program_id should be defined as a security-relevant identifier and proof public inputs/commitments must be cryptographically bound to the corresponding TRACE claims using unambiguous encoding and domain separation.

5. Define relying-party semantics for assurance profiles. The RFC should distinguish between evidence being present, evidence verifying successfully under a given policy/context and that verified evidence actually supporting a specific claim. It should also define expected behavior for unsupported mechanisms, failed verification, evidence that does not cover the evaluated claim, and multiple mechanisms combined with AND/OR semantics.

Does that sound like the right interpretation and would these changes address the feedback you raised? If so, I’ll update the RFC along these lines!

[Trivo25]

I went ahead and applies the points above in a follow-up PR here: https://github.com/Trivo25/trace-spec/pull/1/changes

[lywinged]

Thanks @imran-siddique @lywinged for your feedback!

I think the feedback clusters into five concrete changes to the RFC:

1. Rewrite Compatibility to reflect the current schema enforcement. A ZK assurance block cannot currently be added as an unknown extension; implementation would require a named schema member and corresponding verifier support.
2. Revisit the current trust-level/conformance model. A ZK-only profile is currently forced into software-only/Level 0, which does not express independently verifiable computation assurance. The RFC should acknowledge that the composable model likely requires follow up changes to §7 / TR-RTE, rather than claiming the existing trust levels can remain entirely unchanged.
3. Define the ZK trust assumptions/TCB explicitly, including proof-system soundness, verifier correctness, program identification and setup integrity where applicable. This can remain proof-system neutral at the model level while stating that concrete profiles may have additional system-specific assumptions.
4. Make computation identity and binding requirements explicit. In particular, program_id should be defined as a security-relevant identifier and proof public inputs/commitments must be cryptographically bound to the corresponding TRACE claims using unambiguous encoding and domain separation.
5. Define relying-party semantics for assurance profiles. The RFC should distinguish between evidence being present, evidence verifying successfully under a given policy/context and that verified evidence actually supporting a specific claim. It should also define expected behavior for unsupported mechanisms, failed verification, evidence that does not cover the evaluated claim, and multiple mechanisms combined with AND/OR semantics.

Does that sound like the right interpretation and would these changes address the feedback you raised? If so, I’ll update the RFC along these lines!

Yes, that reads as the right interpretation, and I checked the PR rather than the summary. All five are in, and three of them are stronger than what I raised: program_id went from "pin it early" to a MUST on canonical derivation with human-readable names ruled out, the TCB section generalised the setup question correctly without naming proof systems, and the relying-party section is a real answer rather than an acknowledgement.

One thing follows from your point 1 and is not in the PR yet.

A ZK-bearing record would still carry eat_profile: tag:agentrust-io.com,2026:trace-v0.2. Spec §2 says of that URI: "A v0.2 verifier MUST require tag:agentrust-io.com,2026:trace-v0.2 ... It MUST NOT accept both." And verify_record enforces exactly that, before any cryptographic work. So a correct v0.2 verifier meets a record that truthfully claims to be v0.2 and rejects it — not because the record is wrong, but because the URI promised the semantics the verifier implements, and the record carries semantics it does not.

That is the failure the profile URI exists to prevent, arriving from the inside. The RFC now says a verifier "must explicitly support the future ZK evidence representation before it can accept and evaluate a TRACE record that uses that profile", which is true and leaves open which of two things happens: the ZK representation gets its own profile identifier, and old verifiers reject it correctly and say why; or the v0.2 identifier keeps its name and §2's "MUST require exactly this" grows a notion of compatible versions. Those are different specifications, and only one of them is follow-up work.

A smaller thing that will make this harder to discuss. The RFC uses "profile" for two different objects: the assurance profile it defines, and the EAT profile URI in eat_profile that §2 makes a MUST. The sentence I quoted above uses it in the second sense while the section around it uses the first. Renaming one of them costs a find-and-replace today and gets expensive once people are implementing against it.

This may be larger than this RFC. Which identifier a record carries is a question about how TRACE versions itself rather than a question about ZK, and an RFC that answered it would be answering something it did not set out to. Naming it as a dependency is probably enough.

[Trivo25]

Yes, that reads as the right interpretation, and I checked the PR rather than the summary. All five are in, and three of them are stronger than what I raised: program_id went from "pin it early" to a MUST on canonical derivation with human-readable names ruled out, the TCB section generalised the setup question correctly without naming proof systems, and the relying-party section is a real answer rather than an acknowledgement.

One thing follows from your point 1 and is not in the PR yet.

A ZK-bearing record would still carry eat_profile: tag:agentrust-io.com,2026:trace-v0.2. Spec §2 says of that URI: "A v0.2 verifier MUST require tag:agentrust-io.com,2026:trace-v0.2 ... It MUST NOT accept both." And verify_record enforces exactly that, before any cryptographic work. So a correct v0.2 verifier meets a record that truthfully claims to be v0.2 and rejects it — not because the record is wrong, but because the URI promised the semantics the verifier implements, and the record carries semantics it does not.

That is the failure the profile URI exists to prevent, arriving from the inside. The RFC now says a verifier "must explicitly support the future ZK evidence representation before it can accept and evaluate a TRACE record that uses that profile", which is true and leaves open which of two things happens: the ZK representation gets its own profile identifier, and old verifiers reject it correctly and say why; or the v0.2 identifier keeps its name and §2's "MUST require exactly this" grows a notion of compatible versions. Those are different specifications, and only one of them is follow-up work.

A smaller thing that will make this harder to discuss. The RFC uses "profile" for two different objects: the assurance profile it defines, and the EAT profile URI in eat_profile that §2 makes a MUST. The sentence I quoted above uses it in the second sense while the section around it uses the first. Renaming one of them costs a find-and-replace today and gets expensive once people are implementing against it.

This may be larger than this RFC. Which identifier a record carries is a question about how TRACE versions itself rather than a question about ZK, and an RFC that answered it would be answering something it did not set out to. Naming it as a dependency is probably enough.

That makes sense! ’ll make two changes:

• rename the RFC’s “assurance profile” terminology to “assurance composition” so it cannot be confused with the normative EAT eat_profile and
• explicitly call out in Compatibility that a normative ZK representation must resolve the eat_profile semantics

I’ll leave the choice between those versioning approaches to followup work rather than prescribing it in here.

See Trivo25@2ff6309

[Trivo25]

Hey! I think I've addressed all the comments here and in #162 Let me know what you think! @imran-siddique @lywinged

[Trivo25]

Thank you for your cooperation, @imran-siddique and @lywinged - I would love to continue contributing, as I believe this will be an important foundation for the agentic future. Let me know what you think are some approriate next steps, examples, reference implementation, ..