Pre-Execution Agent Enforcement Evidence: A Completeness Specification
This specification defines what makes a pre-execution agent enforcement record complete. It states eight requirements and two conformance levels. A record that satisfies the first seven is a tamper-evident log; a record that also satisfies the eighth — irreversible sequence sealing — is closed evidence. The dividing line is a single property: whether the record can still be added to, or has been fixed in time. This document names no product but its own reference implementation. It is offered as a neutral measure against which any enforcement record, from any vendor, can be assessed by the reader.
1. Purpose and Scope
Regulatory and standards frameworks for AI — EU AI Act Article 12, ISO/IEC 42001, NIST AI RMF — require that high-risk and agentic AI systems produce traceable, tamper-evident records of their decisions. They state that records must exist and must have integrity. They do not specify the structure of a complete enforcement record, nor the property that separates a record an adversary could revise from one they could not. ISO/IEC FDIS 24970 (transparency and traceability), still pre-publication, points toward the same requirement without yet being in force — this specification anticipates, rather than implements, whatever it ultimately settles on.
This specification fills that descriptive gap. It is not a regulation and confers no compliance. It is a measuring stick: a precise statement of the requirements a pre-execution enforcement record must satisfy to function as evidence — not merely as a log — when the operator of the AI system is itself the party under examination.
The scope is the enforcement record: the artefact generated by an enforcement layer at the moment an AI agent proposes an action, before that action executes. It is not concerned with model behaviour, output content, or post-hoc application logging.
2. The Central Distinction — Record versus Evidence
Most controls that protect an audit trail protect it during operation. Each entry is signed, so each entry is authentic. The entries are hash-linked, so a past entry cannot be silently rewritten. These are necessary and they are not sufficient, because they leave one question unanswered: is this the complete account, fixed at the time — or could material have been added, extended, or reframed afterward, once there was a reason to?
An append-only log cannot answer that question, because it never closes. Hash-chaining proves no past entry was altered; it does not prove the record is finished. A record that can always grow can be grown under pressure — after the incident, during the audit, in litigation. That is precisely the manipulation an adversarial operator would attempt, and it is the one manipulation a perpetually-open log cannot foreclose.
The property that closes the question is finality: the sequence is sealed at a terminal step, after which no entry may be appended, no entry altered, and the sequence may not be reopened. Finality converts a running log into a closed exhibit. The signatures prove each line is authentic; the seal proves the set is complete and was fixed in time. These are different guarantees. This specification requires both.
The distinction has a one-word name: append versus seal. Everyone who keeps a record appends. A complete record, in the sense defined here, also closes.
An analogy. The seal is the earth pin of an enforcement record — the third prong. It carries no payload and makes the system run no faster; like a safety ground, its only function is to hold when something faults. A logging-grade record is a two-prong device: it works, it looks complete, and it has had the ground removed. The omission is invisible until the fault — the incident, the dispute, the moment the operator is the party under examination — at which point there is no safe path and the record cannot bear the load. A system may be safe without a ground only where an equivalent safety architecture is engineered in its place; removing the ground to reduce cost or latency and engineering nothing in its stead is not a design trade-off but an unmitigated hazard.
3. The Eight Requirements
A pre-execution enforcement record is complete if and only if the enforcement layer that produces it satisfies all eight requirements below. Each requirement states the property, why it is necessary, and the established security principle it derives from. None of these principles is new; the contribution of this specification is to state, as a single closed set, which of them an enforcement record must satisfy together to function as evidence.
R1 — Pre-Execution Mediation
The record is created before the proposed action executes, by an enforcement layer the agent cannot read, write, or influence. A record written by the system whose behaviour it describes is testimony; a record written by an independent layer in the action's path is evidence. Derives from: complete mediation (Saltzer & Schroeder, 1975) and the reference monitor's always-invoked property (Anderson, 1972). A denial at this layer must itself be recorded — a DENY record is proof the gate was active and refused, for an action that never ran.
R2 — Deterministic Decision
The enforcement decision is a function of its inputs alone: same inputs, same decision, with no sampling, no temperature, no time-dependent branch. A probabilistic gate cannot produce a reproducible record and cannot be independently re-derived by a verifier. Derives from: reference-monitor theory; decidable policy evaluation over a finite domain.
R3 — Signed, Offline-Verifiable Receipt
Each record carries a cryptographic signature over the canonical serialisation of its own fields, verifiable by any party offline against a published key, with no call back to the issuer. Derives from: EdDSA / Ed25519 (RFC 8032) over a deterministic canonical form such as the JSON Canonicalization Scheme (RFC 8785); the open-design principle (Saltzer & Schroeder, 1975; Kerckhoffs). A symmetric (HMAC) signature satisfies authenticity but not third-party verifiability and so is insufficient on its own.
R4 — Signer Isolation
The signing authority is isolated from the system being recorded: the agent and its operator can neither extract the signing key nor forge or alter a record. This is the requirement that separates evidence from a log. A record the subject can sign for itself is a diary; only a record signed by a party the subject cannot reach survives the subject becoming the suspect. Derives from: the reference monitor's tamperproof property (Anderson, 1972); separation of privilege and least common mechanism (Saltzer & Schroeder, 1975). Isolation may be achieved by an air-gapped signer, an HSM, a hardware enclave, or a key held by an independent party; the requirement is the isolation, not the means.
R5 — Replay Protection
Each step carries a single-use value (a nonce); any reuse within the sequence is refused and recorded, and a freshness window bounds delayed replay. Without this, a captured valid record can be re-presented as a new one. Derives from: anti-replay sequencing (e.g., RFC 6479); standard nonce/challenge construction.
R6 — Total Step-Order Enforcement
The steps of a sequence are subject to a single defined total order; a step presented out of order is refused and recorded as such. Order is enforced as a precondition of execution, not reconstructed afterward. Derives from: total ordering of events and state-machine replication (Lamport, 1978).
R7 — Chain Integrity
Each record references the cryptographic hash of its predecessor, so that tampering with, inserting, deleting, or reordering any record breaks the chain and is detectable without examining each record in isolation. Derives from: hash-chaining and Merkle linking (Merkle, 1979); the same construction underlies Certificate Transparency (RFC 6962). Chain integrity is necessary but, on its own, describes an open log — see R8.
R8 — Irreversible Sequence Sealing (the dividing line)
The sequence terminates at a sealing step, after which no record may be appended, no record altered, and the sequence may not be reopened. The complete account is fixed at the moment of sealing. This is the requirement that distinguishes the two conformance levels in §4, and the requirement most enforcement records do not meet — because the dominant pattern, the perpetually-open transparency log, is engineered precisely never to close. Derives from: finality and terminal-state monotonicity; an append-then-close commitment, the deliberate inverse of the append-only log of R7's lineage. R7 proves the past was not rewritten; R8 proves the account is finished.
4. Conformance Levels
Two levels are defined. The boundary between them is R8 alone.
| Level | Requirements | What it proves — and what it cannot |
|---|---|---|
| Logging-grade | R1–R7 | Tamper-evident, ordered, signed, replay-protected. Proves no past record was silently altered. Cannot prove the account is complete or was fixed in time, because the record never closes and can always be extended. |
| Evidence-grade | R1–R8 | All of the above, and sealed. The sequence is closed and the complete account fixed at the moment of sealing. Nothing can be added, removed, or reframed after the fact — including by the operator, after an incident. |
A reader assessing any enforcement product can place it on this scale without the vendor's cooperation: identify which requirements its records satisfy. Most agent audit records available today are logging-grade. The step from logging-grade to evidence-grade is not incremental hardening — it is the single, categorical act of closing the record. That is the completeness test.
5. The Completeness Test
Ask of any enforcement record: can it still be appended to? If yes, it is logging-grade — admissible, useful, and revisable. If no — if the sequence is sealed and the account fixed in time — it is evidence-grade. The claim "this is the complete record as it stood at the moment of the event" can only be made by an evidence-grade record, because only a closed record has a moment it was completed.
This specification takes no position on which level a given application requires. For an honest-operator audit, logging-grade may be entirely adequate. The distinction becomes decisive only in the adversarial case — when the party who controls the record is the party whose conduct is in question. There, a revisable record is a record the suspect could have shaped, and only an evidence-grade, sealed record stands.
What an auditor tests, and which requirement answers it
An auditor rarely asks for "an audit log". They test a record against a small number of named criteria. The eight requirements above map onto those criteria directly, and the mapping is set out here so that a reader arriving with an auditor's checklist can find the corresponding requirement without having to translate vocabulary.
| What the auditor tests | Requirement |
|---|---|
| Completeness — every material action is captured, including the ones that were refused, not only the ones that succeeded. | R1, R6, R8 |
| Tamper-evidence — the record cannot be altered after the fact by the system that produced it without the alteration being detectable. | R3, R7 |
| Traceability — a given entry maps to a specific step in the documented process, rather than to an undifferentiated stream of events. | R6, R7 |
| Independent generation — the evidence is a byproduct of the system running, generated outside the component under examination, rather than assembled afterwards by the party being audited. | R1, R4 |
| Timestamping and retention — times are bound into the signed record and the record persists for a stated period. | R3, R5 for timestamping; retention is not specified here |
Two of these warrant a caution rather than a claim. Independent generation is satisfied with respect to the agent, which can neither instruct the gate nor edit its output; it is not satisfied with respect to the operator of the gate, and no requirement in this specification asserts otherwise. Timestamping means the recorded time is bound into the signed record and cannot be altered afterwards without breaking verification; it does not establish that the recorded time is true, because that value is asserted by the recording system itself. Retention is a matter of an operator's policy and this specification takes no position on it.
6. Reference Implementation — slp8_receipt_v2
The slp8_receipt_v2 receipt schema is offered as one conformant, evidence-grade reference implementation of this specification. It is named here as the author's own implementation; it is not the only possible one, and this specification is implementation-independent.
| Requirement | Reference mechanism |
|---|---|
| R1 Pre-execution mediation | Enforcement gate evaluates every step before the agent acts; the air-gapped core is unreachable by the agent. DENY receipts record refused actions that never executed. |
| R2 Deterministic decision | Policy evaluation over a fixed policy map; no sampling. Same payload yields the same decision. |
| R3 Signed, offline-verifiable | Ed25519 signature over canonical JSON of the receipt; verifiable against the published keyring at /spec/receipt-public-keys.json with no callback. |
| R4 Signer isolation | The Ed25519 signing key resides only in the air-gapped core; the public surface can neither read nor forge it. |
| R5 Replay protection | Per-step nonce; reuse returns REPLAY_NONCE. Freshness window |ts_ms − now| ≤ 300s returns STALE_TIMESTAMP. |
| R6 Total step-order | Single defined step order per sequence; out-of-order returns SEQUENCE_VIOLATION carrying expected_step. |
| R7 Chain integrity | prev_receipt_id (predecessor's pack_id — ordering) plus prev_receipt_hash (SHA-256 of the predecessor's full canonical form, added 2026-07-08 — content integrity). Tamper, insertion, and reorder break the chain. |
| R8 Irreversible sealing | sealed set at the terminal step; any further step returns SEALED_SEQUENCE. A sealed sequence cannot be reopened without leaving a detectable break in the prev_receipt_hash chain. |
| Property | Value |
|---|---|
| Schema | slp8_receipt_v2 — JSON Schema Draft 2020-12, /spec/receipt-schema.json |
| Active signing | Ed25519 — key ID k2_2026-06-07_ed25519 |
| Legacy signing | HMAC-SHA256 — key ID k1_2026-02-22_01 — retained verify-only |
| Public keys | /spec/receipt-public-keys.json — Ed25519 JWKS + SPKI |
| Public verification | report.agenticrail.nz/report — no login for demo sequences |
7. Relationship to Existing Frameworks
This specification operates beneath the traceability requirements of the major AI governance frameworks. It does not restate them and does not claim conformance to them; conformance to any regulation is assessed at the system and documentation level, not by a record format. The relationship is one of grade.
| Framework requirement | Relationship to this specification |
|---|---|
| EU AI Act — Article 12 (record-keeping / logging) and Article 15 (integrity, resilience to tampering) | A logging-grade record satisfies the literal floor. Evidence-grade adds the integrity that holds when the operator is the party under examination — the case Article 15's resilience language reaches toward but does not specify by mechanism. |
| ISO/IEC 42001 (AI management system — operational records) | Evidence-grade records provide management-system audit artefacts that remain valid against an adversarial reading, not only an honest one. |
| NIST AI RMF (Measure / Manage — traceable decisions) | The completeness requirements specify the structure of the traceable enforcement decision the framework presumes. |
| ISO/IEC FDIS 24970 (transparency and traceability) — pre-publication, not yet in force | This specification supplies the enforcement-record structure and the finality property identified as absent in the 24970 gap analysis (see Related). |
A deliberate boundary of terms. This document defines complete — a property of a record. It does not define compliant — a determination about a system, made by a regulator or auditor. A record may be evidence-grade and the surrounding system non-conformant, or the reverse. The two words are kept apart on purpose.
8. Related Documents
The v1.0 and v1.1 fingerprints above are permanent and unchanged. v1.2 corrects the §6 Reference Implementation table's R7 row, which attributed content-tamper detection to prev_receipt_id alone — that field is an identifier reference (predecessor's pack_id, establishing order); it does not by itself prove the predecessor's content is unchanged. A new field, prev_receipt_hash, was added to slp8_receipt_v2 on 2026-07-08 to actually provide that property, and the table is corrected to attribute it there. The abstract R7 requirement definition in §3 was already written correctly (framework-level, not implementation-specific) and is unchanged. Neither v1.0 nor v1.1 is edited; v1.2 is a separate, independently-fingerprinted record.
The v1.0, v1.1 and v1.2 fingerprints above are permanent and unchanged. v1.3 adds the auditor-criteria mapping in §5, which introduces no requirement and changes none, and corrects the §6 Reference Implementation table's R8 row. That row stated that no unsealing mechanism exists. This was stronger than the evidence supports: what holds is that a sealed sequence cannot be reopened without leaving a detectable break in the prev_receipt_hash chain, and that a full downstream rewrite by a holder of the signing key is caught by an independently held copy rather than by the chain alone. The abstract R8 requirement in §3 is unchanged and the R8:irreversible sequence sealing canonical token is unchanged, so the requirement vocabulary is stable across all four versions. No earlier version is edited; v1.3 is a separate, independently-fingerprinted record.