UHP vs TRACE runtime evidence

The one-sentence difference

UHP is a live client-to-server contract for driving complete agent harnesses; TRACE is an evidence format and verification model for proving facts about an agent workload’s measured runtime, bound policy, data class and observed tool activity.

They therefore address different boundaries: UHP controls execution; TRACE creates portable evidence about execution.

Status first

• UHP is 2026-08-11, a Draft standard with a runnable 52-check conformance suite (2026.8.11.post1).
• TRACE is currently v0.2 Developer Preview. The normative specification labels itself 0.2 — Draft, status RFC — Request for Comments, and explicitly says it is a pre-ratification draft whose fields, wire formats and conformance requirements may change before v1.0.
• On 25 August 2026, the Linux Foundation announced the contribution of TRACE and said it will provide vendor-neutral governance. The current repository describes TRACE Specification as an LF Project hosted as its own Linux Foundation series.
• TRACE has a published schema, conformance test suite and reference implementation, but those artifacts do not make v0.2 a finalized standard or make a TRACE result a UHP conformance result.

Architectural comparison

Dimension	UHP	TRACE
Primary boundary	Client/product ↔ UHP server ↔ complete harness runtime	Attested workload/runtime ↔ Trust Record ↔ verifier/relying party
Main purpose	Execute and control agent-harness work consistently	Produce and verify portable cryptographic governance evidence about an execution
Core object	Harnesses, responses, sessions, containers, files, artifacts and events	Signed Trust Record carrying runtime, model, policy, data-class, tool-transcript and provenance claims
Live control	Submit, stream, continue, cancel and retrieve results/artifacts	No task-submission, session-control or cancellation API
Runtime identity	UHP identifies server/harness execution surfaces and scopes objects to authenticated principals	TRACE binds workload identity and measured runtime evidence, including hardware-attestation roots where available
Policy evidence	UHP defines protocol/security requirements but no generic hardware-attested policy-evidence record	policy.bundle_hash and enforcement mode can be bound into the Trust Record
Tool evidence	UHP may expose events/results from harness work	tool_transcript records governed protocol-boundary tool activity and binds its digest/count into evidence
Data classification	UHP does not define a portable attested data-class claim	data_class is part of the TRACE claim set
Transparency	UHP has no general transparency-ledger requirement	TRACE can bind a SCITT receipt / transparency reference into the record
Conformance	UHP server behavior: Core / Extended / Full, 52 checks in the current suite	Separate TRACE conformance suite for TRACE records/implementations; not interchangeable with UHP conformance
Maturity snapshot	Draft protocol with reference implementation and conformance suite	v0.2 Draft / Request for Comments / Developer Preview under Linux Foundation governance

What a TRACE Trust Record contains

The current v0.2 schema binds several independently checkable facts into one signed record. Key claims include:

• subject — workload identity, such as a SPIFFE SVID or DID URI;
• model — model identity/version and weights digest;
• runtime — measured execution environment and attestation evidence;
• policy — policy bundle hash and enforcement mode;
• data_class — classification attached to the execution;
• tool_transcript — governed MCP/A2A or other instrumented boundary activity;
• build_provenance — SLSA-oriented provenance for code/model build inputs;
• appraisal — evidence appraisal results;
• transparency / anchoring — optional transparency evidence such as a SCITT receipt;
• cnf, profile/time claims and a signature/enveloping signature binding the record to its key.

TRACE composes existing standards rather than replacing them. Its current materials explicitly build on RATS, EAT, SLSA, SCITT, SPIFFE and EAR.

Why this matters for harness interoperability

Agent infrastructure now has at least three separate questions:

1. How do I execute work through a complete harness? UHP targets this client/server runtime contract.
2. How do I exchange a portable history of the run? ATIF targets trajectory interchange for evaluation, replay, debugging and training.
3. How do I cryptographically verify what environment ran, which policy was bound, what data class was handled and which governed tool calls crossed the boundary? TRACE targets this runtime-evidence layer.

A deployment could therefore use the layers together. A UHP server could drive a harness while an implementation-specific attested runtime emits TRACE Trust Records and an observability/evaluation path emits ATIF trajectories. The formats would serve different consumers and assurance goals.

Caution

No standardized UHP↔TRACE binding is established by the current evidence. This guide has not verified a UHP field, endpoint, content type, conformance requirement or official TRACE profile that maps UHP responses/sessions into TRACE Trust Records. TRACE references MCP/A2A execution boundaries in its current design, but that does not make TRACE part of MCP, A2A or UHP, and it does not establish native UHP adoption by the TRACE project or its contributors.

What TRACE does not prove

TRACE’s own limitations are important because cryptographic evidence can be over-interpreted:

• A hardware-attested record does not prove that the model’s output was correct, aligned or safe.
• It does not prevent prompt injection, jailbreaks, hallucinations or other model-behavior failures.
• It binds the policy that was in force; it does not prove that the policy itself was well-designed or sufficient.
• The tool transcript covers activity visible at instrumented protocol boundaries; it does not expose the model’s internal reasoning or every function executed inside the workload.
• Pure offline signature verification does not prove that the signing key is still trusted; current revocation/freshness checks remain separate verifier responsibilities.
• Software-only Level 0 evidence is explicitly development/audit-trail material and does not provide hardware-rooted third-party assurance.

These limits are why TRACE should be read as evidence infrastructure, not as an authorization system, safety certification, or proof that a real-world effect was correct.

Relationship to SCITT action receipts and other evidence layers

TRACE and the other evidence concepts tracked by this guide overlap in vocabulary but not in unit of proof:

• TRACE: environment/runtime/policy/data/tool evidence tied to an attested workload execution.
• SCITT AI-Agent Action Receipts: signed per-action records with optional transparency registration; receipt validity does not itself prove authorization or real-world effect.
• CCS: per-tool-call verification evidence and disposition dimensions.
• AEB: executor-side sequencing for evidence verification, local authorization, durable consumption/reservation, dispatch and outcome reconciliation.
• ATIF: portable whole-agent trajectory records for replay/evaluation/training rather than hardware-rooted attestation.

None of these layers is normative UHP 2026-08-11 behavior.

Reference implementation and governance signal

The TRACE repository identifies Confidential MCP (cMCP) as its first reference implementation and links a dedicated conformance test suite. The Linux Foundation’s 25 August contribution announcement says TRACE was developed collaboratively by AMD, Intel, Microsoft, OPAQUE and the Technology Innovation Institute (TII), and that the Linux Foundation will provide vendor-neutral governance with a technical workstream hosted by CoSAI.

That is a stronger durability signal than a single-vendor draft, but current maturity still matters: v0.2 is Developer Preview / pre-ratification, not v1.0 and not a final industry certification regime.

What TRACE does not replace

• It does not replace UHP’s client-to-harness execution contract.
• It does not replace MCP or A2A as live interaction protocols merely because tool transcripts can reference those boundaries.
• It does not replace RATS, EAT, SCITT, SLSA, SPIFFE or EAR; it profiles/composes them.
• It does not make a TRACE-conformant producer a UHP implementation.
• It does not establish UHP adoption by AMD, Intel, Microsoft, OPAQUE, TII, the Linux Foundation or CoSAI.

Related pages

Read UHP security and trust boundaries, UHP vs ATIF, UHP vs MCP, UHP vs A2A, and the ecosystem map for the neighboring execution, evidence and protocol layers.

Primary sources

• TRACE v0.2 specification
• TRACE specification repository
• TRACE documentation
• TRACE known limitations
• TRACE conformance test suite
• Confidential MCP (cMCP) reference implementation
• Linux Foundation: TRACE contribution announcement (25 Aug 2026)
• UHP 2026-08-11 architecture