[phase-2] tool_transcript binding — hash-chain MCP call log into Trust Record

[imran-siddique]

What and why

The TRACE Trust Record tool_transcript field should cryptographically bind the full tool call log to the Trust Record. In Phase 1, this field contains only the aggregate call summary (call_count, transcript_uri). In Phase 2, it should contain a hash of the full transcript that is verifiable offline.

The GTC Berlin demo requires showing a tool_transcript where a regulator can see:

"tool_transcript": [
  {"tool": "document_reader", "data_class": "confidential", "decision": "allow"},
  {"tool": "credit_score_lookup", "data_class": "confidential", "decision": "allow"},
  {"tool": "risk_report_writer", "data_class": "internal", "decision": "allow"}
]

And verify that this list was signed by the TEE key and matches the audit chain root.

Design

• The audit chain chain_tip hash becomes the tool_transcript.hash value in the Trust Record
• The full transcript (all AuditEntry objects) is available via /audit/export (issue [audit] Audit log export — signed bundle for verifier access #55)
• tool_transcript in the TRACE Claim: {hash: "sha256:...", call_count: N, entries: [{tool, data_class, decision}]}
• The entries array uses the audit chain entries, not raw tool call parameters (no PII leakage)

Acceptance criteria

• GatewayClaim.trace.tool_transcript includes hash = audit_chain.chain_tip
• Each entry in tool_transcript.entries has: tool_name, data_class (from catalog), decision (allow/deny/advisory_deny)
• tool_transcript.hash is verifiable: SHA-256 of canonical JSON of the entries array
• Integration test: run 3 tool calls → verify tool_transcript.call_count == 3 and entries match
• No raw tool arguments or response data in tool_transcript (privacy-preserving)

Notes

Depends on Phase 2 TEE policy enforcement (issue above) — the entries are most meaningful when they're TEE-signed. Target: Q3 2026.