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)