2026 Comparative Analysis: Runtime Attestation and Verifiable Execution Evidence for AI Agents — Applied Technology Index

Executive Summary

Runtime attestation for AI agents is the production of cryptographically verifiable evidence about an execution environment and the claims bound to a particular run. It is stronger than an ordinary application log when the evidence key is protected by measured hardware, but it is narrower than proof that an agent was correct, safe, or successful.

The Linux Foundation announced the contribution of TRACE (Trust, Runtime Attestation, and Compliance Evidence) on 25 August 2026. The announcement describes TRACE as an open specification for hardware-attested runtime and compliance evidence for AI agents and confidential workloads, developed collaboratively by AMD, Intel, Microsoft, OPAQUE, and the Technology Innovation Institute. The current repository identifies TRACE v0.2 as a developer-preview, pre-ratification draft whose fields, wire formats, and conformance requirements can change before v1.0.

TRACE is notable because it defines an AI-agent-specific evidence record rather than another general telemetry format. Its record can bind a workload identity, model identifier and optional weights digest, runtime measurement, policy bundle hash and enforcement mode, data classification, build provenance, evidence appraisal, and a digest of tool calls observed at an instrumented protocol boundary. A confirmation key and signature bind the claims; an optional SCITT reference can bind the record to transparency infrastructure.

TRACE does not replace the standards under it. It composes them:

IETF RATS, RFC 9334 defines the roles and trust model: an Attester produces Evidence, a Verifier appraises it against reference values and policy, and a Relying Party decides what to trust or permit.
IETF EAT, RFC 9711 defines an attestation-oriented claim framework using CWT or JWT and explicitly relies on profiles to make choices about encoding, algorithms, freshness, and required claims.
in-toto Runtime Trace v0.1 describes monitored process, network, and file-access events, primarily for software-supply-chain operations such as builds. It records what a monitor observed, but its strength depends on the monitor and does not by itself establish a hardware root for an AI-agent session.
TRACE v0.2 profiles and binds claims for an AI-agent or confidential-workload run. Its strongest assurance depends on trustworthy hardware evidence, reference measurements, appraisal, key binding, transcript capture, and revocation handling.
SCITT draft-22 provides transparency architecture for signed statements, registration policies, verifiable data structures, and receipts. A receipt supports inclusion and auditability; it does not make the submitted statement accurate.

The central finding is that these mechanisms address different questions. A runtime trace answers what was observed. Remote attestation answers which measured environment produced evidence. An EAT profile answers how claims are represented and interpreted. TRACE answers which AI-agent governance claims are bound together. SCITT answers whether a signed statement was registered under a disclosed transparency policy and can be checked against a verifiable data structure.

No one layer proves that a model followed instructions, resisted prompt injection, chose the right tool, used complete evidence, or caused the intended real-world outcome. TRACE’s own specification and limitations document explicitly exclude model correctness, prompt injection prevention, denial of service, internal reasoning, definitive cross-call data lineage, TEE side channels, and policy correctness.

For production adoption, treat TRACE as an emerging evidence profile, not a finished compliance product. Start by defining the relying-party decision and threat model. Keep raw observability data for investigation, use hardware-rooted attestation only where its trust assumptions are justified, pin trusted verifier and issuer keys outside the record, require freshness and revocation checks, and test independent verification before using a record to authorize consequential actions.

Key Findings

A signed log and a hardware-attested record are not equivalent. A software-held key can show that a record was unchanged after signing, but a privileged operator who controls that key can fabricate the record. TRACE labels this software-only profile Level 0 and limits it to development and audit-trail tooling rather than third-party proof.
Hardware measurements need appraisal. A genuine TEE quote identifies measured state; a verifier still needs current endorsements, reference values, revocation data, and an appraisal policy to decide whether that state is acceptable. RFC 9334 deliberately separates Evidence from Attestation Results and the Relying Party’s trust decision.
EAT is a framework, not an AI-agent evidence policy. RFC 9711 defines attestation claims, CWT/JWT representation, profiles, and freshness considerations. It does not define model, policy-bundle, tool-transcript, or data-classification semantics for agent runs. TRACE adds those profile-specific bindings.
Tool evidence is boundary-limited. TRACE records a digest and count for calls observed at an instrumented surface such as MCP or A2A. Functions executed entirely inside the measured binary do not cross that boundary. A digest also requires access to the underlying transcript and an agreed canonicalization procedure for investigation.
A transcript proves neither intent nor outcome. Observing a request and response does not prove why a model selected the call, which response fields influenced a later action, whether the external system committed the effect, or whether the effect was later reversed.
Policy binding is not policy validation. A record can prove that a particular policy hash and enforcement mode were bound to the run. It cannot prove that the policy was complete, correctly authored, or sufficient for the business outcome.
Transparency is not truth. SCITT’s architecture makes signed statements auditable and supplies receipts over a verifiable data structure. Its security section distinguishes transparency from statement accuracy. A false claim can be immutably registered.
Freshness must be designed, not inferred from a timestamp. RFC 9334 discusses clocks, nonces, and epoch identifiers. TRACE requires time and signature checks and describes stronger challenge or transparency-based handling. A verifier that accepts an old but valid record without a session-bound challenge can authorize the wrong run.
Offline signature verification has a revocation boundary. TRACE’s verification guidance says an offline check can establish that a record was signed by a key, but not that the key remains trusted. Current revocation state or a sufficiently fresh signed revocation bundle is required for a stronger conclusion.
Embedded keys do not self-authenticate. Verifying a signature against the public key carried inside an untrusted record proves only internal consistency. The relying party must bind that key to an external trust anchor, approved issuer, TEE evidence chain, or pinned identity.
Build provenance and runtime evidence are complementary. SLSA or in-toto can describe how an artifact was built; runtime attestation can bind the loaded environment and execution claims. Neither alone proves that the artifact behaved correctly during a particular agent session.
The current TRACE draft has visible implementation maturity work but remains pre-ratification. The repository publishes schemas, examples, a Python SDK, reference integrations, and conformance work. The draft also records breaking profile-identifier migration from v0.1 to v0.2 and open requirements that can change before v1.0.

Methodology

This analysis reviewed primary technical materials available on 31 August 2026. Current public discussion was used only to identify the Linux Foundation TRACE announcement as a frontier signal. Capability and limitation claims were grounded in the Linux Foundation announcement, the TRACE v0.2 specification and repository documentation, IETF RFC 9334, IETF RFC 9711, SCITT architecture draft-22, the in-toto Runtime Trace predicate, and Microsoft’s published Agent Governance Toolkit integration decision.

The approaches were assessed on twelve criteria:

Evidence subject: device, workload, build step, model session, tool boundary, or signed statement.
Trust root: software key, workload identity, hardware attestation key, vendor endorsement chain, or transparency-service key.
Claim semantics: generic measurements, process events, AI-agent policy and tool claims, or registration metadata.
Evidence production: monitor observation, TEE measurement, application adapter, verifier appraisal, or transparency registration.
Freshness: timestamp, nonce, epoch, session binding, inclusion order, or current revocation state.
Identity binding: host URI, subject URI, SPIFFE or DID identifier, confirmation key, or issuer trust anchor.
Policy binding: monitor configuration, evidence appraisal policy, agent policy hash, enforcement mode, or registration policy.
Tool visibility: process and network events, protocol-level tool transcript, or no tool-specific semantics.
Portability: vendor-specific evidence, standards-based attestation result, portable JSON/CBOR profile, or ledger receipt.
Independent verification: what a third party can verify without trusting the workload operator.
Failure semantics: malformed schema, unknown key, stale evidence, revoked key, failed appraisal, missing transcript, or invalid receipt.
Maturity: ratified RFC, Internet-Draft, versioned predicate, pre-ratification profile, reference implementation, and conformance assets.

This is a documented-capability analysis. No confidential-computing instances were provisioned. No AMD SEV-SNP, Intel TDX, TPM, NVIDIA confidential-GPU, SPIFFE, EAT, TRACE, in-toto, or SCITT interoperability workload was executed. The analysis therefore does not measure quote latency, verification throughput, transcript completeness, hardware coverage, operational cost, cross-cloud portability, or resistance to an active adversary.

The comparison treats RATS, EAT, TRACE, in-toto Runtime Trace, and SCITT as composable layers rather than interchangeable products. Product-specific attestation services were not ranked because cloud availability, evidence formats, verification policies, and commercial terms differ and require a separate empirical evaluation.

Comparative Analysis Table

Approach	Primary question answered	Evidence and trust basis	AI-agent and tool semantics	Best fit	Main limitation
Software audit log or signed session record	What did this application report during a run?	Application events, optional hash chain or signature, key usually controlled by the operator	Can be rich if the application records prompts, decisions, tools, approvals, and results	Debugging, operations, internal audit, and the raw transcript behind stronger evidence	Operator-controlled software and keys can omit, alter before signing, or fabricate events; internal consistency is not independent proof
in-toto Runtime Trace v0.1	What process, network, or file-access events did a monitor observe during an operation?	in-toto Statement plus monitor identity, monitor configuration, monitored-process identity, and monitor logs	Generic event model; primarily motivated by software-build runtime traces rather than agent policy or tool-call semantics	Build and supply-chain evidence, hermeticity checks, file-material discovery, and monitored process investigations	Assurance depends on the monitor; event subformats are monitor-specific; asynchronous monitoring can weaken file-digest guarantees; no agent-specific policy or outcome model
IETF RATS, RFC 9334	How should Attester, Verifier, and Relying Party roles exchange and appraise evidence?	Evidence, endorsements, reference values, appraisal policy, and Attestation Results	Technology-neutral architecture with no prescribed AI-agent tool schema	Designing trust boundaries and separating raw evidence from appraisal and authorization	Architecture and terminology, not a wire format or ready-made agent record; deployments must choose protocols, claim formats, freshness, and policy
IETF EAT, RFC 9711	How can attestation-oriented claims about an entity be represented and profiled?	CWT or JWT claims protected by COSE or JOSE mechanisms, interpreted through an EAT profile	Generic entity claims, measurements, manifests, submodules, nonce, timestamps, and profile identifier; no default agent transcript model	Portable attestation claims across devices, software, TEEs, and composite systems	Does not imply a message flow and intentionally delegates many choices to profiles; an EAT token is not automatically a trustworthy appraisal
TRACE v0.2	Which runtime, model, policy, data class, build provenance, and observed tool-transcript claims were bound to this agent or confidential-workload record?	Signed profile record; Level 0 software key or stronger TEE-bound key and appraisal; optional transparency reference	Explicit model, policy bundle, enforcement mode, data class, build provenance, and protocol-bound tool-transcript claims	Cross-organization evidence for governed agent runs, confidential MCP gateways, and regulated-workload evaluation	Developer-preview, pre-ratification draft; hardware and vendor mappings require operational validation; boundary capture does not prove internal reasoning, policy quality, or external outcome
SCITT architecture draft-22	Was a signed statement accepted under a transparency service’s registration policy and committed to a verifiable data structure?	Signed statement, transparency-service trust anchors, registration policy, inclusion or consistency proof, and receipt	Content-agnostic; can carry or anchor agent evidence but does not define agent claims	Durable registration, ordering evidence, auditability, and cross-organization receipt verification	Internet-Draft rather than final RFC; a receipt proves registration and integrity under a service policy, not accuracy of the statement or completeness of all agent runs

Observed Profiles

Software records: useful evidence with an operator-trust ceiling

Most agent systems begin with traces, database rows, object-store logs, or event streams. They are indispensable because they preserve detailed prompts, model responses, tool inputs, tool outputs, approvals, errors, and timing. A compact attestation record normally cannot replace this forensic detail.

Cryptographic chaining improves tamper evidence after an entry has been created. Public-key signatures also let a third party check the artifact without sharing a symmetric secret. Neither property proves that the logging process observed every relevant event or that the operator did not generate a fictional history before signing it.

Microsoft’s Agent Governance Toolkit decision record illustrates this boundary. It describes a pre-existing HMAC-chained tool-call audit log as tamper-evident inside one deployment but not independently portable because verification requires the operator’s shared secret. The integration adds a public-key-verifiable TRACE session record, while identifying hardware attestation and transparency as separate runtime responsibilities.

The practical architecture is to preserve both forms:

a detailed operational trace for debugging and investigation;
an immutable digest over the canonical transcript;
a signed session record that binds the digest to identity, policy, runtime, and time;
stronger hardware and transparency evidence where the relying party requires it.

Deleting the underlying transcript after keeping only its hash proves too little for most investigations. The hash can show that a later transcript matches the committed bytes, but it cannot reconstruct those bytes.

in-toto Runtime Trace: observable system events around an operation

The in-toto Runtime Trace predicate defines a versioned statement with three central components: the monitor, the monitored process, and the monitor log. The log can contain process, network, and file-access events. The motivating use case is a software-supply-chain step such as a build, although the specification says the model can express other monitored operations.

This is a broader and lower-level observation surface than TRACE’s agent-specific record. Process and network events can reveal that an unexpected executable ran or an unapproved network destination was contacted. File-access records can support material discovery or hermetic-build assertions. TRACE instead binds selected governance claims and a digest of protocol-visible agent tool activity into one profile.

The in-toto predicate is explicit about monitor-dependent assurance. Process and network event bodies depend on the named monitor. Its file-access discussion distinguishes synchronous monitoring, which can pause execution while a digest is calculated, from asynchronous mechanisms such as eBPF that cannot stop use of the file before hashing. Consumers must understand the capture mechanism before converting an event into a security conclusion.

A production evidence system can use both: in-toto Runtime Trace for lower-level system activity and TRACE for the higher-level agent session. The records should share stable workload, image, session, and time identifiers. Merely linking two unrelated signed objects does not prove they describe the same execution.

RATS: evidence, appraisal, and the authorization decision are separate

RFC 9334’s most important contribution is role separation. The Attester produces believable information about itself as Evidence. The Verifier appraises that Evidence using endorsements, reference values, and an appraisal policy. It creates Attestation Results. A Relying Party uses those results as one input to a trust or authorization decision.

This prevents a common category error: treating a genuine hardware quote as self-explanatory. A quote can be cryptographically valid while describing an outdated firmware version, an unexpected image, a debug configuration, or a workload that policy does not allow. Verification must compare measurements against acceptable reference values and account for revocation and freshness.

RFC 9334 also distinguishes trust from trustworthiness. Attestation supplies information relevant to trustworthiness. The relying party still chooses whether to trust and what action to permit. That decision can include business identity, user authorization, transaction limits, geography, data classification, and risk signals that are not part of hardware evidence.

For agent infrastructure, map the roles explicitly:

the measured agent runtime or gateway is the Attester;
a cloud, vendor, or independent attestation service can be the Verifier;
the tool gateway, data service, workflow engine, customer, or auditor can be the Relying Party;
reference measurements and endorsements come from image publishers, hardware vendors, and platform authorities;
the relying-party policy determines whether the evidence is sufficient for a read, write, payment, deployment, or data-release operation.

Do not let an agent-generated claim serve simultaneously as Evidence, appraisal, and authorization. That collapses the trust boundaries RATS was designed to separate.

EAT: a profile framework, not a universal policy verdict

RFC 9711 defines the Entity Attestation Token as an attested claim set describing the state and characteristics of an entity. An EAT can be encoded as a CWT or JWT and protected using the corresponding COSE or JOSE mechanisms. Its claims include nonces, identifiers, software manifests and measurements, submodules, issued-at time, intended use, and a profile identifier.

EAT deliberately supports many devices and deployment models. It therefore requires a profile to settle interoperability choices such as JSON or CBOR, algorithms, key identification, freshness, and which claims are required. EAT also states that it does not imply a message flow.

An eat_profile value is consequently not a decorative label. It tells a verifier which semantics and requirements it is expected to implement. TRACE v0.2 uses a profile identifier under the agentrust-io.com domain and requires v0.2 verifiers to reject the superseded v0.1 identifier. That breaking migration is a useful warning for adopters: store exact profile versions, do not silently accept unknown versions, and test upgrade behavior with real records.

A validly signed EAT-shaped object does not automatically mean its measurements are approved or its issuer is trusted. Schema validation, signature verification, external key trust, freshness, appraisal, and relying-party policy remain separate checks.

TRACE v0.2: an agent-specific binding profile

TRACE’s core contribution is the Trust Record. The current v0.2 specification binds:

subject: workload identity, expressed as a URI;
model: provider, model identifier, version, optional weights digest, and optional AI bill-of-materials reference;
runtime: platform and measured runtime evidence;
policy: policy bundle hash and enforcement mode;
data_class: classification associated with the run;
tool_transcript: digest, call count, and optional transcript reference for observed protocol-boundary calls;
build_provenance: SLSA-oriented level, digest, and optional provenance reference;
appraisal: verifier status and identity;
transparency: optional reference to transparency evidence;
cnf: confirmation key binding;
profile, issued-at time, and a signature or signed envelope.

This schema is useful because it makes previously implicit relationships explicit. A relying party can ask whether the approved policy digest was in enforcement mode, whether the measured workload matched the expected release, whether the model identity was allowed, whether the data class was compatible, and whether the tool transcript digest matches the retained session evidence.

The trust level matters more than the field count. TRACE’s documentation describes:

Level 0: a structurally valid record signed with a software-held key. It supports development and internal audit but is forgeable by an operator who controls the key.
Level 1: a record whose signing key and measurement are tied to an appraised TEE or supported hardware root.
Level 2: Level 1 plus transparency anchoring for cross-organization auditability.

These labels should not be accepted without independently evaluating the underlying evidence. The relying party should recompute the achieved level from record content, trusted evidence chains, appraisal, and receipt verification rather than trusting a producer-supplied label.

The signature protocol is equally important. TRACE v0.2 requires a cryptographic binding over canonical record content, using RFC 8785 JSON Canonicalization Scheme unless a profile declares otherwise. The confirmation public key remains in the signed content, but the verifier must compare it with an externally trusted key or hardware-bound identity. Otherwise an attacker can create a new key, embed it, and sign a self-consistent false record.

The repository’s verification guidance checks schema before interpreting claims, validates the exact profile identifier, verifies canonical signature input, applies external key trust, appraises claims, and handles revocation. This fail-closed sequence is a stronger basis than a UI badge that says “attested.”

Tool transcript binding: valuable but intentionally incomplete

Tool calls are where an agent crosses from language generation into external action. Binding a canonical transcript digest to runtime evidence can detect later alteration and help an auditor connect a session record with detailed call history.

The proof boundary must stay explicit. TRACE’s specification says the transcript covers invocations crossing an instrumented protocol boundary. Code paths inside the deployed binary fall outside tool_transcript and are represented only indirectly through model and build-provenance claims. The limitations document also says internal model reasoning and context-window contents are not captured.

A production verifier should ask:

Which boundaries were instrumented: MCP, A2A, HTTP gateway, SDK hook, database proxy, shell, browser, or message bus?
Were both request and response captured?
Were secrets or personal data redacted before canonicalization, and is the redaction policy itself identified?
Is the full transcript retained, where, for how long, and under whose control?
Can the verifier independently recompute the digest and call count?
Are call IDs, session IDs, parent-child delegation IDs, approval IDs, and idempotency keys bound?
Does the transcript record only attempted calls, or independently confirmed effects?
Can an agent reach the same capability through an uninstrumented route?

A complete protocol transcript still may not prove physical or business completion. A payment request can be accepted and later reversed. A deployment call can return before rollout fails. A browser click can be acknowledged while the target transaction is rejected. Consequential systems need receipts from the external authority and post-state reconciliation in addition to the agent-side record.

SCITT: transparent registration without truth laundering

SCITT draft-22 defines architecture for single-issuer signed-statement transparency. A Transparency Service authenticates and registers signed statements under a published Registration Policy, commits them to a verifiable data structure, and returns a Receipt. Auditors and relying parties can validate registration and supporting proofs.

This addresses two gaps that ordinary object storage does not solve well: an issuer should not be able to rewrite history silently, and relying parties should be able to audit which registration policy and trust anchors applied. TRACE can refer to SCITT receipts so a runtime record participates in an independently checkable chronology.

The limitation is fundamental. SCITT’s security considerations state that transparency does not guarantee the accuracy of statements. A service can prove that a particular signed claim was registered, under a particular policy, at a particular position. It cannot know that every relevant agent run was submitted or that the runtime claim was true unless the registration policy performs and documents stronger domain-specific checks.

An operator therefore needs completeness controls outside the receipt itself. Examples include mandatory gateway mediation, sequence-number continuity, expected-run reconciliation, independent tool-side receipts, and alerts when a session terminates without producing or registering evidence.

Freshness, replay, and revocation

A valid old record can be dangerous if it is accepted for a new operation. RFC 9334 provides several freshness models, including synchronized time, nonces, and epoch identifiers. The right choice depends on whether the relying party needs proof about a past event or is deciding whether to release a current capability.

For online admission, a relying party should issue a challenge and require the attestation or signed session evidence to bind that nonce, the intended audience, the exact operation, and an expiration. For retrospective audit, trusted timestamps and transparency ordering may be more important. A bare iat supplied by the record signer is weaker after key compromise because the attacker controlling the key can backdate a forged record.

Revocation creates a separate problem. Cryptographic signature validity does not expire merely because a signing key becomes untrusted. TRACE’s documentation therefore distinguishes offline signature verification from current trust. A current revocation lookup or a signed revocation bundle with a valid freshness window is needed to claim that the key remains acceptable.

Fail closed when revocation status is unavailable for a consequential decision. For an offline historical audit, report the exact state instead of converting uncertainty into a pass: signature valid, profile understood, evidence appraised under named policy, and revocation checked against a bundle valid at a stated time.

An evidence acceptance pipeline for production agents

A relying party considering a consequential agent action can apply this sequence:

Parse without trusting. Enforce size limits, schema, allowed fields, exact profile version, and algorithm policy before interpreting claims.
Resolve external trust. Identify the approved issuer, verifier, hardware vendor, workload identity, and transparency-service roots from configuration outside the record.
Verify signatures and canonicalization. Recreate the exact signed bytes and reject unknown or weak algorithms.
Verify hardware evidence. Check vendor endorsement chains, reference measurements, firmware and TCB state, debug flags, and current revocation data.
Appraise the runtime. Compare measured workload, image, model, dependencies, policy digest, and enforcement mode with approved values.
Bind freshness and audience. Check nonce, session, operation, audience, issued-at, expiration, clock skew, and transparency ordering as required.
Verify transcript commitment. Retrieve the retained transcript from an approved location and recompute its digest and call count.
Verify transparency. Validate the receipt, service trust root, registration policy, and inclusion or consistency proof.
Evaluate business authorization. Apply user, tenant, resource, amount, geography, data-classification, approval, and separation-of-duties policy.
Reconcile outcome. Require authoritative tool-side or business-system receipts and compare final state with the requested action.
Record the decision. Preserve the evidence version, verification software, trust anchors, reference values, policy version, revocation state, and decision result.

Attestation belongs before authorization when it protects a current action, and after execution when it supports audit. Many production systems need both phases.

Evaluation and procurement checklist

Ask a runtime, attestation, or governance vendor:

Which exact TRACE, EAT, RATS, SCITT, in-toto, SPIFFE, SLSA, MCP, and A2A versions are implemented?
Is the emitted artifact raw Evidence, an Attestation Result, a TRACE Trust Record, a transparency receipt, or a vendor-specific wrapper?
Which component holds the record-signing private key, and can the host operator extract or invoke it arbitrarily?
How is the key bound to the measured workload and to the external workload identity?
Which hardware platforms, firmware versions, cloud services, and evidence formats have interoperability tests?
Who supplies reference measurements and endorsements, and how are they updated and revoked?
Which profile and algorithm versions fail closed, and how are migrations handled?
How are nonces, audiences, sessions, expiration, clock skew, and replay detected?
Which tool and network boundaries are instrumented, and what routes bypass them?
Can a third party retrieve the full transcript and independently recompute the committed digest?
How are arguments and responses canonicalized, redacted, encrypted, retained, and deleted?
Does evidence distinguish attempted, accepted, completed, failed, reversed, and reconciled actions?
What does appraisal.status mean, which policy produced it, and can the relying party inspect that policy?
How are current signing-key, verifier-key, hardware, and transparency-service revocations checked?
Can verification run without contacting the evidence issuer, and what trust state becomes unknown offline?
What SCITT registration policy applies, and does it validate only signatures or also domain-specific claims?
How does the system detect a missing record, sequence gap, unregistered session, or disabled instrumentation path?
Are schemas, conformance vectors, negative tests, and independent implementations public and versioned?
What measured performance and cost overhead applies at session start, per tool call, record finalization, registration, and verification?
What assurance claims have been independently audited, and which remain product documentation rather than certification?

Limitations

This analysis reflects public documentation available on 31 August 2026. TRACE is explicitly a developer-preview, pre-ratification v0.2 draft. The profile identifier, fields, wire format, trust-level rules, vendor annexes, conformance requirements, governance structure, reference implementations, and SCITT integration can change before v1.0.

The Linux Foundation announcement establishes contribution, participating organizations, and intended neutral governance. It is not an interoperability certification, security audit, regulatory approval, or proof that every named participant deploys the current draft in production.

No implementation was executed. The analysis does not establish that current TRACE libraries correctly validate every schema edge case, bind keys to every advertised TEE, verify current vendor collateral, produce complete tool transcripts, interoperate across clouds, anchor successfully to a conformant SCITT service, or resist a privileged active attacker.

The in-toto Runtime Trace predicate and SCITT architecture are not direct competitors to TRACE. They address different evidence layers. The table is an architectural comparison, not a product ranking or a claim that every combination is currently implemented.

Hardware attestation inherits hardware and verifier assumptions. A valid quote can coexist with side channels, vulnerable firmware, bad reference values, permissive appraisal policy, compromised vendor roots, missing platform-state checks, or application logic outside the measured boundary.

Agent evidence is necessarily incomplete. A model’s internal reasoning is not observable through tool-call transcripts. Temporal adjacency between calls does not prove data lineage. A protocol-boundary record omits actions that bypass the boundary. A signed request does not prove that an external effect completed or remained final.

Transparency does not guarantee truth or completeness. A receipt proves that a statement was registered under a service’s policy; it does not prove that the statement is accurate, that all runs were registered, or that no parallel log exists.

Compliance conclusions are outside scope. Whether a particular evidence level satisfies the EU AI Act, DORA, HIPAA, financial-services rules, public-sector procurement, or another control framework depends on jurisdiction, system classification, implementation, retention, governance, and professional interpretation. Repository examples should not be treated as legal advice or certification.

Published performance figures in project documentation were not independently reproduced and are not used as comparative results here. Operators should benchmark claim generation, quote retrieval, transcript hashing, storage, registration, verification, and revocation under their own workloads.