REVIEW 2 major objections 4 minor 4 references
A signed action record cannot prove which model or hardware actually produced it; binding it to a hardware quote can.
Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →
T0 review · deepseek-v4-flash
2026-08-05 00:10 UTC pith:KF4Y4NVU
load-bearing objection A small, honest architecture note that composes RATS attestation with action evidence packages; feasible on an emulated TPM, but the model-artefact measurement it depends on remains unvalidated. the 2 major comments →
Hardware-rooted attestation for AI-agent evidence: composing IETF RATS with action evidence packages
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
Core claim
The paper's central claim is that the AEP alone cannot close the gap between 'what does the agent claim it did?' and 'did the specific model version the operator claims to have deployed actually produce this output, on unmodified hardware?' The answer it proposes is to compose two artefacts that live in separate worlds: RATS (Remote Attestation Procedures) hardware Evidence—a TPM (Trusted Platform Module) quote over platform measurement registers, appraised by an independent verifier against reference values—and the software AEP, bound together at record time by folding the SHA-256 digest of the AEP outcome and a fresh appraiser nonce into the quote's qualifying data. A six-term vocabulary (
What carries the argument
The load-bearing mechanism is the output-binding protocol within a composite attestation. An AEP is the signed, append-only action record; hardware Evidence is a TPM (Trusted Platform Module) quote signing platform configuration registers (PCRs), with a model-artefact measurement carried in a PCR. At record time, the SHA-256 digest of the AEP outcome plus a fresh appraiser nonce is folded into the quote's qualifying data, so the quote is cryptographically bound to exactly that record and that moment. A six-term vocabulary then maps the AEP's authorisation check and the RATS appraisal into one composite verdict. Without the binding, a valid quote and a valid AEP can be replayed or recombined
Load-bearing premise
The approach only attests the specific model version if the deployment actually measures the model artefact into the attested platform state—an engineering commitment the paper says not all deployments make today, and one its own experiment sidesteps with a stand-in digest rather than a real model binary.
What would settle it
On a real TPM, measure a real model binary into a PCR, produce an output-binding quote, then silently swap the model binary without updating the measurement; if the verifier returns Attested rather than Contested, the composite fails to catch the swapped-model case it exists for. A second refutation: alter the AEP outcome after a quote is produced and show the pair still verifies.
If this is right
- Auditors can treat a clean AEP and a contested PCR measurement as a single high-signal failure: the record says the action happened, the hardware says the platform was not in the claimed state.
- Deployments that measure the model artefact into the attested state can detect a silently swapped model as a Contested verdict rather than a silent pass.
- The composite works for stochastic inference too: it proves this outcome was bound to this attested platform state, not that the output is uniquely reproducible.
- Because the output-binding pattern is standard, the composite can be built from existing TPM and RATS components without new cryptographic primitives.
- If the model artefact is not measured into the attested state, the composite still attests the boot configuration, but the model-version question remains open—the paper states this as an engineering commitment.
Where Pith is reading between the lines
- The same binding logic would extend naturally to any high-stakes software record beyond AI—financial trades, medical decisions, industrial control—wherever a signed log needs hardware grounding.
- The six-term matrix could be extended with a third axis for trust in the verifier and hardware-vendor endorsements; the paper notes that attestation moves trust to those parties but does not formalise such an axis.
- A testable extension is to measure decode parameters and sampler PRNG state into the attested state at generation start; the paper observes this would recover independent re-derivation for deterministic pipelines, but leaves it as future work.
- Because the experiment substitutes a stand-in digest for a real model binary, the immediate practical check is whether real model artefacts hash stably into PCRs across boot sequences and updates; if they do not, Contested verdicts could become noisy.
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. The paper argues that a signed, append-only action evidence package (AEP), being a software-layer self-report, cannot by itself establish that a specific model version actually ran on unmodified hardware. It proposes composing a RATS-style hardware attestation with the AEP: the AEP outcome digest and a fresh appraiser nonce are folded into the qualifying data of a TPM-signed quote, so that a later reviewer can traverse from an output to an attested, authorised origin. The paper defines a six-term verdict vocabulary (Authorised/Unauthorised/Indeterminate on the AEP axis; Attested/Contested/Expired on the platform axis), maps it provisionally to AR4SI/EAR, and reports a small executed experiment on swtpm with four cases: a good quote (Attested), a perturbed PCR 3 (Contested), a replayed quote (Expired), and a forged AEP outcome under a valid quote (rejected). The paper is explicitly a feasibility demonstration on emulated hardware and states several limitations, including the use of a stand-in digest in PCR 3 rather than a genuinely measured model binary.
Significance. If taken as a design-level composition note, the paper is useful and timely: it connects an active standards effort (IETF RATS, Veraison) to AI-agent governance evidence, and it is unusually honest about the boundary between architecture and implementation. The main strengths are the clean two-axis verdict space, the explicit output-binding mechanism, and the willingness to state what is not demonstrated (endorsement chains, AR4SI/EAR serialization, a real hardware root, a measured model artefact). The executed experiment is small but reproducible in principle, with pinned tool versions. However, the experiment is a specification-compliance check against the author's own stand-in verifier, and it does not exercise the motivating swapped-model scenario with an actual model artefact. These gaps do not invalidate the architecture, but they do mean the paper's central claim is supported only conditionally.
major comments (2)
- [§6, Table 1 (Case B); §7, second honest limitation; abstract] The experiment's Case B perturbs a stand-in tagged digest in PCR 3, not a hash of a real model binary. The paper's motivating question is whether a claimed model version actually produced an output; the demonstrated Contested verdict only shows that a PCR mismatch against a manually recorded good state is detected. The flagship (Authorised, Contested) failure for a swapped model is therefore not actually exercised. This is load-bearing because the abstract's central claim is about 'the specific model version'. Either extend the experiment to measure a real model artefact (e.g., extend a SHA-256 of the model file into a PCR at load time, or use an IMA-style measurement), or explicitly reframe the claim as platform-state attestation with model measurement as a stated precondition for the model-version question.
- [§6 'Results' and second caveat; §5 mapping] The 'verifier' is an author-written stand-in that performs signature, freshness, and PCR-reference checks but not endorsement appraisal, CoRIM ingestion, or AR4SI/EAR serialization. The reported Attested/Contested/Expired outcomes are thus conformance of the implementation to the author's own design, not independent validation against a real RATS verifier or against the §5 mapping. The paper already flags this, but the wording in the abstract ('Veraison ... supply exactly this') and in §6 ('the checks a Verifier performs') overstates the evidential weight. At minimum, the abstract and results should state explicitly that the experiment validates only the binding mechanics and the stand-in verdict logic, not a RATS-compliant appraisal.
minor comments (4)
- [Abstract, §4] Several missing spaces: 'acomposite', 'anoutput-bindingprotocol', 'atrust' (Abstract), and similar in §4. These are typographical but should be fixed.
- [Figure 1 and §6] The caption says all nine pairs are reachable, but the text does not give a concrete scenario for each pair (e.g., how Unauthorised+Attested arises). A short list of example scenarios would make the matrix more convincing.
- [§6, fifth caveat] The Expired case (Case C) tests only nonce freshness, not the lapsed-endorsement or EAT 'exp' paths. This is stated, but the term 'Expired' is used in the abstract and table as if the full semantics were exercised. A sentence in the results section noting this would avoid overreading.
- [Data and code availability] The run package is 'available on request' rather than publicly deposited. Given the emphasis on verifiable provenance, a public repository with the deterministic run script and results.json would strengthen reproducibility.
Circularity Check
No significant circularity: the paper is an architecture-plus-feasibility demonstration with one minor non-load-bearing self-citation; the swapped-model gap is an acknowledged limitation, not a circular derivation.
full rationale
The central claim is a proposal to compose RATS hardware Evidence with a software AEP, plus a small executed feasibility experiment on swtpm. No load-bearing step reduces to its own inputs by construction. The six-term vocabulary in §5 is explicitly a proposed mapping onto RATS appraisal outcomes; §6 then exercises that mapping with a stand-in verifier the author wrote. As the paper itself says, the stand-in 'resolves the three platform outcomes as designed' and the result is 'a feasibility demonstration on emulated hardware, not a hardware-rooted guarantee.' That is a specification-compliance check, not an empirical prediction, and it does not become circular because the verifier logic encodes the same conditions as the desired verdicts — the paper claims feasibility, not discovery. The only self-citation is [4], the author's prior AEP dataset, cited in §7 as a companion; it is not load-bearing because the AEP concept and the need for a hardware layer are argued from first principles in §§1–4 and anchored to external standards (RFC 9334, RFC 9711, Veraison, Keylime, SGX, IMA). The paper's genuine weakness is flagged by the paper itself: §7 states that attesting a model version specifically 'requires that the model artefact be measured into the attested state, which is an engineering commitment not all deployments make today,' and §6 admits Case B 'perturbs a stand-in digest in PCR 3 rather than re-measuring an actual model binary.' This means the flagship (Authorised, Contested) failure is demonstrated only for a synthetic register value, not for a real model swap — a validation gap, not a circularity. No equations are defined in terms of the conclusion, and no fitted parameter is relabeled as a prediction. Score 2 reflects only the single minor self-citation; the derivation itself is self-contained.
Axiom & Free-Parameter Ledger
axioms (4)
- domain assumption A TPM 2.0 quote signs PCR values with a key held by the TPM, and PCR extend is a one-way accumulation.
- domain assumption The RATS separation of Attester, Verifier, and Relying Party is realizable and the Verifier can be independent of the operator.
- standard math SHA-256 is collision-resistant for the output-binding digest.
- domain assumption swtpm faithfully reproduces TPM 2.0 PCR-extend and quote-signing behavior for the feasibility demonstration.
Cite this review
Pith. "Pith review of Hardware-rooted attestation for AI-agent evidence: composing IETF RATS with action evidence packages." pith.science (2026). https://pith.science/paper/KF4Y4NVU
@misc{pith2026260800801,
author = {Pith},
title = {Pith review of: Hardware-rooted attestation for AI-agent evidence: composing IETF RATS with action evidence packages},
year = {2026},
howpublished = {\url{https://pith.science/paper/KF4Y4NVU}},
note = {Machine review of arXiv:2608.00801}
}
read the original abstract
An action evidence package (AEP) is a signed, append-only record of what an AI agent did, who or what authorised the action, and what the outcome was. It is a software-layer artefact: it tells a verifier the story of an action as the agent's own runtime reports it. This note argues that software attestation of this kind is necessary but not sufficient. When a verifier's question shifts from "what does the agent claim it did?" to "did the specific model version the operator claims to have deployed actually produce this output, on unmodified hardware?", the AEP alone cannot answer. The missing element is a hardware root of trust: an attestation that the measured boot and runtime state of the platform match an endorsed reference. The IETF Remote Attestation Procedures (RATS) architecture (RFC 9334) and Veraison, an open-source RATS Verifier implementation (Confidential Computing Consortium / Linux Foundation), supply exactly this. We propose a composite attestation: hardware Evidence appraised under RATS, bound to a software AEP. We map a small verifier vocabulary (Authorised / Unauthorised / Indeterminate / Attested / Contested / Expired) onto RATS appraisal outcomes, and demonstrate feasibility with a small executed experiment: on a software Trusted Platform Module (TPM; the swtpm emulator), an output-binding protocol folds the hash of an AEP outcome and a fresh appraiser nonce into an attestation-key-signed quote, with a model-artefact measurement carried in a platform register. A minimal RATS-Verifier stand-in resolves the three platform outcomes as designed -- Attested for a good, fresh quote; Contested when the model measurement is swapped; Expired when a stale quote is replayed -- and rejects a forged AEP outcome bound to a valid quote. The result is a feasibility demonstration on emulated hardware, not a hardware-rooted guarantee.
Figures
Reference graph
Works this paper leans on
-
[1]
Remote ATtestation procedureS (RATS) Architecture,
H. Birkholz, D. Thaler, M. Richardson, N. Smith, W. Pan, “Remote ATtestation procedureS (RATS) Architecture,” RFC 9334, IETF, January 2023 (Informational). Freshness mechanisms: §10
work page 2023
-
[2]
Project Veraison (VERificAtIon of atteStatiON), open-source RATS attestation-verification components, originated at Arm and donated to the Confidential Computing Consortium (Linux Foundation). https://github.com/veraison
-
[3]
The Entity Attestation Token (EAT),
L. Lundblade, G. Mandyam, J. O’Donoghue, C. Wallace, “The Entity Attestation Token (EAT),” RFC 9711, IETF, 2025 (Proposed Standard). 8
work page 2025
-
[4]
A. Sokolov, “Evidence instrumentation for AI-governance review: underlying data and extended materials for three public-source practitioner use cases,” Zenodo, 2026 (dataset, CC BY 4.0). doi:10.5281/zenodo.20488643. [Keylime] N. Schear, P. T. Cable II, T. M. Moyer, B. Richard, R. Rudd, “Bootstrapping and Maintaining Trust in the Cloud,” Proc. 32nd Annual ...
discussion (0)
Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.