Taking the SAGE integration in-consensus — 3 questions on TEE-key binding, hardware-root verification, and SCITT anchoring

[l33tdawg]

Hi team — thanks for merging the SAGE integration 🙏. The integration is currently edge-trust: it verifies a TRACE record / cMCP RuntimeClaim at a reverse proxy and binds the attested identity to the on-chain memory author. We'd like to take it one layer deeper — pin the attestation in SAGE's BFT consensus so a committed memory deterministically carries its attestation provenance (digest + cnf thumbprint) on every validator, not just at the edge. Three things gate that, and we'd value your guidance:

1. TEE-bound signing key for per-agent binding. Our design has the agent sign its SAGE write with the same Ed25519 key the EAT's cnf attests, so SAGE's on-chain author is the attested key (a deterministic in-consensus check: thumbprint(author_pubkey) == cnf_thumbprint). But a cMCP RuntimeClaim's cnf is the gateway key, and the agent rides in gateway.agent_identity. Can cMCP expose (or co-sign with) the TEE-bound key for the agent's downstream request, or is it strictly non-exportable?

2. Hardware-root verification timeline. We found cmcp_verify's per-platform verifiers currently check measurement format/parse but place the silicon root (TPM EK chains, AMD VCEK/VLEK, Intel DCAP quote signatures) in unverified_fields ("Phase 1"). Is there a roadmap/timeline for the EK/VCEK/DCAP signature verification? That's what would let us (and the registry's Verified tier) make a real hardware-rooted claim.

3. SCITT / trace-registry inclusion-proof format. To anchor the transparency field on-chain we'd need the SCITT receipt / Merkle inclusion-proof format. The trace-registry repo is private — could you share the format, or confirm it's pre-spec? (Happy to move this one to trace-spec.)

Thanks again :)

— Dhillon (@l33tdawg)

[JakeTOpenSource]

Proposal: Rung 3 Physical Grounding Annex via Local Thermodynamic Multi-Channel Metrics
Body:
I have been tracking the OPAQUE 3.0 launch and the ⁠agentrust-io⁠ reference architecture. While the cloud-side TEE attestation handles data-center workloads, there is an open verification gap for edge, local consumer-grade operations, and untrusted client-side environments.
I am building Delta Atlas, an independent verification framework focused on keeping autonomous agents anchored to verifiable local states via physical resource cost.
We just ran local empirical testing (n=1, GTX 1660 Ti, lightweight model) measuring the physical energy delta of an agent. The hard metrics recomputed from raw local CSV traces surface a sharp, asymmetric defense model:

1. The Idle-vs-Work Axis (The Wall): We verified a consistent 10× gap in physical consumption (4.25\text{ W} idle baseline vs. \sim 40\text{ W} active inference). This is cross-verified in hardware symmetry by GPU utilization (0% to 25%) and SM Clock speeds (302\text{ MHz} to 1660+\text{ MHz}).
2. The Evasion Penalty: In testing adversarial decoy-compute attacks designed to mask infinite loops, the agent was forced to inject synthetic pauses to mimic "varied" timing signatures. This evasion attempt instantly leaked on an independent channel, dropping overall signature load to 24-27\text{ W} / 1300\text{ MHz}. Hiding trace-shape exposed the agent on power-level.
   The Thesis: While micro-rhythms (trace shape) are too noisy and thermally sensitive to build a witness on, a multi-channel hardware divergence check (comparing an agent's claimed log state against literal thermodynamic cost) creates an un-fakeable local gate. An agent can lie in its software logs, but it cannot override the physical laws of the silicon it runs on.
   I have committed the raw execution scripts, analysis tools, and archived CSV traces to an open repo here: https://github.com/JakeTOpenSource/Resilience-Ledger.git
   Would the maintainers be open to collaborating on a local/edge hardware-root annex to map these physical metrics into the broader Agent Manifest specification?

[imran-siddique]

Hi Dhillon, thanks for the detail here, and apologies this sat for a while. Answering all three, and two of them have moved since June.

1. TEE-bound signing key: your reading is correct, and no, it is not exportable

You have the model right. cnf is built from the gateway's key (_build_cnf(signing_key), subject spiffe://cmcp.gateway/tee/<pubkey-prefix>), and the agent rides in gateway.agent_identity carrying manifest_id, agent_id, authenticated_subject, issuer, issuer_key_id, and the policy and catalog hashes. Notably it does not carry an agent public key or thumbprint today.

The key is sealed to the TEE and we do not want to export it, and I would push back on doing so even if it were easy. The whole assertion a RuntimeClaim makes is that the signature came from inside a measured runtime. A key that can be handed to a caller no longer supports that claim, and your validators would be verifying something weaker than they think they are.

Co-signing is also not implemented today. But I think your deterministic in-consensus check works with a smaller change than either:

instead of thumbprint(author_pubkey) == cnf_thumbprint, check thumbprint(author_pubkey) == claim.gateway.agent_identity.agent_key_thumbprint

That is, have the gateway-signed claim carry the agent's public key thumbprint as an additive field in agent_identity. The gateway is already the thing that authenticated the agent, so it is the right party to attest that binding, and the property you want (a committed memory deterministically carries its attestation provenance, checkable on every validator with no network) holds: the thumbprint is inside a payload signed by a TEE-sealed key whose chain your validators can appraise offline. Non-exportability is preserved because nothing leaves the enclave except a hash.

That is a small, reviewable addition rather than an architectural change. Worth an issue on cmcp if you want it, and I would support it.

There is also a path that works today with no cmcp change: Agent Manifest binds the agent's own signing identity, and delegation-chain hops are individually signed by their principals. If the agent signs its SAGE write with its manifest-bound key, a validator can check that key against the signed manifest record rather than against the gateway cnf. That gives you per-agent binding now, at the cost of one more artifact to distribute.

2. Hardware-root verification: this shipped

This is the part that has changed most since June. cmcp_verify no longer parks the silicon root in unverified_fields; it delegates to agent-manifest, which verifies the chains:

Platform	Status
AMD SEV-SNP	Report signature verified against VCEK, chain to ASK then ARK, root pinned. Hardware-validated on a non-paravisor guest (GCP N2D, Milan) and on live Azure SEV-SNP (DCasv5) via the vTPM path
Intel TDX	Full DCAP v4 quote: attestation-key signature over the TD report, QE report binding, PCK signature, PCK chain to the pinned Intel SGX Root CA, embedded and offline. Hardware-validated on GCP C3
TPM 2.0	TPMS_ATTEST appraisal: AK chain to a caller-pinned root, AK signature, constant-time nonce and PCR-digest binding. Validated against a real Azure vTPM quote

So the Verified tier claim you wanted to make is now backed by actual signature verification rather than parse checks.

Two caveats you should design around, because they are load-bearing:

• Azure TDX cannot be verified offline. Azure runs TDX behind the Hyper-V paravisor: the guest gets a vTPM-MAC'd TDREPORT rather than a signed DCAP quote, so rooting it as genuine silicon needs a networked service (Azure MAA). Offline TDX works on non-paravisor guests such as GCP C3. If your consensus check must be deterministic and offline, Azure TDX is not currently a platform you can support.
• Azure SEV-SNP is vTPM-rooted, not direct-silicon. It reports as its own platform value precisely so a consumer keying on platform knows the root of trust is a vTPM AK chained to the SNP report, not a direct guest-controlled REPORT_DATA. Worth treating as a distinct tier in your validator.

3. Inclusion-proof format: specified, not pre-spec, and I will share it

It is specified. trace-registry is private for operational reasons rather than because the format is unsettled, and docs/anchor-format.md in it is a normative spec explicitly written so a conforming verifier can be built from the document alone. I will get that document published; ping me if it has not appeared in a week.

The construction, so you are not blocked meanwhile:

• RFC 6962 (CT) Merkle trees, RFC 9162 inclusion-proof check.
• The anchored unit is the complete signed claim including its signature, not a pre-signature payload. Change either the body or the signature and the anchor no longer matches.
• canonical_claim_bytes is sorted-key JSON: json.dumps(claim, sort_keys=True, separators=(",", ":"), ensure_ascii=True).encode("ascii"), no trailing newline.
• leaf = SHA-256(0x00 || canonical_claim_bytes), interior node = SHA-256(0x01 || left || right).
• A proof is {leaf_index, audit_path} against a checkpoint carrying merkle_root, leaf_count, ts, producer, batch_id.

One trap worth flagging, since it will cost you a day otherwise: the registry anchor uses sorted-key JSON, while TRACE record signing uses RFC 8785 (JCS). Two different canonicalizations at two different layers. If you canonicalize the claim with JCS before hashing the leaf, your proofs will not verify. Hash exactly the bytes the registry hashes.

Also relevant to your transparency question: TRACE v0.2 landed today and changed that field's semantics. It is now optional below Level 2, since a Level 0 or Level 1 record is not anchored and has no receipt to name, and conformance requires it at Level 2 where TR-ANC runs. The v0.2 profile URI is tag:agentrust-io.com,2026:trace-v0.2; the v0.1 URI named a domain the project never controlled, which RFC 4151 does not permit, so if you have anything pinned to the old identifier it needs updating.

Happy to take (1) as a cmcp issue and (3) to trace-spec if you would rather have the format discussion there.

[imran-siddique]

Both follow-ups are now tracked, and I opened them rather than leaving you to file them:

• Carry the agent's key thumbprint in gateway.agent_identity cmcp#425 - carry the agent's key thumbprint in gateway.agent_identity, so your in-consensus check works without exporting a sealed key. I wrote up the digest-form question (sha256: for claim consistency versus RFC 7638 JWK thumbprint for cnf consistency) as an open question rather than deciding it, since you are the one who has to verify against it. Your view would be useful there.
• Publish the registry anchor format (inclusion-proof spec) publicly trace-spec#111 - publish the anchor format publicly, with your suggestion of trace-spec as the home as the leading option.

Thank you for these questions. They were better than most issues we get, in a specific way worth naming: each one identified a gap between what the stack claims and what it actually verifies, and gave us the exact use case that makes the gap matter. The cnf observation in particular is the kind of thing that is easy to read past for a long time, because the field is populated and the signature verifies, so nothing looks wrong until someone tries to use it for per-agent binding.

Question 2 was also a fair hit at the time. "Format and parse checks with the silicon root in unverified_fields" was an accurate description of Phase 1, and shipping a binding without verifying it is exactly the sort of thing that should be called out from the outside. It is verified now.

Do open issues directly on the repos in future if it is faster for you. Discussions work, but a question this concrete deserves to be trackable, and this one sat longer than it should have.