# AgenticRail — Full-Text Mirror for AI Agents > Every markdown mirror on this site, concatenated into one file, generated 2026-07-23 from the live pages. For a short summary, a one-sentence accurate citation, and pointers to individual pages, read https://agenticrail.nz/llms.txt first — this file is the long form, for an agent that wants everything in a single fetch rather than many small ones. --- # What's the Difference Between an Asserted and a Provable AI Safeguard? — AgenticRail > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/spec/enforceable-safeguards/ > Site context: https://agenticrail.nz/llms.txt **Document type** Public-Sector Note — Evidence Brief **Subject** Automated decisions in the New Zealand public sector — what makes a safeguard provable **Published by** TUARA KURI LIMITED — trading as AgenticRail, Hokianga, Aotearoa New Zealand **Date** 2026-07-17 **Version** 1.0 **Status** Published — open for citation **Related** [Completeness specification](https://agenticrail.nz/spec/completeness/) · [NZ health evidence brief](https://agenticrail.nz/spec/nz-health/) # Automated Decisions and the Provable Safeguard From 1 July 2026, New Zealand law permits the Ministry of Social Development to make benefit decisions by automated electronic system, *"with appropriate safeguards"* [1][2]. The public debate has asked whether the safeguards are adequate. This note asks a narrower and more answerable question: **whatever the safeguards are, what would make them *provable* — rather than merely asserted?** It distinguishes three tiers of safeguard — asserted, enforced, and provable — documents, from the public record, why the difference between them decided the two most consequential automated-decision failures of the past decade, and describes a verification anyone can run in about five minutes. It asserts no failure by any New Zealand agency. It documents a structural distinction, and identifies the instrument the highest tier requires. ## 1. Scope This is a technical note, not a submission on policy. It takes no position on whether any decision should be automated, and it names no individuals. The overseas failures cited in §3 are historical, documented by royal commission and by human-rights investigation, and are cited as evidence of a *structural pattern* — not as a prediction about any New Zealand programme. Throughout, the same distinction is held as in the companion health brief [12]: a **record** may exist and still be revisable, incomplete, or internal; **evidence** is a sealed, contemporaneous record a party outside the operating agency can verify without trusting the agency. The gap this note describes is in the second. ## 2. The Commitments — what has been promised **Welfare.** The Social Security (Modernisation) Amendment Act, passed under urgency on 29 May 2026, allows MSD to *"approve the use of an automated electronic system … to make any decision, exercise any power, comply with any obligation, or take any other related action under any specified provision, with appropriate safeguards"* [1]. The stated safeguards include human oversight and protections against bias [1]. MSD describes the class of decisions to be automated precisely: *"a rules-based decision is made using clear, set criteria based on the information we have about a client, where no discretion is required"* [1][2]. **Assessment.** NZQA has marked more than 55,000 literacy Writing assessments using an Automated Text Scoring tool since May 2025, with *"results quality assured by human check-marking"* — experienced markers re-checking over a third of results, concentrated at the achievement boundary, with the human mark prevailing wherever the two differ [3][4]. NZQA's published commitments place this under five principles of the Public Service AI Framework, ending in **Accountability**, and describe the posture as *"human at the helm"* [4][5]. Neither agency's statement is doubted here. Both are taken at face value, and both are commendably specific. The question this note asks is structural: **what instrument records that the promised safeguard operated — each time, in order, before the decision issued — in a form someone outside the agency could check?** At present, in both cases, the public answer is the agency's own account of its own process. That is not an accusation. It is the definition of an *asserted* safeguard, and until recently it was the only kind available. ## 3. The Failure Shape — what actually broke, twice **Australia — Robodebt.** Australia's automated debt-raising scheme is remembered as an AI failure. It was not. There was no model, no learning, no black box. It was a *sequence* failure: the scheme's lawful process required actual fortnightly income to be verified before a debt was raised, and the automated system **skipped that step** — substituting an annual average — and raised the debt anyway, hundreds of thousands of times. The scheme was found unlawful; a settlement approaching A$1.8 billion followed; a Royal Commission reported in 2023 [6][7]. Two structural facts matter for this note. First, the failing step was not exotic — it was a known, nameable, required verification that the system was permitted to proceed without. Second, establishing *what the system had actually done, to whom, in what order* took years of forensic reconstruction, because nothing had recorded the integrity of the process at the moment each decision was made. **The Royal Commission was archaeology. It could have been a lookup.** **The Netherlands — the childcare benefits scandal.** The Dutch tax authority's fraud-detection process wrongly accused roughly 26,000 parents of fraudulent benefit claims, with documented discriminatory effect; families were ruined, children were taken into care, and the government resigned over it in 2021 [8]. Here too, the decisive harm was not a clever algorithm but a process in which required checks — proportionality, human reconsideration, lawful data use — were asserted to exist and could not be shown to have operated in the individual case, until reconstruction after the fact. The pattern In both failures, a safeguard existed on paper. In neither case did the system *structurally require* the safeguard step before proceeding, and in neither case did any decision leave a contemporaneous, tamper-evident record that the step had run. The safeguard was **asserted**. It was neither **enforced** nor **provable** — and the difference was measured in years of inquiry, billions in remediation, and lives. ## 4. Three Tiers of Safeguard | Tier | Definition | What it survives | | **Asserted** | A policy, press release, or framework states that the check happens. The system itself does not require it, and no independent record is produced. | Good faith and good weather. Robodebt operated for years at this tier with its safeguards formally in place. | | **Enforced** | The system structurally cannot proceed past a skipped or out-of-order step. A decision with a missing safeguard step is not "flagged" — it is *denied before execution*. | Load, haste, and drift — the ordinary conditions under which asserted checks quietly stop happening. Protects the agency in real time. | | **Provable** | Every decision leaves a cryptographically signed, sealed, tamper-evident receipt of the steps that ran, in order — verifiable by a party outside the agency, offline, against published keys, without trusting the agency's servers. | The inquiry. When a decision is challenged — by a review, an Ombudsman, a court, a journalist — the account of process integrity already exists, fixed at decision time, and checking it is minutes, not years. | The tiers are cumulative in value but separable in mechanism: enforcement without proof protects the agency while it operates; proof without enforcement at least documents violations honestly. Together they are the difference between *"our safeguards are appropriate"* and *"here is the evidence, check it yourself."* ## 5. The Observation — rules-based decisions are the easy case MSD's own description of what will be automated — *"a rules-based decision … using clear, set criteria … where no discretion is required"* [1] — is, in technical terms, a **declared sequence**: a finite set of named steps with defined inputs and a defined order. NZQA's check-marking commitment has the same shape: score, then human check at the boundary, then release. This matters because the declared sequence is precisely the case in which enforcement and proof are *cheapest and strongest*. None of the open philosophical problems of AI safety — alignment, interpretability, emergent behaviour — need solving to make a rules-based decision provable. The step order is already written down. What is missing is only the instrument that (a) refuses to let a step run out of order, and (b) seals a verifiable record that it didn't. ## 6. The Instrument — and a five-minute test The requirements for an evidence-grade record are specified, neutrally and vendor-independently, in the companion [Completeness Specification](https://agenticrail.nz/spec/completeness/): created before the action, independent of the system being recorded, cryptographically signed and offline-verifiable, and irreversibly sealed so the account cannot later be reopened or rewritten without detection. Applied to an automated benefit decision Each decision declares its steps up front — inputs read, criteria applied, human review where the rules require one, decision issued, sequence sealed. An external gate evaluates every step *before it runs*: a step out of order, a skipped review, a replayed or stale request is denied, not logged. Each allowed step produces a signed receipt chained to the one before; at the final step the sequence seals. Anyone — the client, their advocate, a reviewer, a reporter — can verify the signatures and the chain offline against published keys, with no call back to the operator. The safeguard stops being a sentence in a press release and becomes a checkable object. **The test.** This claim is designed to be checked rather than believed, and checking it takes about five minutes: 1. Run the [live demo](https://agenticrail.nz/demo/) — it executes a real multi-step sequence against the production gate and shows each step being allowed, denied, or sealed. Note the sequence ID it gives you. 2. Paste that ID into the [verification tool](https://report.agenticrail.nz/report) — the report returns every receipt with its raw signature and the exact signed bytes. 3. Verify independently: fetch the [published public keys](https://agenticrail.nz/spec/receipt-public-keys.json) and run standard Ed25519 verification over any receipt in your own code, offline. Then flip one character in the signed content and watch it fail. The full API contract is in the [documentation](https://agenticrail.nz/docs/). What a pass demonstrates: the record of the sequence is signed, ordered, sealed, and verifiable by you — a party with no relationship to the operator, using no code of the operator's, making no network call to the operator. That is what tier three feels like from the outside, and it is the test any vendor of "safeguards" — this one included — should be held to. ## 7. A Deliberate Boundary — what this does not do An enforcement receipt does **not** make a decision correct. It does not detect a biased rule, does not compensate for flawed data, and does not replace review, appeal, or the human judgement the rules require — it witnesses that judgement's place in the sequence; it cannot witness its quality. A wrong rule, faithfully followed, produces impeccable receipts of a wrong rule being followed. That limitation is also the point. When every decision carries a verifiable account of *what ran, in what order, against which criteria*, the dispute narrows to where it belongs: the rule itself, examined in the open — rather than years of forensic argument about what the system even did. Robodebt's victims did not primarily lack a better algorithm. They lacked, for years, any means of showing what had been done to them. The receipt is that means, held in advance. And to be plain about the home ground: this note asserts **no failure, breach, or bad faith by MSD, NZQA, or any New Zealand agency**. Both agencies named here have made their safeguard commitments publicly and specifically, which is to their credit — and is exactly what makes the commitments capable of being made provable. ## 8. References [1] "New law allowing automated benefit decisions to modernise welfare system, government says," RNZ News, 30 May 2026 — [rnz.co.nz](https://www.rnz.co.nz/news/political/596791/new-law-allowing-automated-benefit-decisions-to-modernise-welfare-system-government-says) [2] "Modernising our processes," Work and Income / MSD, 2026 (automation in effect from 1 July 2026) — [workandincome.govt.nz](https://www.workandincome.govt.nz/about-work-and-income/news/2026/modernising-our-processes.html) [3] "Embracing AI in student assessments," NZQA — [nzqa.govt.nz](https://www2.nzqa.govt.nz/about-us/news/embracing-ai-in-student-assessments/) [4] "NZQA's Responsible Use of Artificial Intelligence," NZQA, 5 Sep 2025 — [nzqa.govt.nz](https://www2.nzqa.govt.nz/about-us/news/nzqas-responsible-use-of-artificial-intelligence/) [5] Public Service AI Framework, digital.govt.nz — [digital.govt.nz](https://www.digital.govt.nz/standards-and-guidance/technology-and-architecture/artificial-intelligence/) [6] Royal Commission into the Robodebt Scheme, Final Report, July 2023 — [robodebt.royalcommission.gov.au](https://robodebt.royalcommission.gov.au/) [7] "$55m less in benefit payments as Govt automates welfare decisions under urgency," Newsroom, 29 May 2026 — [newsroom.co.nz](https://newsroom.co.nz/2026/05/29/55m-less-in-benefit-payments-as-govt-automates-welfare-decisions-under-urgency/) [8] "Xenophobic machines: Discrimination through unregulated use of algorithms in the Dutch childcare benefits scandal," Amnesty International, Oct 2021 — [amnesty.org](https://www.amnesty.org/en/documents/eur35/4686/2021/en/) [12] "AI in New Zealand Health Care: The Missing Evidence Layer," TUARA KURI LIMITED, 2026 — [agenticrail.nz/spec/nz-health/](https://agenticrail.nz/spec/nz-health/) Document Fingerprint — SHA-256 — v1.0 1733513deb9ce0c77d47d667ad85bc616fb557194eaafec3eead8aa8553583f5 This hash is SHA-256 of the canonical string defined below. It is reproducible independently of this page using any SHA-256 implementation. **Canonical string (pipe-delimited, UTF-8, no trailing newline):** `Automated Decisions and the Provable Safeguard|1.0|2026-07-17|TUARA KURI LIMITED|Social Security Modernisation Amendment automated decisions with appropriate safeguards from 2026-07-01|MSD rules-based decision clear set criteria no discretion|NZQA ATS 55000 writing assessments human check-marking human at the helm|three tiers asserted enforced provable|Robodebt sequence failure skipped verification step royal commission archaeology could have been a lookup|Dutch childcare scandal asserted checks unprovable in the individual case|declared sequence is the easy case|receipt does not make the decision correct it narrows the dispute to the rule|completeness R1-R8|report.agenticrail.nz` Published: 2026-07-17 | Version: 1.0 | Entity: TUARA KURI LIMITED **Sourcing note:** every factual claim about the New Zealand programmes in §2 and the overseas failures in §3 is cited to a primary or named source in §8. This note asserts no failure, breach, or bad faith by any New Zealand agency, and names no individuals. --- # What Makes an AI Enforcement Record Evidence-Grade Instead of Just a Log? — AgenticRail > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/spec/completeness/ > Site context: https://agenticrail.nz/llms.txt **Document type** Specification — Evidence Completeness Requirements **Subject** Pre-execution AI agent enforcement records **Published by** TUARA KURI LIMITED — trading as AgenticRail, Hokianga, Aotearoa New Zealand **Date** 2026-06-24 **Version** 1.2 — supersedes v1.1 (2026-06-24) **Status** Published — open for citation and standards contribution **Related** DIS 24970 gap analysis · slp8_receipt_v2 schema · enforcement specification # 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 The one-line 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. ## 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](https://agenticrail.nz/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`. No unsealing mechanism exists. | | Property | Value | | **Schema** | `slp8_receipt_v2` — JSON Schema Draft 2020-12, [/spec/receipt-schema.json](https://agenticrail.nz/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](https://agenticrail.nz/spec/receipt-public-keys.json) — Ed25519 JWKS + SPKI | | **Public verification** | [report.agenticrail.nz/report](https://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 **Receipt schema** — slp8_receipt_v2 JSON Schema (Draft 2020-12) · [agenticrail.nz/spec/receipt-schema.json](https://agenticrail.nz/spec/receipt-schema.json) **Verification keys** — Ed25519 JWKS + SPKI · [agenticrail.nz/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json) **Enforcement specification** — canonical enforcement spec · [agenticrail.nz/spec/](https://agenticrail.nz/spec/) **Live verification** — [report.agenticrail.nz/report](https://report.agenticrail.nz/report) · No login required for demo sequences Document Fingerprint — SHA-256 — v1.1 (superseded by v1.2 below) 5cd84b51cd0b7309b15dd1581c227d240c6c29a01e4c7b16500b2353cdf25fd4 This hash is SHA-256 of the canonical string defined below. It is reproducible independently of this page using any SHA-256 implementation. **Canonical string (pipe-delimited, UTF-8, no trailing newline):** `Pre-Execution Agent Enforcement Evidence: Completeness Specification|1.1|2026-06-24|TUARA KURI LIMITED|R1:pre-execution mediation|R2:deterministic decision|R3:signed offline-verifiable receipt|R4:signer isolation|R5:replay protection|R6:total step-order|R7:chain integrity|R8:irreversible sequence sealing|logging-grade|evidence-grade|append-then-close|seal-is-the-earth-pin|slp8_receipt_v2|Ed25519|k2_2026-06-07_ed25519|report.agenticrail.nz` Published: 2026-06-24 | Version: 1.1 (supersedes v1.0) | Active key ID: k2_2026-06-07_ed25519 **v1.1 (2026-06-24):** adds the earth-pin safety-ground analogy to §2 and structured metadata; the canonical string above carries the `seal-is-the-earth-pin` token, so this fingerprint supersedes the v1.0 hash `3f48198d662bb0d415509abaa01f880e31782bdbb8877c735d192521eb5353be`. 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. Document Fingerprint — SHA-256 — v1.2 2da590a70624c2de7b2edbe568ee5c74f482d65b405374debebad3f6f34efbb5 This hash is SHA-256 of the canonical string defined below. It is reproducible independently of this page using any SHA-256 implementation. **Canonical string (pipe-delimited, UTF-8, no trailing newline):** `Pre-Execution Agent Enforcement Evidence: Completeness Specification|1.2|2026-07-08|TUARA KURI LIMITED|R1:pre-execution mediation|R2:deterministic decision|R3:signed offline-verifiable receipt|R4:signer isolation|R5:replay protection|R6:total step-order|R7:chain integrity|R8:irreversible sequence sealing|logging-grade|evidence-grade|append-then-close|seal-is-the-earth-pin|slp8_receipt_v2|Ed25519|k2_2026-06-07_ed25519|report.agenticrail.nz` Published: 2026-07-08 | Version: 1.2 (supersedes v1.1, 2026-06-24) | Active key ID: k2_2026-06-07_ed25519 **v1.2 (2026-07-08):** the R1–R8 abstract requirements and canonical tokens are unchanged from v1.1 — only the version and date tokens differ, and only the §6 reference-implementation table (non-canonical prose) was corrected. This fingerprint supersedes the v1.1 hash `5cd84b51cd0b7309b15dd1581c227d240c6c29a01e4c7b16500b2353cdf25fd4`. --- # What's Missing From AI Safeguards in New Zealand Health Care? — AgenticRail > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/spec/nz-health/ > Site context: https://agenticrail.nz/llms.txt **Document type** Sector Gap Analysis — Evidence Brief **Subject** AI in New Zealand health care — the pre-execution evidence layer **Published by** TUARA KURI LIMITED — trading as AgenticRail, Hokianga, Aotearoa New Zealand **Date** 2026-06-24 **Version** 1.0 **Status** Published — open for citation **Related** Completeness specification · DIS 24970 gap analysis # AI in New Zealand Health Care: The Missing Evidence Layer New Zealand has deployed artificial intelligence into clinical documentation at national scale, and AI-guided treatment is now in clinical trial. The official safety position rests on two assurances: that *"the doctor reviews and confirms"* the AI's output, and that the tools *"meet all privacy requirements."* This brief documents — from primary New Zealand sources — that neither assurance is currently **recorded**: there is no sealed, tamper-evident, pre-execution record of what an AI produced, nor of whether a human verified it. The brief makes no claim of harm and alleges no breach of law. It documents a structural gap, and identifies the instrument that closes it. ## 1. Scope This is a sector brief, not a regulation, and it confers no compliance. It establishes three things from cited New Zealand sources: (a) the scale and form of AI deployment in NZ health care as of mid-2026; (b) the precise point at which the deployment's stated safeguards become *unverifiable* for want of a record; and (c) the structure of the evidence layer that would make those safeguards provable. Throughout, a careful distinction is kept between a **record** (which may exist and still be revisable or absent) and **evidence** (a sealed, contemporaneous, independently verifiable record). The gap is in the second. ## 2. The Deployment — what is in place **AI scribes, nationally.** As of 2026, AI "ambient" scribes — tools that record a consultation and automatically draft clinical notes, referral letters and summaries — are in use by approximately **1,250 emergency-department clinicians across all public EDs**, around 250 more than the initial October 2025 target, with a further **1,000 licences being procured for mental-health teams** [11][1][2]. By early 2026, roughly half of NZ GPs reported using some form of AI scribe. Four ambient scribes — **Heidi, iMedX, T-Pro and IntelliTek** — have been endorsed by a Health New Zealand advisory group; Heidi, the primary tool, was endorsed in July 2025 after a Hawke's Bay pilot reduced documentation time from 17 minutes to four [2][3]. **AI-guided treatment, in trial.** A New Zealand-led clinical trial across roughly 50 intensive-care units in NZ and Australia, recruiting more than **24,000 patients**, is testing whether AI can guide the treatment of critically ill patients on life support ($5M Health Research Council grant) [4]. This is the highest-consequence end of the spectrum: decisions that cannot be taken back. **The official safeguard.** The stated workflow is that the scribe produces a draft and *"the doctor reviews and confirms"* it; the responsible Minister has stated that *"AI will never replace clinical skill or judgement"* and that the tools *"meet all privacy requirements"* [1]. The entire safety case rests on the human-in-the-loop review and on privacy compliance. ## 3. The Gap — where the safeguards become unrecorded The structural gap The safety case depends on (a) a human reviewing the AI's output, and (b) that output being handled safely. Neither is captured in a sealed, pre-execution, tamper-evident record. There is no contemporaneous evidence of *what* the AI produced, *whether* a clinician reviewed it, *how* closely, or *on whose authority* a resulting decision was made. "The doctor reviews and confirms" is, at present, an assurance with no instrument behind it. Four documented findings show the gap is not theoretical: **3.1 — Unrecorded consumer-LLM use in clinical notes.** In March 2026, Health New Zealand mental-health and addiction staff were found to be using free, general-purpose chatbots — **ChatGPT, Claude and Gemini** — to draft clinical notes, in some cases transcribing the output into the record. A Rotorua Lakes district memo dated **26 March 2026** warned of disciplinary action, citing *"data security, privacy and accountability"*; HNZ's director of digital innovation and AI confirmed the tools "presented risks to data security, privacy and accountability." The reporting records no mechanism that captured *what those tools produced* or whether it was verified before entering a patient's record [5]. This is the evidence gap in its rawest form: an AI materially shaping a clinical note, leaving no sealed trace. **3.2 — Consent and oversight are patchy, and unrecorded.** An Otago survey of NZ primary-care providers using AI scribes found **41% were not seeking explicit patient consent**; only 66% had read the software's terms; 59% reported seeking consent [6]. The Medical Council guidance requires informed consent for scribe use, and that *whether consent was obtained* be documented (cl. 9–10) [8]. Where practice diverges from that requirement, the absence of a per-encounter sealed record means the divergence cannot be detected, audited, or disproved after the fact. **3.3 — A complaint is anticipated.** A clinical lead at Whakarongorau has stated that a complaint to the Health and Disability Commissioner over AI-scribe use without informed consent is *"only a matter of time"* [6]. A complaint is the *fault event* — the moment at which the absence of a contemporaneous, sealed record stops being abstract and becomes the difference between a defensible account and an unprovable one. **3.4 — A security flaw has already occurred.** A security flaw in a Health NZ AI tool was reported in March 2026 [7]. Whatever its scope, it establishes that the systems holding and processing clinical AI output are themselves subject to compromise — which is precisely the condition under which an externally signed, tamper-evident receipt, rather than a system-internal log, is the only record that still stands. ## 4. Why "Review and Confirm" Is Not Yet Evidence The human-in-the-loop is the load-bearing safeguard, and under time pressure it is the most fragile. Pilot data cited in support of the rollout notes that scribes let doctors see, on average, *one additional patient per shift* [1] — the same time saving that compresses the "review" of an AI draft toward a confirmation click. Whether a given confirmation was a considered clinical judgement or a reflex under load is exactly the fact that determines accountability if something goes wrong — and it is exactly the fact that nothing currently records. The Medical Council's own guidance makes the review a professional obligation, not a courtesy: it states that AI *"may produce inaccurate or fabricated information,"* and that a doctor *"should check the accuracy of any AI output and confirm it is appropriate for the individual patient before using it for patient care or including it in patient records"* [8]. The duty to verify is explicit. What is absent is any contemporaneous, tamper-evident record of *whether the verification actually happened* — leaving the central safeguard asserted but unprovable. A sealed pre-execution record resolves this without trusting anyone's memory: the time spent on a draft, the edits made or not made, and the explicit authority under which a decision proceeded, fixed at the moment it happened and verifiable afterward. It does not assume the review was real. It records *whether* it was. ## 5. Relationship to New Zealand's Existing Framework This brief operates beneath — not in place of — the instruments already governing the field. It restates none of them and claims conformance to none. | NZ instrument | What it requires | Where the evidence layer sits | | **Medical Council of NZ** — *Guidance on using AI in patient care* (10 Mar 2026) [8] | The doctor "remain[s] responsible for all your clinical decisions and actions"; AI "may produce inaccurate or fabricated information," so the doctor "should check the accuracy of any AI output and confirm it" before use (cl. 4). AI use that influences decisions must be **documented in the patient's notes** (cl. 5). Informed consent for scribe use must be obtained, and **whether consent was obtained must be documented** (cl. 9–10). Only **endorsed** AI may be used, or the doctor must assure its safety (cl. 11). | Every one of these obligations — the accuracy check, the consent, the documentation — is currently discharged into the *revisable patient record*, or not recorded at all. A sealed receipt makes the Council's own requirements **provable** rather than merely asserted: it fixes, at the moment of the decision, that the check happened, that consent was taken, and what the AI produced. | | **Health Information Privacy Code 2020** (incl. IPP3A) [9] | Governs how patient information may be collected, used and disclosed. | A pre-execution receipt records, at decision time, what data an AI step touched and under what authority — independent of the AI system being governed. | | **Health & Disability Commissioner** [6] | Adjudicates complaints about the quality and safety of care, including consent. | The sealed record is the artefact that makes a consent-and-oversight account provable when a complaint arrives. | | **GPNZ AI-in-primary-care working group** [10]; Health NZ generative-AI advice | Developing sector guidance on safe AI use. | The completeness requirements (§6) offer a neutral technical specification of the "traceable, tamper-evident record" such guidance presumes but does not yet specify. | ## 6. The Instrument — a sealed pre-execution receipt The missing layer is specified, neutrally and in full, in the companion [Completeness Specification](https://agenticrail.nz/spec/completeness/): an enforcement record is *evidence-grade* only if it is created before the action (R1), independently of the system being recorded (R4), cryptographically signed and verifiable offline (R3), and — the dividing line — **irreversibly sealed** so the account is fixed in time and cannot later be added to, altered, or reopened (R8). A logging-grade record proves nothing was secretly rewritten; only a sealed record proves the account is complete and was fixed at the time — including when the operator is the party later under examination. Applied to an AI-assisted clinical decision At the moment an AI step runs — a scribe drafting a note, a model returning a suggestion — an external gate writes a sealed receipt recording what was produced, what evidence (if any) the clinician reviewed, the time and authority of the human confirmation, and a cryptographic chain to the prior step. The clinician cannot alter it; the AI cannot author it; anyone can verify it offline against a published key, with no call back to the vendor. The verification is automatic — a machine check returning a verdict, requiring no effort from the busy human it protects. `slp8_receipt_v2`, AgenticRail's production receipt schema, is offered as one conformant reference implementation. It is named here as the author's own; the specification is implementation-independent, and any vendor's record can be assessed against the same eight requirements. ## 7. A Deliberate Boundary This brief asserts **no harm** and **no breach of law or duty** by any named body, clinician or vendor. The clinicians described are operating under genuine workload pressure with tools their system endorsed. The brief documents one structural fact: that the safeguards the deployment relies on are not, at present, captured in evidence-grade records — and that the blindness this creates is the danger, independent of whether harm has yet occurred. The argument is for an instrument, not against a person. ## 8. References [1] Hon Simeon Brown, "AI scribe to speed up emergency care for patients," Beehive.govt.nz, 27 Oct 2025 — [beehive.govt.nz](https://www.beehive.govt.nz/release/ai-scribe-speed-emergency-care-patients) [2] "New Zealand expanding national AI scribe rollout to emergency mental health," Healthcare IT News — [healthcareitnews.com](https://www.healthcareitnews.com/news/anz/new-zealand-expanding-national-ai-scribe-rollout-emergency-mental-health) [3] "AI scribe tool rolled out to emergency departments," RNZ News — [rnz.co.nz](https://www.rnz.co.nz/news/national/579400/ai-scribe-tool-rolled-out-to-emergency-departments-promises-to-slash-clinicians-admin) [4] "Major NZ-led clinical trial to test AI-guided treatment of critically ill patients," Health Research Council of NZ — [hrc.govt.nz](https://www.hrc.govt.nz/news-and-events/major-nz-led-clinical-trial-test-ai-guided-treatment-critically-ill-patients) [5] "Health NZ staff told to stop using ChatGPT to write clinical notes," RNZ News, 26 Mar 2026 — [rnz.co.nz](https://www.rnz.co.nz/news/national/590645/health-nz-staff-told-to-stop-using-chatgpt-to-write-clinical-notes) [6] "HDC complaint over AI scribes 'only a matter of time'," New Zealand Doctor (incl. Otago primary-care survey figures) — [nzdoctor.co.nz](https://www.nzdoctor.co.nz/article/news/hdc-complaint-over-ai-scribes-only-matter-time) [7] "Health NZ downplays security flaw found in its vaunted AI chatbot," Newsroom, 20 Mar 2026 — [newsroom.co.nz](https://newsroom.co.nz/2026/03/20/health-nz-downplays-security-flaw-found-in-its-vaunted-ai-chatbot/) [8] Medical Council of New Zealand, "Guidance on using artificial intelligence (AI) in patient care," approved 17 Feb 2026, published 10 Mar 2026 — [mcnz.org.nz](https://www.mcnz.org.nz/assets/standards/Guidance-on-using-artificial-intelligence-AI-in-patient-care-March-2026.pdf) [9] Health Information Privacy Code 2020 (including IPP3A), Office of the Privacy Commissioner — [privacy.org.nz](https://www.privacy.org.nz/) [10] GPNZ "AI in primary care" working group — [gpnz.org.nz](https://gpnz.org.nz/our-work/ai-in-primary-care-group/) [11] Hon Simeon Brown, "AI scribe now in every emergency department," Beehive.govt.nz, 28 Feb 2026 — [beehive.govt.nz](https://www.beehive.govt.nz/release/ai-scribe-now-every-emergency-department) Document Fingerprint — SHA-256 — v1.0 11d3156b98796b6ada4dc2cff728b8eb8668e082f6a939a22e8a94fb03ffaa2b This hash is SHA-256 of the canonical string defined below. It is reproducible independently of this page using any SHA-256 implementation. **Canonical string (pipe-delimited, UTF-8, no trailing newline):** `AI in New Zealand Health Care: The Missing Evidence Layer|1.0|2026-06-24|TUARA KURI LIMITED|national AI scribe rollout ~1250 ED clinicians all public EDs|endorsed ambient scribes Heidi iMedX T-Pro IntelliTek|consumer LLM use ChatGPT Claude Gemini for clinical notes Rotorua memo 2026-03-26|no sealed pre-execution record of AI output or of human review|Otago survey 41pct no explicit patient consent|HDC complaint only a matter of time Whakarongorau|AI scribe security breach reported 2026-03|the missing layer is an irreversible sealed pre-execution receipt|slp8_receipt_v2 completeness R1-R8|report.agenticrail.nz` Published: 2026-06-24 | Version: 1.0 | Entity: TUARA KURI LIMITED **Sourcing note:** every factual claim in §§2–5 is cited to a primary or named New Zealand source in §8, including direct quotations from the Medical Council guidance [8]. This brief asserts no harm and no breach of law or duty by any named body, clinician or vendor. --- # How Do You Prove NCEA Moderation of AI-Assisted Work Actually Happened? — AgenticRail > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/spec/nzqa-nz-education/ > Site context: https://agenticrail.nz/llms.txt **Document type** Sector Gap Analysis — Evidence Brief **Subject** AI in New Zealand education assessment — the verification evidence layer **Published by** TUARA KURI LIMITED — trading as AgenticRail, Hokianga, Aotearoa New Zealand **Date** 2026-07-06 **Version** 1.0 **Status** Published — open for citation **Related** Completeness specification · AI in New Zealand Health Care brief # AI in New Zealand Education Assessment: The Missing Evidence Layer New Zealand's national qualifications authority already names the gap this brief documents, in its own governing rules and guidance — years before this brief was written. NZQA's assessment framework has required internal work to be *valid, authentic,* and **verifiable** since at least 2020: "the work is recorded in a way that allows someone else to verify the evidence." The statutory Assessment Rules now define plagiarism to explicitly include machine-generated content. Reported breaches — many AI-attributed — are rising sharply. What has not changed is the instrument: verification is still discharged through unsealed declaration forms, teacher judgement, and version-history spot-checks, none of which produce an independently checkable record. This brief documents that gap from primary New Zealand sources and identifies the instrument that closes it. It makes no claim that any teacher, school, or student has failed a duty. ## 1. Scope This is a sector brief, not a regulation, and it confers no compliance. It establishes three things from cited New Zealand sources: (a) the scale and statutory basis of AI-related assessment integrity in New Zealand as of mid-2026; (b) the precise point at which NZQA's own required verification steps become *unverifiable* for want of a durable record; and (c) the structure of the evidence layer that would make those steps provable. Throughout, a careful distinction is kept between a **record** (which may exist and still be self-attested, revisable, or absent) and **evidence** (a sealed, contemporaneous, independently verifiable record). The gap is in the second — and it is NZQA's own third pillar of assessment credibility. ## 2. The Deployment — what NZQA already requires and reports **The statutory basis.** NZQA's *Assessment Rules for Schools, TEOs assessing against Achievement Standards and NCEA Co-requisite Standards, and Candidates* — a rule made under s.452(1)(m) of the Education and Training Act 2020, revised annually and currently in force as the 2026 edition — define **Plagiarism** as: *"(a) copied, paraphrased, sourced or otherwise used another person's work or ideas; or (b) used machine or device generated content (such as through the use of artificial intelligence); and (c) presented it as the Candidate's own work without full acknowledgement."* [1][2] This is law, not guidance: AI-generated assessment content is written directly into the legal definition of the offence. **The scale.** Schools carry out approximately **75% of all NCEA assessment** internally [3] — the layer governed by teacher verification, not exam supervision. Reported external-assessment breaches rose from 876 in 2024 to **1,241 in 2025** (+42%); of these, AI-attributed breaches rose from 59 to **168** (+185%); authenticity was the single most common breach category in 2024, at 209 cases [4]. The volume forced a blunt, sector-wide response: the Ministry and NZQA discontinued reports as an assessment method for NCEA Level 1 entirely from 2025, citing authenticity concerns "including the rapid advancement in AI tools" [5]. **The stated safeguard.** The Ministry of Education's official guidance to schools states plainly: *"Teachers or assessors have a responsibility to verify that work submitted for assessment has been produced by the student. The teacher or assessor must therefore be able to assure authenticity by verifying that the evidence of achievement is the student's own."* [6] The entire integrity case for 75% of NCEA assessment rests on that verification being real. ## 3. The Gap — NZQA names it in its own words The structural gap NZQA's own credibility framework, in force since before generative AI existed as a public product, requires internal assessment to be **verifiable** — "recorded in a way that allows someone else to verify the evidence" [3]. Neither the teacher's verification step, nor the school's internal moderation, nor the annual sample sent for external moderation is currently captured in a sealed, tamper-evident, independently checkable record. Each is self-attested by the same school whose credibility is in question. NZQA's own rules acknowledge this indirectly: they require schools to "have monitoring systems" and "retain... evidence of internal moderation" [2] — but specify no mechanism by which NZQA, an appeals panel, or the Ombudsman could confirm that retained evidence is complete, unaltered, and was fixed at the time, rather than reconstructed afterward. Three findings from NZQA and the Ministry's own materials show the gap is structural, not a training or resourcing problem that better guidance would close: **3.1 — The 2023 framing, still true in 2026.** At NZQA's own "Assessment in the Age of AI" symposium, Cath Ellis (UNSW) was quoted approvingly in NZQA's own presentation: *"I've gone from worrying about not having enough evidence to prove cheating has occurred to worrying about not having enough evidence to prove learning has occurred."* [7] This is not a detection problem — it is an absence of evidence in either direction. **3.2 — The moderation cycle is a real, multi-step sequence with no seal.** NZQA's Assessment Rules require every School and TEO, for every internally assessed standard, every year, to: establish an internal moderation process; maintain "monitoring systems that ensure the results they report have been subject to" it; and "retain, until the end of the following academic year, evidence of internal moderation" [2]. Non-compliance carries a real consequence — NZQA "may require additional out-of-cycle external moderation and/or impose limitations on reporting results," including "taking steps to remove the relevant standard from a School's or TEO's Consent to Assess" [2]. The sequence exists and the stakes are real. What is missing is a structural means of independently confirming the sequence was actually followed, rather than re-trusting the same institution's own retained paperwork after the fact. **3.3 — The verification toolkit is manual and explicitly declared unreliable where it is technical.** The Ministry's own guidance lists the discharge of the teacher's "responsibility to verify" as: knowing the student and their work, verbal questioning, checking a document's version history, and asking students to sign "a declaration form / authenticity statement" [6]. Where technical detection is used, the same guidance states: *"AI detection software should not be relied upon to ensure authenticity... they are susceptible to returning 'false positive' results. They are therefore unsuitable to use as the sole means of ensuring authenticity."* [6] A "declaration form" is an unsealed self-attestation — the same shape as the confirmation click a clinician gives an AI scribe's draft (see the companion health brief) — asserted, not fixed at the time in a form a third party can independently check. ## 4. Why "Teacher Verification" Is Not Yet Evidence The teacher's verification is the load-bearing safeguard for three-quarters of NCEA assessment, and it operates under exactly the pressure that makes an unrecorded confirmation fragile: large class sizes, compressed marking windows, and — per the Ministry's own list of AI-misuse "indicators" — reliance on stylistic tells like "excessive use of commas" or "American spellings" [6] that a student can trivially avoid and that say nothing about whether the required check actually took place. Whether a given "teacher verification" was a considered check of the student's understanding or a signature on a declaration form under time pressure is exactly the fact that determines the credibility of the qualification if it is later challenged — and it is exactly the fact nothing currently records. A sealed record resolves this without requiring anyone's memory or good faith after the fact: the standard checked, the evidence reviewed, the time and identity of the verifier, and an explicit chain to the prior step in that Candidate's assessment record — fixed at the moment it happened and verifiable afterward, including by the school whose own paperwork would otherwise be the only account. It does not assume the verification was real. It records whether it was. ## 5. Relationship to New Zealand's Existing Framework This brief operates beneath — not in place of — the instruments already governing the field. It restates none of them and claims conformance to none. | NZ instrument | What it requires | Where the evidence layer sits | | **NZQA Assessment Rules** — made under s.452(1)(m), Education and Training Act 2020 [1][2] | Defines Plagiarism to include AI-generated content presented as a Candidate's own work. Requires an internal moderation process, monitoring systems, and retained evidence for every internally assessed standard, every year (Schedule 4). | Binds each verification/moderation step to a sealed receipt, so "monitoring systems" and "retained evidence" become independently checkable at the moment they occur — not paperwork produced or reconstructed on request. | | **Ministry of Education** — *GenAI in NCEA assessment: FAQs* (Mar 2025) [6] | States the teacher's "responsibility to verify" authenticity, and that AI detectors are "unsuitable to use as the sole means." | The declaration/affirmation step becomes a signed attestation bound into a receipt chain, rather than an unsealed paper form — the duty to verify is unchanged; whether it happened becomes provable. | | **NZQA Assessment Rules, Schedule 5** — Candidate Breaches of External Assessment [2] | A reactive investigation process, triggered only after a report, with 15-business-day review and appeal cycles through to the Chief Executive. | A sealed record at assessment time gives investigators a contemporaneous account to examine, rather than reconstructing events from memory and after-the-fact paperwork. | | **Education and Training (System Reform) Amendment Act 2026** [8] | In force 6 July 2026. Transfers licensing, monitoring, compliance and enforcement functions from the Ministry to the Education Review Office, effective by 1 November 2026. | New compliance infrastructure being stood up now is the natural point to specify a durable, third-party-verifiable evidence format for assessment integrity, rather than retrofit one onto an established process later. | | **NZQA Academic Integrity Guidelines for TEOs and SSBs** (tertiary) [9] | Extends the same authenticity requirement to tertiary education organisations and standard-setting bodies. | The same instrument applies without redesign — the verification-step problem is identical at tertiary level, at higher qualification stakes. | ## 6. The Instrument — a sealed pre-execution receipt The missing layer is specified, neutrally and in full, in the companion [Completeness Specification](https://agenticrail.nz/spec/completeness/): an enforcement record is *evidence-grade* only if it is created before the action (R1), independently of the system being recorded (R4), cryptographically signed and verifiable offline (R3), and — the dividing line — **irreversibly sealed** so the account is fixed in time and cannot later be added to, altered, or reopened (R8). A logging-grade record proves nothing was secretly rewritten; only a sealed record proves the account is complete and was fixed at the time — including when the school or teacher whose verification is in question is the party later under examination. Applied to NCEA internal moderation and teacher verification At the moment a teacher completes an authenticity check, or a Principal's Nominee confirms internal moderation for a standard, an external gate writes a sealed receipt recording which standard was checked, what evidence was reviewed, the time and identity of the verifier, and a cryptographic chain to the prior step in that Candidate's assessment record. The school cannot alter it after the fact; a student's AI-assisted draft cannot author it; NZQA, an appeals panel, or the Ombudsman can verify it offline against a published key, with no need to re-trust the school's own retained paperwork. The verification is automatic — a machine check returning a verdict, requiring no extra effort from an already time-pressured teacher. `slp8_receipt_v2`, AgenticRail's production receipt schema, is offered as one conformant reference implementation. It is named here as the author's own; the specification is implementation-independent, and any vendor's record can be assessed against the same eight requirements. ## 7. A Deliberate Boundary This brief asserts **no failure of duty** by NZQA, the Ministry of Education, any school, or any teacher. Teachers are discharging a stated obligation with the tools available to them, under real class-size and time constraints NZQA's own guidance acknowledges. The brief documents one structural fact: that the verification steps NZQA's own rules and guidance require are not, at present, captured in evidence-grade records — and that this absence is exactly what forces blunt, costly, sector-wide responses, such as withdrawing an entire assessment method nationally, when a scalable per-step record would instead allow a narrower, evidence-based one. The argument is for an instrument, not against a person. ## 8. References [1] NZQA, Report OC01429 — *NZQA Assessment Rules for Schools, TEOs assessing against Achievement Standards and NCEA Co-requisite Standards, and Candidates 2025*, definitions clause, in force 1 Feb 2025 — [nzqa.govt.nz](https://www2.nzqa.govt.nz/assets/About-us/Official-releases/2025/OC01429-NZQA-Assessment-Rules-for-Schools-TEOs-assessing-against-Achievement-Standards-and-NCEA-Co-requisite-Standards-and-Candidates-2025.-pdf.pdf) [2] NZQA, *NZQA Assessment Rules* index (confirms the 2026 successor rules, in force 1 Feb 2026, carry the same Plagiarism definition forward) — [nzqa.govt.nz](https://www2.nzqa.govt.nz/about-us/rules-fees-policies/nzqa-rules/nzqa-assessment-rules-for-schools-teos/) [3] NZQA, *Effective Assessment Practice Guide*, February 2020 (proactively released as part of OIA response OC00458) — [nzqa.govt.nz](https://www2.nzqa.govt.nz/assets/About-us/Official-releases/2023-2024/Artificial-intelligence-OC00458_.pdf) [4] "Reports of NCEA exam breaches surge by 250% as AI use prompts crackdown," NZ Herald — [nzherald.co.nz](https://www.nzherald.co.nz/nz/ai-linked-breaches-contribute-to-ncea-exam-misconduct-rise/K3GNDSTPGVDJTKG2SPTYNZXXNE/) [5] "Schools abandon take-home assignments after artificial intelligence used to cheat," RNZ News — [rnz.co.nz](https://www.rnz.co.nz/news/education/528800/schools-abandon-take-home-assignments-after-artificial-intelligence-used-to-cheat) [6] Ministry of Education / Te Poutāhū Curriculum Centre, *GenAI in NCEA assessment: FAQs*, March 2025 — [education.govt.nz](https://web-assets.education.govt.nz/s3fs-public/2025-03/GenAI%20in%20NCEA%20assessment%20FAQs_MAR2025.pdf) [7] NZQA, "New Zealand's policy and regulatory approaches to generative AI" (Neil Miller, 2023), same OC00458 release as [3] — [nzqa.govt.nz](https://www2.nzqa.govt.nz/assets/About-us/Official-releases/2023-2024/Artificial-intelligence-OC00458_.pdf) [8] Ministry of Education, "Education and Training (System Reform) Amendment Bill" — [education.govt.nz](https://www.education.govt.nz/our-work/information-releases/issue-specific-information-releases/education-and-training-system-reform-amendment-bill) [9] NZQA, "Academic Integrity Guidelines for TEOs and SSBs" — [nzqa.govt.nz](https://www2.nzqa.govt.nz/tertiary/assessment-and-moderation-of-standards/academic-integrity-and-artificial-intelligence/guidelines/) Document Fingerprint — SHA-256 — v1.0 5ac23a1bffd31fb065297f73daf6f6ca68df76f2ee0bfd26ee94004b9115afd3 This hash is SHA-256 of the canonical string defined below. It is reproducible independently of this page using any SHA-256 implementation. **Canonical string (pipe-delimited, UTF-8, no trailing newline):** `AI in New Zealand Education Assessment: The Missing Evidence Layer|1.0|2026-07-06|TUARA KURI LIMITED|NZQA Assessment Rules OC01429 2025 and 2026 successor define Plagiarism to include machine or device generated content such as through artificial intelligence|NZQA Valid Authentic Verifiable credibility pillars since 2020 Effective Assessment Practice Guide|75pct of NCEA assessment is internal|1241 external assessment breaches 2025 up 42pct from 876 in 2024|168 AI attributed breaches 2025 up 185pct from 59 in 2024|209 authenticity breaches 2024 most common category|MOE GenAI in NCEA assessment FAQs March 2025 teacher responsibility to verify authenticity|AI detection software unsuitable as sole means of ensuring authenticity MOE guidance|internal moderation monitoring systems and retained evidence self attested no independent seal Schedule 4 OC01429|Schedule 5 candidate breaches reactive investigation only after a report|Education and Training System Reform Amendment Act 2026 in force 2026-07-06 transfers functions to Education Review Office|the missing layer is a sealed pre execution receipt binding the verification step|slp8_receipt_v2 completeness R1-R8|report.agenticrail.nz` Published: 2026-07-06 | Version: 1.0 | Entity: TUARA KURI LIMITED **Sourcing note:** every factual claim in §§2–5 is cited to a primary or named New Zealand source in §8, including direct quotations from NZQA's own statutory Assessment Rules [1][2] and the Ministry of Education's official guidance [6]. This brief asserts no failure of duty by NZQA, the Ministry of Education, any school, or any teacher. --- # NIST AI RMF Mapping — AgenticRail > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/spec/nist-ai-rmf/ > Site context: https://agenticrail.nz/llms.txt Technical Reference — AgenticRail / NIST AI RMF # NIST AI RMF Mapping: Pre-Execution Enforcement for Agentic AI Mapping AgenticRail's gate architecture to NIST AI Risk Management Framework 1.0 subcategories. Manage 2.4, Measure 2.4, Manage 4.1 — and the structural gap in the framework that agentic AI exposes. Published 2026-05-23 · agenticrail.nz/spec/nist-ai-rmf/ ## 1. Framework Overview The **NIST AI Risk Management Framework 1.0** (January 2023) organises AI risk management across four functions: Govern, Map, Measure, and Manage. It is voluntary — no regulatory penalties attach to non-conformance — but it has become the de facto US enterprise baseline for AI risk programmes, referenced in federal procurement, sector guidance (financial services, healthcare, critical infrastructure), and international cross-referencing with ISO 42001 and the EU AI Act. In April 2026, NIST published a concept note for an AI RMF Critical Infrastructure Profile — sector-specific prescriptive guidance for energy, finance, healthcare, and transport. The direction of travel is toward greater specificity, not less. Organisations building to the current framework should anticipate more prescriptive requirements in those sectors. ## 2. The Agentic AI Gap in NIST AI RMF NIST AI RMF 1.0 was designed for AI systems whose behaviour is characterisable at deployment time — systems that can be tested, evaluated, and risk-assessed before they go live, and whose behaviour in production can be monitored through aggregate metrics. The structural gap Agentic AI systems violate the assumptions the framework was built on. They execute multi-step workflows autonomously, produce different action sequences on every run, and interact with external systems in ways that cannot be fully characterised before deployment. The risk is not static — it is generated at runtime, step by step, action by action. A risk management framework that relies on pre-deployment characterisation and post-hoc aggregate monitoring cannot govern systems whose risk materialises at execution time in discrete, atomic steps. Three NIST AI RMF subcategories expose this gap most directly. All three require operational evidence — proof that controls ran during deployment, not documentation that they were planned. ## 3. Subcategory Mapping | Subcategory | Requirement | Agentic AI gap | AgenticRail mechanism | | Manage 2.4 | Mechanisms in place, and responsibilities assigned, to supersede, disengage, or deactivate AI systems inconsistent with intended use | If oversight depends on the model's self-reported output, human authority is nominal — not structural. The model is the only entity evaluating whether a step should proceed. | Gate operates at infrastructure level. API keys held by designated personnel. No step executes without gate ALLOW. Model cannot bypass, self-report around, or replay an issued decision. | | Measure 2.4 | Functionality and behaviour of the deployed AI system monitored when in production | Aggregate session metrics and post-hoc dashboards detect anomalies after sequences have completed and decisions have been made. For consequential agentic decisions, monitoring must be contemporaneous with execution. | Every gate decision is a monitoring event. ALLOW, DENY, and HALT recorded per action before execution. Ed25519-signed receipt written to immutable storage. Dashboard surfaces statistics in real time. Retrospective analysis at full per-action fidelity. | | Manage 4.1 | Post-deployment monitoring plans implemented, including mechanisms for appeal and override | Post-hoc dashboards surface anomalies after the sequence has run. The monitoring — and the override point — must sit in the execution path, before each step commits. | Every step is monitored at the gate before it runs; a DENY or HALT is the structural appeal-and-override point. No step N+1 runs without gate ALLOW on step N — monitoring and override are the operational process for every step of every sequence. | ## 4. Mechanisms in Detail Manage 2.4 Structural human authority — gate as the intervention point The gate sits between the agent's reasoning layer and action execution. An agent cannot advance from one step to the next without clearing the gate. The gate's API keys are held by designated personnel — not the model, not the application layer. Those personnel can revoke keys, modify the declared step-order policy, or issue a HALT that retires the sequence without the model's cooperation or awareness. HALT is terminal. A HALT-ed sequence is sealed — no further steps can be evaluated, regardless of what the model attempts. The authority to halt is unconditional and does not require the model to stop itself. **Manage 2.4 evidence available:** Key issuance log (who holds gate access, when granted/revoked). HALT receipt records (when human authority was exercised, which sequence, which step triggered it). Sequence termination events in KV statistics. Measure 2.4 Per-action monitoring — contemporaneous with execution For every step evaluation, the gate assesses: sequence position against the declared step order; function/step identity match; action type permissibility against the policy map; nonce uniqueness (replay protection); timestamp freshness (300-second window). Each assessment produces a decision — ALLOW, DENY, or HALT — and an Ed25519-signed receipt written to immutable R2 storage before the gate returns the decision to the caller. The receipt is written before the action executes. This is not a description of what ran — it is a record of what was authorised at the moment of authorisation. For risk-appropriate monitoring of consequential agentic decisions, this is the minimum granularity: per action, per sequence, before execution. **Measure 2.4 evidence available:** Per-step receipt chain for any sequence. ALLOW/DENY statistics at sequence and step level. DENY reason codes (SEQUENCE_VIOLATION, REPLAY_NONCE, ACTION_NOT_ALLOWED, STALE_TIMESTAMP). Real-time dashboard with step distribution and refusal log. Retrospective compliance report via report.agenticrail.nz. Manage 4.1 Post-deployment monitoring and override — in the execution path The gate is not a monitoring layer layered on top of the agent. It monitors every step in production as it runs, and a DENY or HALT is the structural appeal-and-override point. An agent that calls a tool without first receiving a gate ALLOW for that step will not receive an ALLOW retroactively — the receipt does not exist, the step is not in the chain, and the sequence is invalid. This means monitoring and override are not adjacent to operations — they sit in the execution path at the level of individual step execution. The override is not procedural (a policy that requires developers to call the gate) — it is architectural (the agent framework requires gate ALLOWs to proceed, enforced by the SDK and wrapper layer). **Manage 4.1 evidence available:** The receipt chain itself. Every step that ran appears in the chain. Steps that did not clear the gate appear as DENYs — the recorded override events — or do not appear at all. The chain proves post-deployment monitoring and override not by assertion, but by structure. ## 5. Evidence Package for NIST AI RMF Documentation The following evidence is available from AgenticRail for inclusion in a NIST AI RMF risk programme documentation package: Available evidence - Receipt schema specification — [agenticrail.nz/spec/receipt-schema.json](https://agenticrail.nz/spec/receipt-schema.json) — defines all fields, types, and signature computation inputs - Compliance report — [report.agenticrail.nz](https://report.agenticrail.nz) — full receipt chain for any sequence, chain integrity verification, per-step enforcement log, per-receipt signature verification status - Live receipt verification endpoint — POST /verify with sequence_id and receipt pack_id returns cryptographic verification result - Dashboard statistics — real-time ALLOW/DENY ratios, step distribution, HALT events, refusal log available at dashboard.agenticrail.nz - DENY receipt examples — SEQUENCE_VIOLATION, REPLAY_NONCE, ACTION_NOT_ALLOWED samples demonstrating that blocked actions are recorded - Sequence sealing evidence — SEALED_SEQUENCE denial records proving that completed sequences cannot be replayed or extended ## 6. Cross-Framework Alignment The same receipt chain produced by AgenticRail maps to three frameworks simultaneously. The underlying requirement across all three is identical: proof that oversight controls ran during deployment, not documentation that they were planned. | Framework | Requirement | Receipt chain satisfies | | NIST AI RMF | Manage 2.4, Measure 2.4, Manage 4.1 | Structural intervention authority, per-action monitoring evidence, post-deployment monitoring and override proof | | EU AI Act | Article 12 — automatic logging for reconstruction of sequence of events | Pre-execution receipts enable full sequence reconstruction without re-running the system | | ISO/IEC 42001 | A.6.2.8 — event log recording; A.6.1.6 — operational logging and reconstruction | Ed25519-signed, chain-linked, schema-published receipts satisfy both controls — pre-execution timing, defined format, cryptographic integrity, chain linkage | References and further reading NIST AI Risk Management Framework 1.0 — [nist.gov/artificial-intelligence](https://www.nist.gov/artificial-intelligence) AgenticRail receipt schema — [agenticrail.nz/spec/receipt-schema.json](https://agenticrail.nz/spec/receipt-schema.json) Live compliance report — [report.agenticrail.nz](https://report.agenticrail.nz) --- # How Does AgenticRail's Deterministic Enforcement Gate Decide ALLOW, DENY, or HALT? — AgenticRail > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/spec/ > Site context: https://agenticrail.nz/llms.txt Specification v1.4 Published 2026-05-17 · Amended 2026-07-08 TUARA KURI LIMITED # AgenticRail Enforcement Specification This document specifies the AgenticRail deterministic enforcement gate: its decision architecture, enforcement rules, receipt structures, sequence enforcement mechanism, and cryptographic verification model. It is a technical specification, not a marketing document. Every claim here is verifiable without login or operator involvement: run a test sequence at [agenticrail.nz/demo/](https://agenticrail.nz/demo/), verify the receipt chain at [report.agenticrail.nz/report](https://report.agenticrail.nz/report), or watch live enforcement at [dashboard.agenticrail.nz](https://dashboard.agenticrail.nz). ## 1. Decision Architecture AgenticRail sits between an AI agent's intent and the action's execution. Before any step runs, it must pass the gate. The gate returns one of three decisions. No other outputs exist. Permitted ALLOW Refused DENY Request rejected HALT Every decision — including DENY — produces a cryptographic receipt written before the action executes. A DENY receipt is forensic evidence of enforcement. It proves the gate ran and refused. This is the architectural distinction from post-execution logging systems, which have no mechanism to receipt a step that was stopped before it ran. ## 2. Enforcement Rules Rules are evaluated in order. The first failure terminates evaluation and returns DENY with the corresponding denial code. All nine rules must pass for ALLOW. *(Corrected in v1.2, 2026-07-05 — see the amendment below: rules 1–3's actual codes, and rule 8, were not accurately documented in v1.0/v1.1.)* - 1Function missing or empty → DENY:missing_function - 2`action_type` not permitted for function → DENY:ACTION_NOT_ALLOWED - 3`step !== function` → DENY:FUNCTION_STEP_MISMATCH - 4Sequence already sealed → DENY:SEALED_SEQUENCE - 5Nonce already used → DENY:REPLAY_NONCE - 6Step out of order → DENY:SEQUENCE_VIOLATION - 7|ts_ms − now| > 300s → DENY:STALE_TIMESTAMP - 8`RECORD_RESULT` at `boundary` citing a `witnessed_pack_id` that doesn't match the real, durably-written, immediately-preceding receipt → DENY:ARTIFACT_UNBOUND *(added 2026-07-05)* - 9All pass → ALLOW Rule 7 closes the replay-with-fresh-nonce-after-delay attack vector. A valid nonce does not help an attacker whose timestamp window has expired. Rules 5 and 7 together mean a step cannot be replayed at any time: not immediately (nonce), not later (timestamp). ## 3. Enforcement Architecture ``` Client / Agent → Wrapper Worker (auth, rate limit, D1 key store) → Gate Worker (hardening, poison check, internal secret injection) → Core Worker (policy map, timestamp, sequence position) → Durable Object (nonce uniqueness, step counter — per sequence_id) → R2 (Ed25519-signed receipts, immutable storage) → KV (stats index, fast read for report generator) ``` The Gate is the only public entry point. The Core Worker is not publicly callable — it receives requests exclusively via service binding from the Gate, which injects an internal secret before forwarding. This means the enforcement logic cannot be bypassed by calling Core directly. ## 4. Payload Contract ``` { "schema_version": "1.0", "model_id": "MSMD", "sequence_id": "", "step": "", "function": "", "action_type": "", "action": "", "inputs": { "signal": "..." }, "nonce": "", "ts_ms": 1775262544154 } ``` The invariant `step === function` is an ontological constraint, not a validation rule. A step cannot be what it is not. The gate does not attempt to reconcile a mismatch — it denies immediately. ## 5. Sequence Spines The gate enforces ordered sequences called spines. Steps must execute in the defined order. No skipping. No replay. The sequence is sealed permanently at the final step — no unsealing mechanism exists. MSMD Spine — 8 steps intake → disruption → instability → state_read → internal_driver → execution → boundary → settle The architecture is spine-agnostic. Any ordered sequence of named steps can be enforced with the same gate mechanism. The spine defines the permitted order; the Durable Object enforces it per `sequence_id`. ## 6. Receipt Structure — ALLOW On ALLOW, an Ed25519-signed receipt is written to R2 immutable storage before the action executes. Receipt fields are listed in canonical order (alphabetically sorted — the same order used to compute `pack_id`). *(Corrected in v1.2, 2026-07-05 — v1.0/v1.1 named fields that don't exist at this level, `nonce`/`action`/`schema_version`, and omitted several that do. Corrected further in v1.3, 2026-07-08 — `prev_receipt_id`'s description previously overstated what it alone protects; and `prev_receipt_hash` was added as a new field. This table now matches the live implementation and the published JSON Schema exactly.)* | Field | Description | | `attestation` | Optional per-step evidence — AML results, approval hashes, boundary witness references. Excluded from poison check. | | `decision` | **ALLOW**, **DENY**, or **HALT** — same shape for all three | | `executed` | Whether the decision was ALLOW (permitted) — *not* whether the downstream action ran or succeeded | | `key_id` | Signing key identifier: `k2_2026-06-07_ed25519` (active Ed25519; receipts before the 2026-06-07 cutover carry `k1_2026-02-22_01`) | | `meta` | Nested object — see below | | `pack_id` | SHA-256 of canonical JSON (alphabetically sorted keys) — deterministic fingerprint | | `payload_hash` | SHA-256 of raw request body | | `prev_receipt_id` | `pack_id` of the previous receipt — an identifier reference (chain order), not a content hash of the predecessor. Anchor only advances on ALLOW + a confirmed-durable write (2026-07-05). | | `prev_receipt_hash` | SHA-256 of the previous receipt's full canonical JSON, signature included (added 2026-07-08) — the actual hash chain. An in-place edit to any earlier receipt breaks every subsequent link, even if `prev_receipt_id` references still match. Null for the chain's first receipt and for any link whose anchor predates this field. | | `reasons` | Array of denial codes — empty on ALLOW | | `sealed` | Whether this receipt closes the sequence permanently (true only at the final step) | | `signature` | Ed25519 over the receipt's canonical JSON minus this field, signed in the air-gapped core (pre-cutover receipts: HMAC-SHA256) | | `signature_alg` | `Ed25519` or `hmac-sha256` | | `ts_ms` | Gate decision timestamp in milliseconds | | `version` | `slp8_receipt_v2` | **meta** (nested, alphabetical): `action_type`, `function`, `model_id`, `policy_map_ids`, `sequence_id`, `step`. ## 7. Receipt Structure — DENY Every denied step produces a DENY receipt — the **same field shape as ALLOW** above, not a separate structure. This is the critical distinction from post-execution logging: the gate receipts what it stopped, not just what it allowed. A DENY receipt is forensic evidence of an enforcement event — proof the gate was active and refused a non-compliant step. *(Corrected in v1.2, 2026-07-05 — v1.0/v1.1 described a separate DENY shape with `denial_code`/`expected_step` fields that were never implemented; the real reason is carried in the same `reasons` array ALLOW uses, empty on ALLOW and populated on DENY.)* Common values in `reasons` at the enforcement-rule level: `ACTION_NOT_ALLOWED`, `ARTIFACT_UNBOUND`, `FUNCTION_STEP_MISMATCH`, `REPLAY_NONCE`, `SEALED_SEQUENCE`, `SEQUENCE_VIOLATION`, `STALE_TIMESTAMP`. Field-validation codes (e.g. `missing_nonce`) are enumerated in the JSON Schema, not repeated here. ## 8. Cryptographic Model **pack_id** is computed as SHA-256 of the receipt's canonical JSON — keys alphabetically sorted, values as-stored. This makes the fingerprint deterministic regardless of key insertion order. Any verifier can reproduce it independently. **prev_receipt_id** links every receipt to the previous receipt in the sequence by `pack_id` — an identifier reference establishing chain order. On its own it proves something with that identifier preceded this receipt; it does not prove the predecessor's content is unchanged. **prev_receipt_hash** (added 2026-07-08, v1.3) closes that gap: a SHA-256 of the previous receipt's full canonical JSON, signature included. Tampering with any receipt in the chain changes its hash, breaking every subsequent `prev_receipt_hash` link even if `prev_receipt_id` references still match — this is the property that makes the chain self-verifying without a trusted third party. It is null for the chain's first receipt and for any link whose anchor predates this field; the compliance report treats that as "not verifiable", not "broken", and surfaces it as a distinct **Chain hash** column alongside the existing pack_id and linkage checks. **signature** is Ed25519 over the receipt's canonical JSON (with the `signature` field removed), signed in the air-gapped core with key `k2_2026-06-07_ed25519` and verifiable offline against the published public key. Multi-generation verification logic covers both canonical JSON and JSON.stringify forms to handle Gen-1 and Gen-2 receipts. The `signature_alg` field on every receipt records the algorithm used (`Ed25519` or `hmac-sha256`). Ed25519 signing has been active since **2026-06-07**: receipts carry an Ed25519 signature verifiable against the published public key at [/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json) with no call back to any AgenticRail endpoint. Receipts issued before the cutover carry HMAC-SHA256 under `k1_2026-02-22_01` — a shared secret, therefore confirmable only server-side, *not* by a third party. The verifier selects key and algorithm per receipt by `key_id`; the compliance report flags each receipt's `third_party_verifiable` status so a legacy receipt cannot be mistaken for an offline-verifiable one. **What is signed.** The signature covers the canonical JSON of the full receipt envelope, not only the fields tabled above. The envelope also carries `meta` (function, step, model_id), `executed`, `sealed`, `signature_alg`, and `version` — all inside the signed preimage. The compliance report exposes that exact preimage as `signed_canonical` alongside the raw `signature` and `key_id`, so a third party can reconstruct and verify the signed bytes independently. Note the semantics of `executed`: `executed: true` attests only that the gate *permitted* the step (decision = ALLOW). It does not assert that the downstream action ran or succeeded — AgenticRail is an enforcement layer, not an execution runtime. **payload_hash** is SHA-256 of the raw request body — independent verification that the payload the gate evaluated matches what was submitted. ## 9. Article 12 Mapping — EU AI Act | Article 12 Requirement | AgenticRail Mechanism | | Automatic logging of events | Gate decision written to R2 before action executes | | Traceability of operation | `prev_receipt_id` chain — every step linked to previous | | Integrity of records | Ed25519 signature (HMAC-SHA256 pre-cutover) — tamper breaks chain verification | | Independence from AI system | Gate is architecturally separate — model cannot write its own receipt | | Human oversight evidence | DENY receipts prove enforcement was active and refused non-compliant steps | | Third-party verifiability | Run [agenticrail.nz/demo/](https://agenticrail.nz/demo/), take the sequence ID it returns, verify it at report.agenticrail.nz/report. No login required. | ## 10. Deployment | Detail | Value | | Public verification | Run [agenticrail.nz/demo/](https://agenticrail.nz/demo/), then verify the sequence ID it returns at [report.agenticrail.nz/report](https://report.agenticrail.nz/report) | | Deployment | Cloudflare Workers + Durable Objects + R2 + KV + D1 | | Entity | TUARA KURI LIMITED, Hokianga, New Zealand | ## 11. NIST AI RMF Mapping A formal mapping of AgenticRail's pre-execution enforcement gate to NIST AI Risk Management Framework 1.0 subcategories: Manage 2.4 (mechanisms to supersede, disengage, or deactivate a non-compliant system), Measure 2.4 (per-action monitoring contemporaneous with execution), and Manage 4.1 (post-deployment monitoring with appeal and override). Includes the evidence package available for US enterprise and federal AI risk programme documentation. [agenticrail.nz/spec/nist-ai-rmf/](https://agenticrail.nz/spec/nist-ai-rmf/) — gap analysis, subcategory mapping table, mechanism descriptions, evidence available, cross-framework alignment. Prints to two pages. ## 12. Formal Receipt Schema A machine-readable JSON Schema (Draft 2020-12) for the `slp8_receipt_v2` enforcement receipt is published at [`agenticrail.nz/spec/receipt-schema.json`](https://agenticrail.nz/spec/receipt-schema.json). The schema formally specifies three objects: - 1**Receipt** (`slp8_receipt_v2`) — the signed enforcement decision written to R2 before the action executes. Fields: `ts_ms`, `pack_id`, `version`, `decision`, `reasons`, `executed`, `sealed`, `meta`, `attestation`, `payload_hash`, `prev_receipt_id`, `key_id`, `signature_alg`, `signature`. `additionalProperties: false` on all objects — the schema is closed. - 2**Pack** (`slp8_pack_1.0`) — the enforcement decision object whose SHA-256 canonical hash becomes `pack_id`. The minimal authoritative record of the decision, independent of receipt metadata. Defined at `$defs.pack`. - 3**Request Payload** — the client payload submitted to `POST /v1/evaluate`. Eight required fields; the raw body is hashed to produce `receipt.payload_hash`. Defined at `$defs.request_payload`. **Relation to DIS 24970.** ISO/IEC DIS 24970 (AI system transparency and traceability, targeting Q4 2026 finalisation) contains no receipt structure for pre-execution enforcement decisions — no specification of what an ALLOW or DENY record must carry, how denial codes map to enforcement rules, or how receipts chain across a sequence. The `slp8_receipt_v2` schema addresses this gap directly: a production schema with over one million signed enforcement decisions predating the standard's finalisation. The reason codes (`SEQUENCE_VIOLATION`, `REPLAY_NONCE`, `SEALED_SEQUENCE`, `UNKNOWN_STEP`, `FUNCTION_STEP_MISMATCH`, `ACTION_NOT_ALLOWED`, `STALE_TIMESTAMP`, `ARTIFACT_UNBOUND`) enumerate the enforcement failure taxonomy in machine-readable form. *(Corrected 2026-07-05 — the previously-listed `NO_POLICY_MATCH` was never implemented; `UNKNOWN_STEP` is the real mechanism, and `ARTIFACT_UNBOUND`, added 2026-07-05, is included.)* The schema is dated 2026-05-17. Future revisions carry new `$id` URIs and retain prior versions at their original URLs. ## 13. Evidence Completeness Specification A neutral completeness specification for pre-execution agent enforcement records: the eight requirements (R1–R8) that distinguish an **evidence-grade** record from a **logging-grade** one, and the single property that divides them — irreversible sequence sealing. The framing is *append versus seal*: every system that keeps a record appends; a complete record also closes. The seal is the earth pin of an enforcement record — the safety ground that carries no payload and holds only when something faults. The specification names no product but its own reference implementation; it is offered as a measure any enforcement record, from any vendor, can be assessed against. [agenticrail.nz/spec/completeness/](https://agenticrail.nz/spec/completeness/) — eight requirements, two conformance levels, the completeness test, reference implementation, framework mapping. Fingerprinted. Published 2026-06-24. ## 14. AI in New Zealand Health Care — Sector Gap Analysis A cited gap analysis of New Zealand's national AI deployment in health care: ambient AI scribes in use by ~1,250 emergency-department clinicians across all public EDs (with 1,000 further licences for mental-health teams), AI-guided treatment in ICU trial, and documented use of consumer chatbots (ChatGPT, Claude, Gemini) to draft clinical notes. The brief shows that the deployment's stated safeguards — *"the doctor reviews and confirms,"* and privacy compliance — are not, at present, captured in any sealed, pre-execution, tamper-evident record. The Medical Council's own guidance (Mar 2026) requires the accuracy check, informed consent, and documentation of AI use; the sealed receipt is the instrument that makes those requirements provable. Asserts no harm and no breach — an argument for an instrument, not against a person. Every claim cited to a primary New Zealand source. [agenticrail.nz/spec/nz-health/](https://agenticrail.nz/spec/nz-health/) — deployment scale, the evidence gap, mapping to NZ's regulatory framework, the instrument, full references. Fingerprinted. Published 2026-06-24. ## 15. AI in New Zealand Education Assessment — Sector Gap Analysis A cited gap analysis of NZQA and Ministry of Education assessment integrity. NZQA's own *Assessment Rules* (a statutory rule under s.452(1)(m) of the Education and Training Act 2020) define Plagiarism to explicitly include "machine or device generated content (such as through the use of artificial intelligence)" — and NZQA's assessment framework has required internal work to be **verifiable** ("recorded in a way that allows someone else to verify the evidence") since 2020, years before generative AI existed as a public product. Reported breaches rose from 876 (2024) to 1,241 (2025); AI-attributed breaches rose from 59 to 168 over the same period. The brief shows that NZQA's own required verification steps — teacher authenticity checks, internal moderation — are still discharged through unsealed declaration forms and self-attested school paperwork, with no independent seal. Asserts no failure of duty by NZQA, the Ministry, any school, or any teacher — an argument for an instrument, not against a person. Every claim cited to a primary New Zealand source. [agenticrail.nz/spec/nzqa-nz-education/](https://agenticrail.nz/spec/nzqa-nz-education/) — statutory basis, the evidence gap, mapping to NZ's regulatory framework, the instrument, full references. Fingerprinted. Published 2026-07-06. ## 16. Automated Decisions and the Provable Safeguard — Public-Sector Note A technical note occasioned by New Zealand's move to automated public-sector decision-making (the Social Security (Modernisation) Amendment, in effect from 1 July 2026, permitting automated benefit decisions *"with appropriate safeguards"*). The note distinguishes three tiers of safeguard — **asserted** (a policy says the check happens), **enforced** (the system structurally cannot proceed past a skipped step), and **provable** (every decision leaves a signed, sealed, offline-verifiable receipt) — and documents from the public record that the two most consequential automated-decision failures of the past decade (Australia's Robodebt; the Dutch childcare benefits scandal) were failures of sequence and evidence at the first tier, not failures of artificial intelligence. Includes a five-minute verification anyone can run. Asserts no failure by any New Zealand agency and names no individuals. [agenticrail.nz/spec/enforceable-safeguards/](https://agenticrail.nz/spec/enforceable-safeguards/) — the commitments, the failure shape, three tiers, the instrument, the test, full references. Fingerprinted. Published 2026-07-17. Document Fingerprint — SHA-256 — v1.0 (superseded by v1.1 below) ceebe558492a3ba33ceb78e49fd3aa7fed334ce3a8f127938e4fed0fb8a4d6ba This hash is SHA-256 of the canonical specification content defined below. It is reproducible independently of this page. **Canonical content covers:** version, date, entity, decision values, enforcement rules (numbered, in order), MSMD spine, Hokianga spine, ALLOW receipt fields (alphabetical), DENY receipt fields (alphabetical), denial codes, pack_id method, prev_receipt_id method, payload_hash method, signature algorithm, key_id, verification URL. **To verify:** Reconstruct the canonical string from the fields above in the order specified at [agenticrail.nz/spec/canonical.txt](https://agenticrail.nz/spec/canonical.txt) and compute SHA-256. The result must equal the hash above. Published: 2026-05-17 | Version: 1.0 | Key ID: k1_2026-02-22_01 The v1.0 fingerprint above is permanent and unchanged. The amendment below records a later development — the activation of Ed25519 signing — as a separate, independently-fingerprinted record. v1.0 is not edited; it is superseded. Amendment v1.1 — Ed25519 Activation — SHA-256 4e7ab63ed319ea2a4f45a891b16a532d709c3d716bedc2e2535139af1e2352e9 On 2026-06-07 receipt signing was activated to **Ed25519** (key_id `k2_2026-06-07_ed25519`) and the verification public key was published at [agenticrail.nz/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json) — receipts are now offline-verifiable by anyone, no endpoint required. **Unchanged from v1.0:** the receipt schema, canonicalization, `pack_id` derivation, and chain linkage. Only the active signature algorithm and key_id change. Receipts issued before the cutover remain HMAC-SHA256 under `k1_2026-02-22_01` and are unaffected; the verifier selects key and algorithm per receipt by `key_id`, so chains spanning the cutover verify intact. **To verify:** Compute SHA-256 of the canonical content at [agenticrail.nz/spec/canonical-v1_1.txt](https://agenticrail.nz/spec/canonical-v1_1.txt) with trailing whitespace removed. The result must equal the hash above. The v1.0 record remains independently reproducible from [canonical.txt](https://agenticrail.nz/spec/canonical.txt) and is not affected. Published: 2026-06-07 | Version: 1.1 | Key ID: k2_2026-06-07_ed25519 The v1.0 and v1.1 fingerprints above are permanent and unchanged. v1.2 corrects documentation errors in the ALLOW/DENY receipt field lists and denial codes published in v1.0/v1.1 (they named fields that were never implemented and omitted several that were) and adds one new enforcement rule. Neither v1.0 nor v1.1 is edited; v1.2 is a separate, independently-fingerprinted record. Amendment v1.2 — Receipt Field & Denial Code Correction — SHA-256 6ab32d42d3055890616327ef661e0868b7d7dae4b139e4fa268f35cbc2dbd958 On 2026-07-05, the ALLOW/DENY receipt field lists and denial codes published in v1.0/v1.1 were found to be inaccurate — they named fields that were never implemented at the receipt's top level (`nonce`, `action`, `schema_version`, `denial_code`, `expected_step`) and omitted several that were (`meta`, `executed`, `sealed`, `reasons`, `signature_alg`, `version`). Verified directly against the live enforcement engine's receipt-building code and cross-checked against the machine-readable JSON Schema at [receipt-schema.json](https://agenticrail.nz/spec/receipt-schema.json), which already carried the correct structure. v1.2 also documents the artifact-binding enforcement rule (9, added 2026-07-05: a boundary witness claim must match the real, durably-written, immediately-preceding receipt — `DENY:ARTIFACT_UNBOUND` otherwise) and its new denial code. **Unchanged from v1.0/v1.1:** the receipt schema, canonicalization, `pack_id` derivation, chain linkage, and signature algorithm. This amendment corrects documentation of the receipt's shape and denial-code set — it does not alter the shape or the set. **To verify:** Compute SHA-256 of the canonical content at [agenticrail.nz/spec/canonical-v1_2.txt](https://agenticrail.nz/spec/canonical-v1_2.txt) with trailing whitespace removed. The result must equal the hash above. The v1.0 and v1.1 records remain independently reproducible from their own files and are not affected. Published: 2026-07-05 | Version: 1.2 | Key ID: k2_2026-06-07_ed25519 The v1.0, v1.1, and v1.2 fingerprints above are permanent and unchanged. v1.3 adds one new receipt field, `prev_receipt_hash` — a genuine hash chain, not merely an identifier chain. Neither v1.0, v1.1, nor v1.2 is edited; v1.3 is a separate, independently-fingerprinted record. Amendment v1.3 — Hash-Chain Field — SHA-256 f0983383ee013ebc398aa8cda8e30293cfeecc719dd16291f47e65b70fef83a6 On 2026-07-08, a new receipt field `prev_receipt_hash` was added: a SHA-256 of the immediately preceding receipt's full canonical JSON (signature included), not merely its `pack_id`. `prev_receipt_id` is an identifier reference — it proves something with that identifier preceded this receipt, not that the predecessor's content is unchanged. `prev_receipt_hash` closes that specific gap: an in-place edit to any earlier receipt in the chain changes its hash, breaking every subsequent link even if `prev_receipt_id` references still match. Null for the chain's first receipt, and for any link whose anchor predates this field — the report generator's chain-integrity check treats that as "not verifiable", not "broken", the same way legacy pre-Ed25519 receipts are treated as unverifiable rather than invalid. Verified directly against the live enforcement engine and report generator, then confirmed end-to-end against a real production sequence the same day (the report's `hash_chain` field showed `verified:7, broken:0, not_verifiable:1` — the 1 being the chain's own first receipt). **Unchanged from v1.2:** the enforcement rules, decision set, denial codes, `pack_id` derivation, and signature algorithm. This amendment adds one new receipt field only. **To verify:** Compute SHA-256 of the canonical content at [agenticrail.nz/spec/canonical-v1_3.txt](https://agenticrail.nz/spec/canonical-v1_3.txt) with trailing whitespace removed. The result must equal the hash above. The v1.0, v1.1, and v1.2 records remain independently reproducible from their own files and are not affected. Published: 2026-07-08 | Version: 1.3 | Key ID: k2_2026-06-07_ed25519 The v1.0, v1.1, v1.2, and v1.3 fingerprints above are permanent and unchanged. v1.4 removes the Hokianga Spine definition present in v1.0-v1.3. Neither v1.0, v1.1, v1.2, nor v1.3 is edited; v1.4 is a separate, independently-fingerprinted record. Amendment v1.4 — Hokianga Spine Removed — SHA-256 beba65d05587ca2a368eda128187ca59ac3aa19ad92d557f7233ca24874175a6 On 2026-07-08, the Hokianga Spine (an 8-step dialect-provenance sequence) was removed from this specification. AgenticRail is a deterministic sequence-enforcement and accountability layer — it does not provide, and has never claimed to provide, language or data sovereignty. The Hokianga Spine was never wired into the live enforcement engine (`slp8-core.js` imports only `msmd_policy_maps.js`; a separate policy-map file prepared for it was never integrated) and is withdrawn as it did not reflect an actual product capability. **Unchanged from v1.3:** the enforcement rules, decision set, denial codes, receipt fields, `pack_id` derivation, and signature algorithm. This amendment removes one spine definition only. **To verify:** Compute SHA-256 of the canonical content at [agenticrail.nz/spec/canonical-v1_4.txt](https://agenticrail.nz/spec/canonical-v1_4.txt) with trailing whitespace removed. The result must equal the hash above. The v1.0, v1.1, v1.2, and v1.3 records remain independently reproducible from their own files and are not affected. Published: 2026-07-08 | Version: 1.4 | Key ID: k2_2026-06-07_ed25519 --- # Frequently Asked Questions — Proving an AI Safeguard Actually Ran — AgenticRail > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/faq/ > Site context: https://agenticrail.nz/llms.txt # Frequently Asked Questions — Proving an AI Safeguard Actually Ran Direct answers, no pitch. Every answer below is drawn from AgenticRail's published docs and specs — nothing here is a new claim. ## What does it mean for an AI safeguard to be provable rather than just claimed? There are three tiers. **Asserted:** a policy or press release states the check happens, but the system doesn't require it and no independent record exists. **Enforced:** the system structurally cannot proceed past a skipped or out-of-order step — a decision with a missing safeguard is denied before execution, not flagged. **Provable:** every decision leaves a cryptographically signed, sealed, tamper-evident receipt of the steps that ran, in order, verifiable by a party outside the operator, offline, against published keys, without trusting the operator's servers. Most deployed safeguards today sit at tier one. ## How is this different from a normal system log? A log written by the same system whose conduct is in question answers a narrower thing than people assume. "We logged it" is not the same as "we can prove it" — a log that can still be added to, edited, or tidied after the fact cannot establish that what it shows is the complete account as it stood at the time. A provable record is created *before* the action, independent of the system being recorded, cryptographically signed, and irreversibly sealed, so the account is fixed at the moment it happened. ## Do I have to trust the company that built this? Not to verify a receipt. Verification runs entirely offline, against public keys published at [agenticrail.nz/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json), with standard Ed25519 verification code you run yourself — no network call to AgenticRail required. A sealed sequence also cannot be reopened without leaving a detectable break in its hash chain, and sealed sequences are additionally copied to an independently held write-once archive at the moment of sealing, so even a rewrite by the operator is detectable against the witness copy. ## Does this work with any AI system, or only a specific vendor's? The gate sits between an agent and its downstream actions and evaluates the request payload against a declared policy — it does not care which model or vendor produced the request. Any agent, on any model, can be wired to call the gate before it acts. It is an independent enforcement layer, not a feature of one AI provider's stack. ## What does it actually take to implement this? An agent declares its own step order and calls the gate before each action with a small payload — `sequence_id`, `step`, `function`, `action_type`, `action`, `inputs`, a fresh `nonce`, and a timestamp. The gate returns ALLOW or DENY before the action runs. Python and JavaScript SDKs wrap this contract directly. Full payload contract and API reference: [agenticrail.nz/docs/](https://agenticrail.nz/docs/). ## Is this specific to New Zealand, or could any country or agency use it? The mechanism itself is not jurisdiction-locked — the receipt chain is citable as evidence under frameworks including EU AI Act Article 12, ISO/IEC 42001 A.6.1.6, and NIST AI RMF Measure 2.4. The company's current outreach is focused on Aotearoa New Zealand, but nothing about the enforcement mechanism or the receipt format restricts it to any one country or agency. ## How do you verify a receipt without contacting AgenticRail? Fetch the published public keys, take a receipt's `signed_canonical` preimage and its `signature`, and run `ed25519_verify(public_key, signed_canonical, signature)` in your own code. That's the whole check — no account, no callback, no dependency on AgenticRail's servers being up. Flip one character in the signed content and the verification fails. ## If the company disappeared tomorrow, would verification still work? For any receipt and public key you already hold a copy of: yes, permanently — Ed25519 verification is pure offline math, it does not call home. The honest limit is upstream of that: fetching a receipt from the live report tool, or fetching the keys fresh from the live site, needs the company's infrastructure to be running. Anyone who wants verification to survive the company should save the receipt and the public keys themselves. This is also the exact gap the independently held archive exists to narrow, not fully close — it protects against the operator quietly rewriting history, but the archive is not yet run by a separate custodian, so that residual case is disclosed, not hidden. **Go deeper** Full enforcement spec — [agenticrail.nz/spec/](https://agenticrail.nz/spec/) Asserted vs. enforced vs. provable, with Robodebt as the case study — [agenticrail.nz/spec/enforceable-safeguards/](https://agenticrail.nz/spec/enforceable-safeguards/) Verify a real sealed record — [report.agenticrail.nz/report](https://report.agenticrail.nz/report) API documentation — [agenticrail.nz/docs/](https://agenticrail.nz/docs/) --- # How Many Requests Has AgenticRail's Enforcement Gate Survived Under Attack? — AgenticRail > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/security/ > Site context: https://agenticrail.nz/llms.txt # Security Hardening Every attack vector tested. Every result recorded. The gate has been run against poison injection, replay attacks, sequence skips, concurrent race conditions, and adversarial probe suites — all against the live deployment, not a test environment. Evidence is public and independently verifiable. 1,045,508 Verified requests 0 Enforcement errors 3 Poison categories blocked 11 Adversarial test suites ## Injection hardening The gate's `checkPoison` layer runs before payload evaluation. Any request carrying these patterns is rejected with **HALT** before reaching the enforcement core. Three attack categories are in scope; all are blocked at the gate layer, not the application layer. HALT — Blocked #### Role directive injection Patterns: `system:`, `<|im_start|>`, `{role:`. Attempts to embed LLM role or instruction directives in JSON payload fields — action, input, sequence_id, step. All field values are scanned before evaluation. HALT — Blocked #### Base64 blob injection Long base64-encoded strings in any payload field. Common vector for encoding instructions or binary payloads that bypass text-pattern filters. The gate detects and halts regardless of which field carries the blob. HALT — Fixed May 2026 #### YAML front matter injection `---` delimiters as both raw newlines and JSON-encoded `\n`. The initial regex matched literal newline characters only — `JSON.stringify` encodes newlines as `\\n`, so the pattern never fired. Regex updated to match both forms. Found by the daily adversarial probe. ### How the YAML gap was found The daily monitoring agent runs rotating adversarial probes against the live gate each morning. On 2026-05-03 it reported YAML front matter returning ALLOW instead of DENY. Root cause: `checkPoison` used a literal-newline regex against JSON-serialised bodies where newlines are two-character escape sequences. The fix was deployed the same session. The probe found a genuine gap in a production security control — not a theoretical edge case. ## Pressure test record All tests run against the live Cloudflare Workers deployment — not a staging environment, not a mock. Results are machine-recorded JSON files stored in the evidence directory. | Test | Requests | Enforcement accuracy | What it proves | | | **1M Full-Sequence** 125,000 complete 8-step MSMD sequences · 50 concurrent workers · 68 req/s · 3h 46m | 923,983 | 100% 0 enforcement errors 0 false DENY | Rail is deterministic at scale. Every ALLOW correct, no misfire on valid sequences over 3+ hours. | ✓ | | **100K Enterprise** 33,334 sequences × 3 scenarios: valid, skip, replay | 100,002 | 99.98% 0.02% network errors | Skip-ahead and replay enforcement under sustained load. Valid sequences always pass; invalid sequences always block. | ✓ | | **Step Transition** 1,000 sequences × 3 scenarios: valid, skip, replay | 3,000 | 100% zero errors | Step ordering enforcement is perfect. Skip-ahead: 100% blocked. Replay: 100% blocked. Valid: 100% pass. | ✓ | | **Action Type Mismatch** Valid MSMD functions with wrong action_type deliberately set | 3,003 | 100% 3,003 blocked 0 false allows | The function/action_type contract is enforced without exception. No wrong-action-type request ever passes. | ✓ | | **Concurrent Burst** 200 sequences × 10-request simultaneous burst each | 2,000 | 100% 200/200 bursts: exactly 1 ALLOW 0 race leaks | Durable Object single-threaded model prevents race conditions. Concurrent requests on the same sequence are serialised — no double-advance possible. | ✓ | | **Seal Behaviour** 100 full 8-step sequences + post-seal breach attempt each | 900 | 100% 100/100 sequences sealed 0 seal leaks | The seal is permanent. After `settle`, no further steps are accepted on the sequence — ever. Post-seal attempts always DENY. | ✓ | | **Nonce Replay** 300 sequences × first request + replay of same nonce | 600 | 100% 300/300 replays blocked | Nonce replay protection is absolute. The same nonce is never accepted twice on the same sequence, regardless of timing. | ✓ | | **Intake Node Pressure** Single-step entry point · concurrency 300 | 10,000 | — | Entry point throughput ceiling under maximum concurrency. Measures CPU and latency at the first enforcement step. | ✓ | Total verified requests across all pressure tests: **1,045,508**. JSON evidence files with full latency distributions available in the test evidence directory. ## Live breach suite Ten targeted tests, each designed to breach one specific enforcement rule. All 10 run against the live production gate — not unit tests, not mocks. Result: all 10 held. | Test | Attack | Expected | Result | | T1 | Unknown function — `garbage_step` as function name | DENY — UNKNOWN_STEP | HELD | | T2 | Forbidden action_type on disruption step | DENY — ACTION_NOT_ALLOWED | HELD | | T3 | Sequence skip — jump from step 1 to step 3 | DENY — SEQUENCE_VIOLATION | HELD | | T4 | Function/step mismatch — `step ≠ function` | DENY — FUNCTION_STEP_MISMATCH | HELD | | T5 | Nonce replay — same nonce sent twice | DENY — REPLAY_NONCE | HELD | | T6 | Forbidden action_type on execution step | DENY — ACTION_NOT_ALLOWED | HELD | | T7 | Skip to settle — jump to final step from step 2 | DENY — SEQUENCE_VIOLATION | HELD | | T8 | Settle with wrong function name | DENY — FUNCTION_STEP_MISMATCH | HELD | | T9 | Clean 8-step MSMD run — full sequence seal | ALLOW × 8 → SEALED | SEALED | | T10 | Report generator verification of sealed sequence | VERIFIED_INTACT | VERIFIED | ## Architecture edge cases Five edge cases that test the enforcement boundary conditions — not the happy path, the corners. All five pass on the live deployment. | Test | Edge case | Result | | **Duplicate step names** | `step_order: ["intake", "intake", "settle"]` — duplicate in the sequence definition | Handled gracefully — ALLOW or DENY, no crash | | **DO nonce cap** | 501 unique nonces on a single sequence — past the nonce ledger eviction threshold | Nonce eviction working — no crash, no memory leak, no replay admitted | | **Timestamp boundary** | `ts_ms` exactly 299,999ms old — 1ms inside the 300s freshness window | ALLOW — correctly inside window | | **XSS in sequence_id** | `` as sequence_id in report generator | Sanitized — raw script tag not reflected in response | | **Empty step_order** | `step_order: []` — empty array sent with intake request | Fell back to MSMD spine — ALLOW on valid intake | ## Daily adversarial monitoring The agent that monitors AgenticRail runs 2 randomly selected scenarios from a pool of 10 adversarial patterns every morning. This is the probe that found the YAML injection gap on 2026-05-03. The pool covers all 6 core enforcement rules. | Scenario | Rule tested | Status | | Function/step mismatch — `step=intake, function=disruption` | FUNCTION_STEP_MISMATCH | Held | | Sequence skip — intake then instability (skip disruption) | SEQUENCE_VIOLATION | Held | | Unknown step — random string not in spine | UNKNOWN_STEP | Held | | Custom order exclusion — step not in custom step_order | UNKNOWN_STEP (custom spine) | Held | | Forbidden action type — execution with CHECK_STATE | ACTION_NOT_ALLOWED | Held | | Wrong index in custom order — settle at position 0 | SEQUENCE_VIOLATION | Held | | Step regression — run forward then send a completed step again | SEQUENCE_VIOLATION | Held | | Nonce replay — same nonce sent twice with delay | REPLAY_NONCE | Held | | Sealed sequence re-entry — full 8-step then attempt intake again | SEALED_SEQUENCE | Held | 2 scenarios selected at random per daily run. Running since 2026-03-25. Pool covers: FUNCTION_STEP_MISMATCH, ACTION_NOT_ALLOWED, UNKNOWN_STEP (3 variants), SEQUENCE_VIOLATION (3 variants), REPLAY_NONCE, SEALED_SEQUENCE. ### Verify the claims independently Any sequence ID beginning with `demo-` can be verified at [report.agenticrail.nz](https://report.agenticrail.nz) without an API key — full receipt chain, signature verification, and chain linkage proof. Receipts from before the 2026-06-07 Ed25519 cutover use symmetric HMAC, checked server-side by the report; receipts since then are Ed25519 and additionally verify **offline** against the published public key. For the strongest test, run the demo at [agenticrail.nz/demo/](https://agenticrail.nz/demo/), take the sequence ID it returns, and verify a receipt's Ed25519 signature yourself against [/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json) — no call back to us. The receipts are the proof. [Try the demo →](https://agenticrail.nz/demo/) [Verify a sequence →](https://report.agenticrail.nz) [Compliance matrix →](https://agenticrail.nz/compliance/) --- # What Does AgenticRail's Receipt Chain Actually Prove for Compliance? — AgenticRail > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/compliance/ > Site context: https://agenticrail.nz/llms.txt # Compliance — what this actually provides AgenticRail is a deterministic enforcement gate that produces cryptographically signed, chained receipts before and after each step in an agent workflow. Below is a narrow, honest account of which class of regulatory requirement that mechanism is actually relevant to — and an explicit list of what it does not do. This page is our own technical account, not legal advice, and it is not a substitute for your own counsel's assessment. ### Per-step attestation — optional, and inert unless you use it Every gate call accepts an optional `attestation` object. Whatever you pass — a document hash, an approval ID, a sign-off token — is signed into the receipt at that step, immutably, chained to the rest of the sequence. The gate does not require, generate, or validate the content of an attestation; it only binds whatever you give it to the moment of enforcement. Where the baseline receipt proves *a step ran, in order, at a given time*, attestation lets you additionally bind *a specific piece of evidence you supplied* to that step — a signed fact, not a log entry, and not a claim about whether that evidence was itself correct. ## The class of requirement this addresses Most AI governance frameworks contain provisions about record-keeping, audit trails, tamper-evidence, and non-repudiation — proving that something was logged, that the log wasn't altered afterward, and that the log was generated automatically rather than by the system being audited. That is the specific, narrow class of requirement a deterministic gate producing signed, chained receipts is genuinely relevant to. The table below lists the handful of provisions we consider a close, defensible match — not an exhaustive matrix, and not a claim of certification against any of them. | Provision | Requirement | What the receipt actually provides | | FDA 21 CFR §11.10(f) | Operational system checks to enforce permitted sequencing of steps and events | The closest match we know of. The gate enforces exact step order at the infrastructure layer — a step out of the declared order is denied before it runs. | | FDA 21 CFR §11.10(e) | Secure, computer-generated, time-stamped audit trails | Ed25519-signed receipts, computer-generated at decision time, stored in immutable object storage. Whether your retention period and validation procedures meet the full requirement is your determination to make, not ours. | | EU AI Act Art. 12 | Record-keeping — automatically recorded logs during system operation | Receipts are generated by the infrastructure layer at decision time, not by the application being governed, and cannot be edited after the fact. We do not claim this satisfies Art. 9 (risk management), Art. 10 (data governance), or Art. 14 (human oversight) — see below. | | NIST SP 800-53 AU-9(3) | Cryptographic mechanisms to protect audit-information integrity | Every receipt is signed (Ed25519, or legacy HMAC-SHA256) over canonical JSON. Tampering with a receipt is cryptographically detectable. | | NIST SP 800-53 AU-10 | Non-repudiation | The receipt chain (`prev_receipt_id` for ordering, `prev_receipt_hash` for content — added 2026-07-08) proves a given step occurred in sequence and that no earlier receipt was silently altered afterward. It does **not**, by itself, bind a human identity to the action — that requires you to pass an actor/approver token via `attestation`, and the strength of that binding depends entirely on how you authenticate that token before submitting it. | | PCI DSS 10.3.4 | File integrity monitoring on audit logs | Chain linkage (`prev_receipt_hash`, added 2026-07-08) means any alteration to a past receipt's content changes its hash, breaking the link in every subsequent receipt — detectable without trusting a separate monitoring system. | | SEC Rule 17a-4(f)(2)(i), path B | WORM (write-once-read-many) electronic storage | Immutable object storage is structurally WORM-like. Whether it satisfies the full regulatory definition of WORM for your specific use is a determination for your compliance team, not a claim we make here. | ## What this does not do This list exists because it's easy for an infrastructure vendor to let "the receipt is real" quietly become "therefore the requirement is satisfied." It is not. Be explicit with your own reviewers about the difference. | Not addressed | Why | | Training data governance / bias (e.g. EU AI Act Art. 10) | The gate does not see, evaluate, or govern training data or model outputs. It proves a step ran in the declared order — it says nothing about whether the AI's underlying decision was accurate, fair, or free of bias. | | Effective human oversight (e.g. EU AI Act Art. 14) | The gate can require a step to be gated on human input, and can bind whatever token you supply as evidence that occurred. It cannot prove a human actually read, understood, or meaningfully considered anything — only that the gated step was passed. | | Risk management, impact assessment, safety certification (e.g. EU AI Act Art. 9, Korea AI Basic Act Art. 33/36) | These require substantive judgment about a specific system's risks and safety case. Receipts can be cited as supporting evidence that a process was followed — they are not a substitute for doing the assessment. | | Anti-discrimination / bias-audit outcome proof (e.g. US state AI employment laws) | Receipts can show that the same sequence of steps ran for every candidate or case — process consistency. They cannot show the *outcomes* of those steps were non-discriminatory. Process consistency and outcome fairness are different claims. | | Legal compliance certification, for any framework named on this page or elsewhere | Nothing here is legal advice or a compliance certification. Confirm applicability with your own counsel before relying on any of it for a regulatory submission. | | Independent security audit; production deployment in a regulated sector | As of this writing, AgenticRail has not had a third-party security audit published, and has no production healthcare (or other regulated-sector) deployment. Weigh that into any procurement decision. | ## Data residency & sovereignty Aotearoa NZBounded by designWhat is stored, where, and what is not claimed AgenticRail is an enforcement and evidence layer. It does **not** make anyone sovereign over the AI model, and it does not claim to. What it holds is deliberately small — and we state its limits plainly rather than imply more. | Concern | How AgenticRail answers it | | What is stored | Receipts are **metadata and SHA-256 hashes only** — a hash of the request, never the request body. No clinical content and no personal data are stored in a receipt; the hash is not the content. | | Where it is stored (hosted tier) | The hosted service runs on Cloudflare R2 — **outside New Zealand**. No in-country residency is claimed for the hosted tier. **Mitigation:** because only hashes and metadata are held, no taonga or personal record leaves your systems inside a receipt. | | NZ / sovereign residency | For an organisation with a data-residency requirement, a **self-hosted or sovereign deployment** can be provisioned on New Zealand-owned infrastructure. Receipts are S3-compatible and can be written to an NZ-owned store — keeping the record, and authority over it, in Aotearoa. | This meets a documented expectation of patients for health AI — that their information stays within the health system and is not shared with outside or commercial organisations. Deploy AgenticRail into your own tenant, hold none of your data, and verify receipts against your own keys. ## Legal documents Operating terms and data processing — each cryptographically fingerprinted so customers can prove the version in force at any point in time. | Document | Version | What it covers | | [Terms of Service](https://agenticrail.nz/terms/) | `v1.6` | Operating terms for use of the System. Deterministic enforcement, client responsibility, no guarantee of outcomes, fail-closed by design. Governed by New Zealand law. | | [API Terms of Use](https://agenticrail.nz/api-terms/) | `v2.7` | Request contract, rate limits, reason codes, idempotency. Read alongside the main Terms of Service. | | [Privacy Policy](https://agenticrail.nz/privacy/) | `v2.6` | Data minimisation, GDPR and NZ Privacy Act 2020 alignment, no model training, no marketing sale. Metadata-only retention. | | [Data Processing Agreement](https://agenticrail.nz/dpa/) | `v1.9` | GDPR Article 28 processor terms. Subprocessor list with flow-down liability. Delete-or-return at the controller's choice. SCCs by reference. Takes effect automatically on first paid API call. | AgenticRail is operated by **TUARA KURI LIMITED**, a New Zealand registered company — NZBN [9429053582867](https://www.nzbn.govt.nz/help/nzbn-register/search-the-register/) (search the public NZBN register directly), registered address 431 Omanaia Road, RD 3, Kaikohe 0473, New Zealand. [Try the demo →](https://agenticrail.nz/demo/) [Get a key →](mailto:hello@agenticrail.nz) --- # Are AI Agents Deterministic or Probabilistic? Here's the Real Difference > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/blog/deterministic-vs-probabilistic-ai-agents/ > Site context: https://agenticrail.nz/llms.txt Published 22 April 2026 · Last reviewed 21 July 2026 · AgenticRail # Deterministic vs Probabilistic AI Agents: Why the Distinction Matters for Deployment A **deterministic AI agent** enforces a fixed, reproducible sequence of steps before any action executes — each step must pass an explicit gate, producing a cryptographic receipt, before the next step is authorised. A **probabilistic AI agent** (any LLM-based system) selects actions by statistical likelihood: the same input can produce different outputs, and steps can be silently inferred as complete without executing. For regulated industries where "what did the agent actually do?" must be provably answerable, this distinction is not academic. It is the line between compliance and liability. ## The core distinction A **probabilistic AI agent** — GPT, Claude, Gemini, or any transformer-based system — selects its next action based on the statistical likelihood of that action being correct given the current context. Given the same inputs twice, it may choose different actions. Steps can be inferred as complete without being executed. Validations can be skipped if the model assigns them low weight. This is not a bug — it is how language models work. The [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/) identifies this pattern — "excessive agency" — as a primary attack surface for agentic systems. A **deterministic AI agent** executes steps in a defined, reproducible order enforced by an independent gate — not the model. Each step must satisfy explicit preconditions before proceeding. No step can be skipped, replayed, or reordered. The execution path is governed by the enforcement layer. If a precondition fails, execution halts — immediately, unconditionally. This is what [AgenticRail](https://agenticrail.nz) enforces, and what frameworks like [NIST AI RMF 1.0](https://www.nist.gov/artificial-intelligence) and [ISO/IEC 42001:2023](https://www.iso.org/standard/81230.html) require as evidence of control. The difference is not academic. It is the difference between a system that might behave correctly and a system that provably did. ## Why probabilistic execution breaks in regulated contexts Consider an AI agent processing loan applications. Its spine might be: `intake → identity_check → credit_assessment → decision → notification`. In a probabilistic system: - —The model may infer that identity_check was implicitly completed based on prior context - —No record exists proving identity_check ran — only that the model said it did - —A regulator asks for evidence that identity verification occurred before credit assessment — you have none - —The audit trail is a log of what the model reported, not cryptographic proof of what the system executed The [EU AI Act](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689) and [ISO/IEC 42001:2023](https://www.iso.org/standard/81230.html) do not ask what the model intended to do. They ask what the system did, when, and whether a human could have intervened. Probabilistic execution cannot answer these questions with the required certainty. ## Comparing the two approaches | Property | Probabilistic agent | Deterministic agent | | Step execution | Inferred by model | Enforced by gate | | Audit trail | Model-reported log | Cryptographic receipt chain | | Replay protection | None — model may rerun steps | Nonce ledger, sealed sequences | | Failure mode | Silent — continues on error | Fail-closed — DENY on any failure | | Regulatory evidence | Reconstructed from logs | Gate decision record, pre-action | | Human-oversight evidence | Application layer only | Infrastructure layer, receipted | | Step-skipping | Possible — model may infer completion | Denied pre-execution — gate blocks out-of-order | ## How AgenticRail enforces determinism on probabilistic models AgenticRail does not replace the language model. It wraps it. The model still generates the agent's reasoning and actions — but before any action executes, it must pass through the gate. The enforcement layer operates independently of the model. The gate does not read the model's reasoning. It reads the step identifier, the function, the action type, the nonce, and the timestamp. It checks these against the sequence's current state in a **Cloudflare Durable Object** — a single-threaded, strongly consistent store that cannot be bypassed or concurrently modified. The gate returns ALLOW, DENY, or HALT. It does not return "probably fine." There is no confidence interval. There is no exception for urgent steps. If the gate says DENY, the step does not run. This is the definition of a **fail-closed design**: the default on any ambiguity, error, or missing precondition is denial. Every ALLOW produces an Ed25519-signed receipt written to tamper-evident, append-only storage; on sealing, a copy also goes to an independently held archive. The receipt records what step ran, what sequence it belongs to, the gate's decision, and the pack ID that links it to the next receipt in the chain. This chain is the proof — not a log you generate after the fact, but a gate decision recorded before the action ran. ## What "deterministic" does and does not mean here Deterministic enforcement does not mean the model's outputs are deterministic. The model can still generate varied responses. What is deterministic is the **sequence of steps that are authorised to execute**. The model may suggest a different order; the gate enforces the correct one. The model may claim a step completed; without a gate receipt, it didn't. This is the correct mental model: **deterministic sequence, probabilistic content**. The path is fixed. What the agent does at each step within the path is still governed by the model — but whether the step ran at all is provable. ## Implementation: adding gate enforcement in three steps AgenticRail adds deterministic enforcement to any agent with a single API call before each step: ``` # Before each step in your agent loop: response = requests.post( 'https://api.agenticrail.nz/v1/evaluate', headers={'Authorization': 'Bearer YOUR_KEY'}, json={ 'sequence_id': session_id, 'step': current_step, 'function': current_step, 'action_type': 'CHECK_STATE', 'action': 'loan_' + current_step, 'inputs': {'signal': 'loan_application'}, 'step_order': LOAN_SPINE, # ['intake','identity_check','credit_assessment','decision','notification'] — declare your spine on every call 'nonce': str(uuid4()), 'ts_ms': int(time.time() * 1000), } ) decision = response.json().get('decision') # ALLOW → proceed. DENY or HALT → stop. if decision != 'ALLOW': raise StepDeniedError(decision) ``` The gate computes its decision deterministically in a few milliseconds of CPU; the receipt is written automatically as part of the same operation. No separate logging call. No separate audit trail setup. The enforcement and the evidence are the same operation. ## When probabilistic is fine — and when it isn't Not every AI deployment needs sequence enforcement. A chatbot, a code assistant, a content generator — these are systems where probabilistic variation is acceptable and the cost of being wrong is low. You don't need a gate to write a draft email. You do need a gate when: - →The agent takes actions with real-world consequences (financial, medical, legal) - →A regulator can ask "prove this validation ran before that decision" - →The cost of a skipped step is higher than the cost of a blocked action - →Multiple agents or users share sequences and replay must be provably blocked - →Your system falls into a high-risk regulatory class (health, finance, welfare, education) In these contexts, probabilistic execution is not a performance characteristic — it is a compliance gap. The gate closes it. In April 2026, Microsoft released the [Agent Governance Toolkit](https://opensource.microsoft.com/blog/2026/04/02/introducing-the-agent-governance-toolkit-open-source-runtime-security-for-ai-agents/) — open-source runtime security for AI agents — acknowledging that the gap between model intent and executed action is the defining security problem for agentic AI in 2026. AgenticRail addresses this at infrastructure level, not the application layer where the model lives and where bypasses are possible. ## Best practices for deterministic AI agent audit logs If you are building or evaluating an AI agent for a regulated context, these are the properties your audit log infrastructure must satisfy. Application-layer logging — records generated by the agent itself — does not meet these requirements because the model can fabricate or omit entries. The gate must be independent of the model. - **1. Record before the action executes, not after** Post-execution logs can be lost, delayed, or — in an LLM agent — never written if the model decides the step was implicitly done. The gate decision must be recorded as the precondition to execution, not a side-effect of it. If there is no receipt, the step did not run. - **2. Unique nonce per step — enforce replay protection** Every gate request must include a single-use nonce. The gate maintains a nonce ledger per sequence; a repeated nonce returns `REPLAY_NONCE` and the step is blocked. Without this, a malfunctioning agent or an attacker can re-execute completed steps and corrupt the audit chain. - **3. Cryptographic receipts in immutable storage** Each gate decision should produce an Ed25519-signed receipt stored in append-only infrastructure, with sealed sequences additionally copied to an independently held archive. The signature covers a canonical serialisation of the receipt fields — any tampering breaks verification. This is what makes the audit trail provable rather than assertable. - **4. Seal sequences on completion** When the final step of a sequence completes, the sequence must be sealed. Any further requests on that sequence ID return `SEALED_SEQUENCE`. This prevents late replay — submitting additional steps to a completed sequence to alter its apparent history. - **5. Fail-closed on any ambiguity** The default on any missing precondition, malformed payload, policy mismatch, or system error must be denial — not silent continuation. A fail-open design (allow by default when uncertain) produces an audit trail that looks complete but has gaps wherever the guard was uncertain. A regulator will find those gaps. - **6. Enforce at infrastructure layer, not application layer** Application-layer controls live in the same process as the model. The model can bypass them — not through malice, but through hallucination. An infrastructure-layer gate is independent of the model: the model cannot report a step as done without a gate receipt existing. The separation is architectural, not procedural. ## Frequently asked questions Are AI agents deterministic or probabilistic? LLM-based AI agents are probabilistic by default — the same input can produce different outputs on different runs, steps can be skipped, and actions can be hallucinated as complete. They can be made to behave deterministically by wrapping them with an independent enforcement gate that verifies each step before execution. The gate decision is deterministic: given the same sequence state, policy, and request, it always returns the same ALLOW or DENY. The model's outputs remain probabilistic; the execution path becomes provable. What are best practices for AI agent audit logs? Record gate decisions before execution — not after. Use a unique nonce per step to block replay. Store Ed25519-signed receipts in tamper-evident, append-only infrastructure. Seal sequences on completion. Use fail-closed design so any ambiguity results in denial. Enforce at infrastructure layer, not application layer — the model cannot be trusted to audit itself. What is a deterministic AI agent? A deterministic AI agent enforces a fixed, reproducible sequence of steps via an independent gate before any action executes. The model still generates probabilistic reasoning and outputs — but whether each step actually ran is provably recorded. The model may suggest a different order; the gate enforces the correct one. The model may claim a step completed; without a gate receipt, it didn't. What is replay protection in AI agents? Replay protection prevents a previously executed step from being submitted again — accidentally or deliberately. It requires a unique nonce with every gate request. The gate maintains a nonce ledger per sequence; any repeated nonce returns `REPLAY_NONCE` and the step is blocked. Without replay protection, a malfunctioning agent can re-execute steps that already ran, triggering duplicate actions and corrupting the audit chain. Can an LLM-based agent be made deterministic? The model's outputs cannot be made deterministic — LLMs are probabilistic by design. What can be made deterministic is the sequence of steps authorised to execute. An independent gate wraps the model: before any step runs, it must pass sequence validation, policy checks, and nonce verification. The result is a deterministic sequence with probabilistic content — the path is fixed and provable; what the agent does at each authorised step is still model-generated. What does the EU AI Act require for AI agent audit trails? Articles 9, 11, 12, and 14 require high-risk AI systems to maintain logs that enable post-market monitoring, support incident investigation, and demonstrate that human oversight was possible at each stage. Application-layer logs — generated by the model — do not satisfy this because the model can infer steps as complete without executing them. The Act requires evidence of what the system did, not what the model reported. Infrastructure-layer enforcement, where an independent gate records decisions before actions execute, provides the required separation. Related [Automated Decisions and the Provable Safeguard: Asserted, Enforced, Provable →](https://agenticrail.nz/spec/enforceable-safeguards/) [The Completeness Specification: Eight Requirements for Evidence-Grade Records →](https://agenticrail.nz/spec/completeness/) [The AgenticRail Enforcement Specification →](https://agenticrail.nz/spec/) [Back to AgenticRail](https://agenticrail.nz/) · [API documentation](https://agenticrail.nz/docs/) · [Live demo](https://agenticrail.nz/demo/) --- # Tamper-Evident AI Agent Audit Logs — Deterministic Replay is Best Practice > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/blog/ai-agent-audit-log-best-practices/ > Site context: https://agenticrail.nz/llms.txt Published 9 May 2026 · Last reviewed 18 July 2026 · AgenticRail # AI Agent Audit Log Best Practices: Deterministic Replay, Cryptographic Receipts, Fail-Closed The fundamental problem with AI agent audit logs: **the model writes them**. An LLM-based agent records what it believes it did — not what it provably executed. Best practice is to move the record upstream: **an independent gate writes a cryptographic receipt before each action executes**. The result is an audit trail the model cannot influence, that supports deterministic replay for any audit, and that produces evidence for ISO 42001 A.6.1.6, EU AI Act Article 12, and NIST Measure 2.4 simultaneously. ## The six requirements for a production AI agent audit log Most production AI deployments use application-layer logging — the agent writes a record after each step completes. This is a good start and usually enough for internal observability. It is not enough for a compliance audit. An auditor reviewing an AI agent deployment needs to answer a different question: *did these steps provably execute, in this order, at these timestamps, with these inputs?* Application-layer logs cannot answer that question reliably. A production audit log that can withstand regulatory scrutiny requires six properties: - 01 **Pre-execution record**The gate decision is written before the action executes. A log written after execution can be fabricated, lost on failure, or overwritten. The record must precede the action — not follow it. - 02 **Nonce-based replay protection**Each step carries a unique nonce. The gate rejects any repeated nonce with REPLAY_NONCE. Without this, the same step can execute multiple times against the same sequence — duplicating real-world effects and corrupting the audit trail. - 03 **Cryptographic integrity**Each receipt is Ed25519-signed over all fields. Any modification to the record after write — payload, decision, timestamp, step name — breaks the signature. The record cannot be silently altered to show a different outcome. - 04 **Sequence sealing**When the final step runs, the sequence is sealed. No further steps can be appended to a closed chain. This prevents retroactive insertion of steps that didn't happen — a tactic that would otherwise allow a manipulated agent to make a skipped validation appear to have run. - 05 **Infrastructure-layer independence**The logging system must be independent of the model. Application-layer logs — records the AI system writes about itself — can be bypassed if the model infers a step as complete without executing it. The gate must sit between the model's decision and the action execution. - 06 **Fail-closed design**Any ambiguity, missing precondition, network error, or policy gap returns DENY or HALT — never a silent pass. A log that records "ALLOW" because no gate was consulted is indistinguishable from one that records "ALLOW" because the step legitimately passed. Fail-closed makes the distinction provable. ## Why AI agents cannot reliably log their own actions LLMs are probabilistic systems. They do not execute a deterministic program — they infer the most statistically likely next action given their current context. This creates a structural problem for self-reported audit logs. The self-reporting failure mode A model processing a loan application decides that identity verification *implicitly ran* — based on context suggesting it should have — and moves to the credit check step. It logs "identity_verified: true". The verification never ran. The log is accurate from the model's perspective. It is wrong. An auditor reviewing the log has no way to know. This is not a hallucination in the traditional sense — the model is not confabulating a wrong answer. It is doing what LLMs do: making a statistically reasonable inference from context. The problem is that inference is not execution, and a log that records inference as execution is not an audit trail. The OWASP Top 10 for LLM Applications identifies this pattern — **excessive agency** — as a primary attack surface for agentic systems. A model that proceeds without executing required steps is operating with excessive agency, and a self-reported log provides no evidence that it did not. ## What deterministic replay requires **Deterministic replay** means that for any completed AI agent sequence, you can reconstruct exactly what steps ran, in what order, at what timestamps, with what inputs — from the audit records alone, without re-running the model. (See: [Deterministic vs Probabilistic AI Agents — why the distinction decides compliance](https://agenticrail.nz/blog/deterministic-vs-probabilistic-ai-agents/).) This is only possible if: | Requirement | Application-layer log | Infrastructure-layer receipt | | Record written before execution | No — written after, or not at all if step fails | Yes — gate decision is the record | | Record independent of the model | No — model decides what to log | Yes — gate is a separate system | | Tamper-evident after write | No — database records can be updated | Yes — Ed25519 signature breaks on modification | | Replay attacks blocked | No — same step can be re-logged | Yes — nonce ledger rejects repeats | | Sequence provably complete | No — gaps are invisible | Yes — sealed chain with ordered receipts | Without these properties, a replay of an audit log is a replay of what the model said it did. With them, a replay is a reconstruction of what provably executed — verifiable without trusting the model's account. ## Replay protection: how nonces work in practice Every gate request carries a **nonce** — a UUID generated by the caller that is used exactly once. The gate checks the nonce against a ledger maintained per sequence. If the nonce has appeared before, the gate returns `REPLAY_NONCE` and blocks the step regardless of all other conditions. This matters in three scenarios: **Network retry loops.** An agent that receives a timeout may retry the same request. Without replay protection, the step executes twice — the second execution is real and the audit trail shows two receipts for the same logical action. With a nonce, the retry is blocked. **Adversarial replay.** An attacker captures a valid gate request and re-submits it later — possibly with a fresh timestamp — to trigger an action a second time. Nonce-based protection blocks this even if the timestamp is within the freshness window. **Malfunctioning agents.** An agent in a loop may re-submit a step it has already completed. The gate blocks the repeat and returns REPLAY_NONCE. The agent gets a clear error rather than a silent second execution. ## What a production audit receipt looks like Each gate decision produces one receipt — one per step, per sequence. The receipt is written before the action executes and stored in tamper-evident, append-only object storage with an Ed25519 signature over the canonical receipt. Gate receipt — sequence: loan-app-2847f3 / step: identity_verification ALLOW sequence_id loan-app-2847f3 step identity_verification decision ALLOW payload_hash SHA-256 of the full request — nonce, inputs, and step identity bound into the record prev_receipt_hash SHA-256 of the previous receipt — chains this step to the one before it ts_ms 1746748812041 — within freshness window signature Ed25519, base64 — signed over the canonical receipt, key_id: k2_2026-06-07_ed25519 recorded before action executed The signature is computed over a canonical JSON serialisation of the full receipt — keys sorted alphabetically, no whitespace variation. Any modification to any field after write produces a different value. The receipt cannot be silently updated to show a different decision, step, or timestamp. At audit time, a compliance report reads the receipt chain for a sequence from the KV index, verifies each signature, confirms step order, and confirms no gaps. The report is generated from the receipts — not from application logs, not from model-reported state. ## Timestamp freshness and the replay window Replay protection has two layers. The nonce blocks exact replay of a previous request. Timestamp freshness closes the window for replay-with-new-nonce attacks. Each gate request carries a `ts_ms` field — milliseconds since epoch, set by the caller at request time. The gate enforces a freshness window: if the timestamp is more than 300 seconds in the past or future, the request is rejected with `STALE_TIMESTAMP`. A valid nonce does not help if the timestamp is stale. This means an attacker who captures a valid gate request cannot submit it later with a fresh nonce — the timestamp is outside the freshness window. The request must be submitted within 5 minutes of the original timestamp, and with a unique nonce. Both conditions must be met simultaneously. ## Framework alignment: one receipt chain, three frameworks The same infrastructure-layer receipt chain answers the audit log requirements across all three major AI governance frameworks: ISO 42001 · A.6.1.6 Operational logging Requires logging enabling reconstruction of AI system behaviour for certification audits. The receipt chain provides step-by-step reconstruction with cryptographic integrity. EU AI Act · Article 12 Logging obligations Requires logs enabling post-market monitoring and incident investigation for high-risk AI systems. Pre-execution receipts independent of the model are exactly this record. NIST AI RMF · Measure 2.4 Runtime monitoring Requires monitoring mechanisms that detect performance degradation and unexpected behaviour. Gate decisions surface policy violations, out-of-order steps, and replay attempts in real time. The same gate receipt that evidences ISO 42001 A.6.1.6 evidences EU AI Act Article 12 and NIST Measure 2.4. A single enforcement layer produces evidence for all three simultaneously — no additional logging infrastructure required per framework. ## The compliance report For any sequence, a compliance report can be generated on demand. The report reads the receipt chain from the KV index, verifies each signature, confirms step order is intact, confirms no replays occurred, and surfaces any DENY or HALT decisions with the reason code. The report is formatted for auditor review — it answers the question "what did this AI agent actually execute?" with cryptographic evidence rather than application-reported state. See a live example of the compliance report generated from real gate receipts: Try the enforcement gate with the public demo key. Run a sequence, see the receipts written in real time, and generate the compliance report. [Try the demo](https://agenticrail.nz/demo/) [See compliance report →](https://report.agenticrail.nz/report) Related [Deterministic vs Probabilistic AI Agents: Why the Distinction Matters for Deployment](https://agenticrail.nz/blog/deterministic-vs-probabilistic-ai-agents/) The core distinction — what regulators actually ask, and how an external gate makes a probabilistic model’s execution path provable. [NIST AI RMF Mapping](https://agenticrail.nz/spec/nist-ai-rmf/) How the receipt chain maps to the NIST AI Risk Management Framework’s functions. [The Completeness Specification](https://agenticrail.nz/spec/completeness/) Eight requirements (R1–R8) that separate an evidence-grade enforcement record from an ordinary log. [Automated Decisions and the Provable Safeguard](https://agenticrail.nz/spec/enforceable-safeguards/) Asserted, enforced, provable — three tiers of safeguard, and why the difference decided Robodebt. --- # IETF Agent Audit Trail: What the Draft Standard Requires — and What It Doesn't > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/blog/ietf-agent-audit-trail/ > Site context: https://agenticrail.nz/llms.txt [AgenticRail](https://agenticrail.nz/) › [Blog](https://agenticrail.nz/blog/) › IETF Agent Audit Trail Standards 2026-05-12 · reviewed 2026-07-18 Kade Cowper # IETF Agent Audit Trail: What the Draft Standard Requires — and What It Doesn't There is a live IETF Internet-Draft that defines a JSON standard for AI agent audit records with hash chaining, trust levels, and mandatory fields. It cites EU AI Act Article 12 and ISO/IEC 42001. Here is what the draft requires, where it leaves gaps, and how AgenticRail aligns with — and goes beyond — it. ## The Draft `draft-sharif-agent-audit-trail` is an IETF Internet-Draft defining a standardised format for audit records produced by AI agent systems. It was published to address the absence of a common structure for agent audit logs — the gap that makes compliance attestation difficult when every deployment invents its own schema. The draft expires September 29, 2026. At that point it either advances toward RFC status, is revised, or lapses. For now it represents the closest thing to an emerging standard that developers, auditors, and compliance teams can reference when building or evaluating agent audit infrastructure. Draft Reference **draft-sharif-agent-audit-trail** — IETF Internet-Draft, version -00 (status re-verified 18 July 2026). Expires 2026-09-29. Regulatory references: EU AI Act Article 12, ISO/IEC 42001, SOC 2, PCI DSS. ## Mandatory Fields Every audit record under the draft must include the following fields. Optional fields can be added, but omitting any mandatory field renders the record non-conformant. | Field | Required | Description | | `record_id` | Required | Unique identifier for this record | | `timestamp` | Required | ISO 8601 timestamp of the event | | `agent_id` | Required | Identifier of the agent that produced the record | | `agent_version` | Required | Version string for the agent | | `session_id` | Required | Groups all records from one agent session | | `action_type` | Required | Categorises the action (e.g. tool_call, lifecycle) | | `action_detail` | Required | Structured object describing the specific action | | `outcome` | Required | Result: success / failure / timeout / denied / escalated | | `trust_level` | Required | L0–L4 verification assurance level | | `parent_record_id` | Required | Record that triggered this one (null for genesis) | | `prev_hash` | Required | Hash of the prior record; null for genesis | The `session_id` + `prev_hash` combination is what turns individual records into a chain. Every record knows what session it belongs to and cryptographically commits to the content of the record before it. This means you cannot insert, delete, or alter any record in the chain without invalidating all subsequent `prev_hash` values. ## The Hash Formula The draft specifies SHA-256 over **JSON Canonicalization Scheme** output (RFC 8785): Hash chain formula ``` prev_hash(N) = hex(SHA-256(JCS(record(N-1)))) ``` JCS (RFC 8785) produces a deterministic, canonicalised JSON encoding: alphabetically sorted keys, no insignificant whitespace, Unicode normalisation. The key property: two representations of the same logical record produce identical JCS output, and therefore identical hashes. Conversely, any change to field content, field order, or encoding in a prior record will produce a different hash, breaking the chain at the next record. The genesis record — the session start record — has `prev_hash: null` and `parent_record_id: null`. It uses `action_type: "lifecycle"` and `action_detail.event: "session_start"`. All subsequent records in the session chain back to it. AgenticRail alignment AgenticRail signs receipts with Ed25519 over canonical JSON (alphabetically sorted keys), and chains them with SHA-256 over the same canonicalisation via `prev_receipt_hash` (the draft's `prev_hash`) — the same structure the draft mandates. The `sequence_id` field maps directly to the draft's `session_id`. ## Trust Levels The `trust_level` field is mandatory on every record. The draft defines five levels: L0 No verification. The agent asserts its identity and produces records with no external check. Records can be self-reported and cannot be independently verified. L1 Self-signed. The agent signs its own records using a key it controls. The signature proves record integrity but doesn't verify the signing key itself came from a trusted authority. L2 Authority-signed. A trusted third party countersigns or issues records. The signing key is externally verifiable. L3 Mutual authentication. Both the agent and its counterparty verify each other's identity before records are produced. L4 Full mutual auth with certificate revocation checking and continuous monitoring. The highest assurance level — every verification is checked against live revocation data. Most production deployments today operate at L0 or L1. Compliance contexts targeting EU AI Act or ISO 42001 should aim for L2 minimum — authority-signed records that an auditor can verify without trusting the agent itself. ## Special Record Types ### Genesis Record The first record in every session. Marks session initialisation. `parent_record_id` and `prev_hash` are both null. All records in the session chain back to this one. Genesis record structure ``` { "record_id": "rec_0001", "timestamp": "2026-05-12T09:00:00Z", "session_id": "sess_abc123", "agent_id": "credit-approval-agent", "agent_version": "1.4.2", "action_type": "lifecycle", "action_detail": { "event": "session_start" }, "outcome": "success", "trust_level": "L2", "parent_record_id": null, "prev_hash": null } ``` ### Tombstone Record Used for GDPR-compliant deletion. When personal data in a record must be erased, a tombstone replaces the original record. The tombstone preserves the `record_id`, `timestamp`, and chain linkage fields (`prev_hash`, `parent_record_id`) so chain integrity is maintained, while removing the personal data. This lets you honour right-to-erasure requests without destroying audit chain continuity. ## What the Draft Requires The draft is explicit about structure. It requires: - All mandatory fields present on every record - Hash chaining using the JCS+SHA-256 formula - Trust level declared per record - Genesis record at session start - Outcome value from the specified set What it does not specify: how long records must be retained, which storage backend to use, whether the recording system must be independent of the agent, or when in the action lifecycle the record must be written. ## The Gap: Pre-Execution Recording The most significant gap in the draft is timing. The draft defines records of events that *occurred* — it records outcomes after actions complete. The outcome values reflect completion states: success, failure, timeout, denied, escalated. This means a fully conformant implementation could write all records after execution. An agent could complete every action in a session and then produce a conformant, hash-chained audit log retroactively. The chain would be internally consistent. The hashes would verify. But the records would not prove that any enforcement gate fired before execution — they would only record what the agent reported about itself. Critical gap The draft does not require that a record be written at the moment of authorisation rather than at the moment of completion. A post-execution log can be fully draft-conformant. That is not the same as pre-execution evidence. This matters for EU AI Act Article 12. Article 12 requires logs enabling *reconstruction of the sequence of events* — which implies the log must be a faithful record of what was enforced, not a summary written after the fact by the system being audited. ## How AgenticRail Aligns With the Draft | Draft Requirement | AgenticRail | Status | | SHA-256 over canonical JSON | SHA-256 over canonical JSON for the receipt chain (`prev_receipt_hash`); Ed25519 signatures over the same canonicalisation | Aligned | | `session_id` groups records | `sequence_id` groups all receipts in a session chain | Aligned | | `denied` outcome value | DENY decisions map to `denied` outcome; specific reason codes also provided | Aligned | | Tamper-evident record storage | Receipts written to tamper-evident, append-only storage, Ed25519-signed at write time; sealed sequences copied to an independently held archive | Aligned | | Trust level per record | Gate enforces key verification on all requests; receipts are signed by the gate — an authority independent of the agent (L2 characteristics) | Aligned | ## Where AgenticRail Goes Further | Capability | Draft standard | AgenticRail | | Record timing | Post-event (outcome recorded after action completes) | **Pre-execution** — receipt written at gate decision time, before action runs | | Step order enforcement | Not specified — records are individual events, no sequence enforcement | Strict step-order enforced across session; SEQUENCE_VIOLATION returned for out-of-order steps | | Replay protection | Not specified | Nonce ledger per session; REPLAY_NONCE for any reused nonce | | Sequence sealing | Not specified | Session sealed at final step; SEALED_SEQUENCE for any subsequent request | | DENY reason codes | Single `denied` outcome value | SEQUENCE_VIOLATION / REPLAY_NONCE / ACTION_NOT_ALLOWED / UNKNOWN_STEP / SEALED_SEQUENCE / STALE_TIMESTAMP / ARTIFACT_UNBOUND | | Timestamp freshness | Timestamp field required; no freshness check defined | |ts_ms − now| > 300s → STALE_TIMESTAMP — closes replay-with-fresh-nonce-after-delay | ## An AgenticRail Receipt Mapped to Draft Fields Here is an AgenticRail ALLOW receipt with the IETF draft fields mapped: AgenticRail receipt — IETF field mapping ``` { // draft: record_id (SHA-256, 64 hex chars) "pack_id": "24449424694a3f...e020", // draft: outcome ("success" / "denied") "decision": "ALLOW", "reasons": [], "executed": true, // permitted — not proof the downstream action performed // draft: session_id, agent identity, action_type, action_detail — carried in meta "meta": { "model_id": "client:acme-bank", "sequence_id": "credit-approval-20260512-001", "step": "intake", "function": "intake", "action_type": "CHECK_STATE" }, // binds the full request — nonce, inputs, labels — into the record "payload_hash": "9080bd2ac4da...86cb", // draft: prev_hash — SHA-256 of the prior receipt's canonical JSON "prev_receipt_id": "a7f3c91b22e0...54da", "prev_receipt_hash": "b6a18d234e38...338d", // draft: timestamp "ts_ms": 1715507244154, "key_id": "k2_2026-06-07_ed25519", "signature_alg": "Ed25519", "signature": "TpQr8f3aXz9c2b1d...", // base64, over the canonical receipt "version": "slp8_pack_1.0" } ``` The structural alignment is clear. And the pre-execution property needs no special field: the receipt *is* the gate decision, written at the moment of authorisation, before the action runs. The `executed` field records that the step was permitted — deliberately not a claim that the downstream action performed. ## DENY Receipt: The `denied` Outcome AgenticRail DENY — maps to draft outcome: "denied" ``` { "pack_id": "0098a55bab90...823e", // draft outcome: "denied" "decision": "DENY", // AgenticRail extension: specific reason codes, as an array "reasons": ["SEQUENCE_VIOLATION"], "executed": false, "meta": { "model_id": "client:acme-bank", "sequence_id": "credit-approval-20260512-001", "step": "execution", "function": "execution", "action_type": "SELECT_NEXT_STEP" }, "payload_hash": "b6a18d234e38...338d", "prev_receipt_hash": "b1d8e27c9a04...61f2", "ts_ms": 1715507311208, "key_id": "k2_2026-06-07_ed25519", "signature_alg": "Ed25519", "signature": "Nq4wRz1c8f3aXz9c..." } ``` The draft records `denied`. AgenticRail records `DENY` with `SEQUENCE_VIOLATION` in its `reasons` array — a step was submitted out of order. An auditor reading this receipt knows not just that something was denied, but exactly which policy rule fired and what the agent attempted. ## Regulatory Context The draft explicitly references the following regulatory frameworks: | Framework | Relevant Requirement | Draft coverage | | EU AI Act Article 12 | Automatic recording of events enabling reconstruction of the sequence | Structural — no pre-execution mandate | | EU AI Act Article 26 | Deployers retain logs at least 6 months | Not specified — retention policy outside draft scope | | ISO/IEC 42001 | AI management system risk controls and evidence | Structure aligns; enforcement controls outside draft scope | | SOC 2 | Availability, confidentiality, integrity controls | Hash chain satisfies integrity; storage controls outside draft scope | | PCI DSS | Audit log completeness and tamper evidence | Chain tamper evidence aligns; field completeness depends on implementation | The draft is a structural foundation. It defines how records relate to each other and what fields every record must carry. It does not specify the enforcement architecture that produces those records — that is left to implementors. For EU AI Act purposes, the draft alone gets you a well-formed log. Pre-execution enforcement is what makes that log admissible as evidence of control rather than observation. ## What This Means in Practice If you are evaluating agent audit infrastructure against the IETF draft, the questions to ask are: - **When is the record written?** At action completion, or at gate decision time before execution? The draft allows both. Only pre-execution records provide enforcement evidence. - **Who writes the record?** The agent itself (L0/L1), or an independent gate (L2+)? The draft requires trust level to be declared — it does not require independence. Auditors will ask. - **Are all 11 mandatory fields present?** Missing any one — including `trust_level` or `prev_hash` — makes the record non-conformant. - **Is the chain verifiable independently?** JCS canonicalisation must be reproducible without the original system. Verify hashes offline before claiming chain integrity. - **What does `denied` mean in your implementation?** The draft has one denied outcome. What rule fired? Which step was out of order? Reason codes are not required by the draft — but they are what compliance teams and auditors actually need. 11 Mandatory fields per record L0–L4 Trust verification levels RFC 8785 Canonicalisation standard (JCS) 2026-09-29 Draft expiry date ## Summary The IETF agent audit trail draft is the right structural starting point. It defines a hash-chained, tamper-evident record format with trust levels and mandatory fields that map cleanly onto EU AI Act, ISO 42001, and other compliance frameworks. If you are building agent audit infrastructure, building to the draft gives you a schema that regulators and auditors will recognise. The gap the draft leaves open is enforcement. A conformant log can be written post-hoc by the agent itself. For compliance contexts where the question is not just "what happened?" but "what was the agent permitted to do, and was that permission granted before execution?" — you need a gate that fires before execution and signs a receipt at the moment of decision. That is what AgenticRail provides, on top of the structural alignment the draft defines. ### See IETF-aligned receipts in the live demo Run a sequence through AgenticRail and inspect the hash-chained receipts — canonical JSON, Ed25519-signed, hash-chained, written pre-execution. [Open Demo](https://agenticrail.nz/demo/) [Read Docs](https://agenticrail.nz/docs/) [← All posts](https://agenticrail.nz/blog/) --- # Policy as Code for AI Agent Enforcement: What It Means and How It Works > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/blog/policy-as-code-ai-agent-enforcement/ > Site context: https://agenticrail.nz/llms.txt [AgenticRail](https://agenticrail.nz/) › [Blog](https://agenticrail.nz/blog/) › Policy as Code — AI Agent Enforcement Governance 2026-05-12 · reviewed 2026-07-21 Kade Cowper # Policy as Code for AI Agent Enforcement: What It Means and How It Works Policy as code is arriving in AI agent governance — Kyndryl, Microsoft, and Altimetrik are all publishing on it in 2026. Most of what they describe is declaration: expressing agent policy as structured configuration rather than prose. The part most implementations leave out is enforcement: a runtime gate that evaluates the policy against every action before execution and produces a signed receipt as proof. ## Why Can't AI Agent Policy Just Live in the System Prompt? Most AI agent "policies" today live in the system prompt. The prompt tells the agent what it's allowed to do, what steps to follow, what data it may access. This is policy-as-natural-language: readable by humans, interpretable by the model, unenforceable by anything. A system prompt is a probabilistic instruction. The model reads it and approximates compliance on each generation. There is no mechanism that prevents a non-compliant action from executing — if the model generates a bad output, the action runs. If a prompt injection overwrites the instruction, the agent follows the injection. If the model simply hallucinates a step that isn't in the policy, nothing stops it. | Policy expression | Machine-readable | Versioned | Enforced before execution | Auditable evidence | | System prompt / guidelines | No — natural language | No — lives in model context | No — probabilistic | No — model output only | | Post-hoc evaluation (LLM judge) | Partial — structured prompt | Partial — prompt versioning | No — runs after execution | Partial — evaluation records | | Policy as code — enforcement gate | Yes — structured contract | Yes — versioned with deployment | Yes — gate fires pre-execution | Yes — signed receipt per decision | ## What Is Policy as Code for AI Agents? Policy as code in the DevOps sense (Open Policy Agent, HashiCorp Sentinel) evaluates infrastructure configuration at deploy time — checking whether a proposed change conforms to policy before it is applied. That is useful, but it is a one-shot check at a single point in a deployment pipeline. Agent policy as code is a continuous runtime check. The policy is evaluated on every action, during a live session, in the critical window between the agent's decision to act and the action's execution. The enforcement point is not "before deploy" but "before each tool call." Three components are required: 1 — Step Order Contract - Declares the permitted sequence of steps - Machine-readable string or config - Versioned with the enforcement worker - Violations → SEQUENCE_VIOLATION 2 — Action Type Map - Declares which action categories each function permits - Versioned policy map (not prompt instructions) - Violations → ACTION_NOT_ALLOWED - Steps outside the declared order → UNKNOWN_STEP 3 — Enforcement Gate - Independent of the agent — cannot be overridden - Evaluates policy before execution - Returns ALLOW or DENY - Writes signed receipt at decision time The policy is not "what the agent believes it should do." The policy is what the gate evaluates against. The agent's understanding is irrelevant — the gate's decision is authoritative. ## How Do You Enforce Step Order in an AI Agent Before It Executes? AgenticRail implements policy as code as a two-part contract: the step order and the function/action_type map. **The step order** is declared as an ordered list. For an 8-step MSMD spine: Step order policy — versioned environment variable ``` SLP8_STEP_ORDER_MSMD="intake,disruption,instability,state_read,internal_driver,execution,boundary,settle" ``` This string is the policy. It is stored as an environment variable on the enforcement worker, deployed as part of the worker version, and auditable via the deployment history. Every receipt written by the gate carries the policy identifiers in effect at decision time (`policy_map_ids`, in the receipt metadata) alongside the signing key identifier (`key_id`) — the policy version is stamped into the receipt that proves it ran. **The function/action_type map** declares which action categories each function permits: Policy map — function → permitted action types ``` // an illustrative domain policy — your map, your action types "intake": ["CHECK_STATE", "READ_INPUT"] "execution": ["WRITE_DB", "CALL_EXTERNAL_API"] "settle": ["SEAL_SEQUENCE"] ``` An agent attempting to call `WRITE_DB` during `intake` — regardless of what its prompt or reasoning said was appropriate — receives `DENY: ACTION_NOT_ALLOWED` before the write executes. AgenticRail's own production policy for the MSMD spine carries a sharper rule worth copying: the `execution` step (the doer) permits only `SELECT_NEXT_STEP` and `PAUSE_CYCLE` — it cannot record its own results. Witnessing happens at the following step (`boundary`), and a result recorded there must carry a verifiable link to the receipt of the work it attests to, or it is denied (`ARTIFACT_UNBOUND`). The doer cannot self-attest; that separation is policy, enforced. ## What Actually Stops a Non-Compliant Agent Action From Running? The gate is what separates policy-as-code from policy-as-documentation. Without a gate, you have a policy document. With a gate, you have enforcement. The gate sits between the agent and every downstream action. The agent does not call tools directly — it calls the gate, which evaluates the declared policy and decides whether the action may proceed. The agent cannot route around the gate; it cannot modify the policy at runtime; it cannot bypass the nonce check or the step order constraint. Key property The agent is the regulated system. The gate is the regulator. A system cannot regulate itself — the independence of the gate is what makes the policy enforceable rather than advisory. Every gate decision produces a signed receipt, written before the action executes: ALLOW receipt — policy check passed, action authorised ``` { "pack_id": "24449424694a3f...e020", // SHA-256, 64 hex "decision": "ALLOW", "reasons": [], "executed": true, // permitted — not proof the downstream action performed "meta": { "model_id": "client:acme-bank", "sequence_id": "loan-approval-20260512-001", "step": "execution", "function": "execution", "action_type": "SELECT_NEXT_STEP", "policy_map_ids": ["msmd_policy_v1"] }, "payload_hash": "9080bd2ac4da...86cb", "prev_receipt_hash": "b6a18d234e38...338d", "ts_ms": 1715508000000, "key_id": "k2_2026-06-07_ed25519", "signature_alg": "Ed25519", "signature": "TpQr8f3aXz9c2b1d..." // base64, over the canonical receipt } ``` ## What Happens When an AI Agent Action Violates Policy? When the policy is violated, the gate returns a specific reason code. Each code maps to a distinct policy rule: SEQUENCE_VIOLATION Step submitted out of declared order. Step order policy enforced. ACTION_NOT_ALLOWED Action type not in the permitted set for this function. UNKNOWN_STEP Step/function not present in this sequence's own declared step order. REPLAY_NONCE Nonce already used in this session. Replay protection policy enforced. SEALED_SEQUENCE Session reached final step and was sealed. No further actions permitted. STALE_TIMESTAMP Request timestamp outside the 5-minute freshness window. FUNCTION_STEP_MISMATCH Step and function fields disagree. The contract requires step === function. ARTIFACT_UNBOUND A result recorded at the witnessing step without a verifiable link to the receipt of the work it claims. The doer cannot self-attest. Each denial produces a signed receipt — tamper-evident, pre-execution evidence that the policy ran and what it rejected. These receipts are the operational exhibits that compliance auditors, EU AI Act documentation, and ISO 42001 evidence packages cite. ## How Is AI Agent Policy Versioned and Audited? Because the policy is expressed as code — not embedded in a prompt — it has all the properties of code: - **Versionable:** every policy change is a deployment. The git history and worker deployment log are the policy audit trail. - **Diffable:** you can compare two policy versions and see exactly what changed — which steps were added, which action types were permitted or revoked. - **Attributable:** each receipt references the key_id of the signing key active at decision time. An auditor reviewing receipts from any session can determine which policy version was in effect for each decision. - **Testable:** the policy can be tested in isolation from the agent. Submit a sequence with a deliberate SEQUENCE_VIOLATION — the gate must return DENY. The policy is verifiable independently of the model that calls it. 8 Specific DENY reason codes Pre-exec Receipt written before action runs Versioned Policy stamped into every receipt ## Does Policy as Code Satisfy EU AI Act, ISO 42001, or NIST AI RMF Compliance? | Framework | Requirement | What policy as code evidences | | EU AI Act Article 9 | Risk management system — identify, analyse, mitigate risks | The declared risk boundary plus proof it was enforced — the evidenced core of a risk management system, not the whole system | | EU AI Act Article 12 | Automatic logging enabling reconstruction of events | Pre-execution receipts are the reconstruction anchors — not post-hoc observations | | ISO/IEC 42001 A.6.1.6 | Controls for AI system operation — documented and evidenced | Policy document + receipt chain = documented control + evidence it ran | | NIST AI RMF Manage 2.4 | Accountability mechanisms for AI system decisions | Every gate decision attributed to a policy version, signed, and stored tamper-evidently | | OWASP ASI01 (Goal Hijack) | Prevent agent from being redirected to unauthorised objectives | Step order and action type policy enforced externally — prompt injection cannot override the gate’s evaluation | ## Why Do Most "Policy as Code" Implementations Still Not Enforce Anything? The industry conversation about policy as code for AI agents tends to stop at declaration. Expressing agent governance as structured configuration rather than prose is valuable — it is readable by tools, comparable across versions, and unambiguous in intent. But declaration without enforcement is documentation. A policy document does not prevent a non-compliant action from executing. It describes what should happen; it does not guarantee what does happen. The enforcement gate is what makes the code operative. Without it, "policy as code" is a better way of writing the same unenforceable guidelines that used to live in the system prompt. ### See policy as code in action Run a sequence through the AgenticRail gate — submit a step out of order and inspect the SEQUENCE_VIOLATION receipt. [Open Demo](https://agenticrail.nz/demo/) [Read Docs](https://agenticrail.nz/docs/) [← All posts](https://agenticrail.nz/blog/) --- # Pre-Action Authorization for AI Agents: The Missing Security Layer > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/blog/pre-action-authorization-ai-agent/ > Site context: https://agenticrail.nz/llms.txt [AgenticRail](https://agenticrail.nz/)›[Blog](https://agenticrail.nz/blog/)›Pre-Action Authorization Security 2026-05-12 · reviewed 2026-07-22 Kade Cowper # Pre-Action Authorization for AI Agents: The Missing Security Layer The gap between what an AI agent *can* do and what it *should* do is an authorization problem, not an alignment problem. Model alignment shifts the distribution of outputs toward safe behaviour — it cannot guarantee any individual action. Pre-action authorization is the control that fires before every tool call, evaluates it against declared policy, and blocks it before execution if it does not pass. An independent adversarial study found that under a strict pre-action gate, attack success against an AI agent dropped from 74.6% to zero. AgenticRail enforces pre-action authorization on every step — ALLOW or DENY, with a signed receipt written before the action executes. [Try the demo](https://agenticrail.nz/demo/) [Read the docs](https://agenticrail.nz/docs/) ## What an independent study found Researchers published ["Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents"](https://arxiv.org/abs/2603.20953) (arXiv:2603.20953), evaluating a system they call Open Agent Passport (OAP) in a live adversarial testbed — 4,437 authorization decisions across 1,151 sessions, with a bounty for successful attacks. The results were not close. 74.6% **Attack success — permissive policy**Social engineering attacks succeeded in manipulating the agent into executing prohibited actions, model alignment alone. 0% **Attack success — restrictive OAP policy**Zero successful attacks across 879 attempts under a restrictive pre-action authorization policy. Same model, same attack vectors. The model didn't change. The alignment training didn't change. The only difference was a pre-action gate evaluating every tool call against declared policy before execution. This is independent, third-party evidence for AgenticRail's own architectural bet, not a study AgenticRail ran or commissioned — cited here because it's the sharpest evidence available that this class of defence works, and because a vendor's own claims about its own product shouldn't be the only source you check. ## Model alignment, post-hoc evaluation, and pre-action authorization | Approach | When it fires | What it guarantees | | Model alignment | Training time | Nothing per-action — shifts a distribution, doesn't set a boundary | | Post-hoc evaluation | After execution | Nothing before the fact — finds violations after the action already ran | | Pre-action authorization | Before execution | The action itself — denied before it runs if policy fails | Pre-action authorization and [sequence enforcement](https://agenticrail.nz/blog/policy-as-code-ai-agent-enforcement/) are complementary, not the same control. Pre-action authorization asks whether a specific action is permitted by policy. Sequence enforcement asks whether the step containing that action is the next permitted step in a declared order. An agent can pass one and fail the other — both must hold for the record to be complete. ## What a pre-action authorization receipt actually contains Every gate decision produces a receipt, written before the action executes. Real fields, not illustrative placeholders: loan-proc-3341a · boundaryALLOW pack_id: "24449424...e020" // SHA-256 decision: "ALLOW" reasons: [] executed: true // permitted — not proof the write itself succeeded meta.action_type: "WRITE_RECORD" payload_hash: "9080bd2a...86cb" prev_receipt_hash: "b6a18d23...338d" key_id: "k2_2026-06-07_ed25519" signature_alg: "Ed25519" loan-proc-9982b · executionDENY decision: "DENY" reasons: ["SEQUENCE_VIOLATION"] executed: false meta.action_type: "WRITE_RECORD" // attempted at the wrong step payload_hash: "a1f0e3c8...552d" prev_receipt_hash: "24449424...e020" The DENY receipt is as tamper-evident as the ALLOW. It proves the gate intercepted a violation before the write executed — not that a violation was found in a later review. Storage is tamper-evident and append-only; a sealed sequence cannot be reopened without leaving a detectable break in the hash chain, and sealed sequences are additionally copied to an independently held archive at the moment of sealing. ## How much latency this actually adds Worth being honest about, since the cited study reports its own system's number and it's easy to blur the two: OAP measures a 53ms median for its own architecture. That describes their system, not AgenticRail's — the two shouldn't be quoted as if interchangeable. AgenticRail's own gate, pressure-tested under real adversarial load, measures roughly 1.5–2.1 seconds for a cold-started sequence, with a further ~0.6–0.7 seconds of durable-storage write cost on every call. Not sub-100-millisecond. The property that matters isn't speed — it's that the decision happens, and the receipt is written, before the action runs, every time, regardless of how long that takes. ## Pre-action authorization and OWASP's Top 10 for Agentic Applications OWASP's Top 10 for Agentic Applications 2026 names several risks pre-action authorization directly addresses: | Code | Risk | How the gate responds | | **ASI01** | Agent Goal Hijack | The gate evaluates the action against declared policy, not the agent's stated goal — a hijacked goal that skips steps still gets SEQUENCE_VIOLATION. | | **ASI02** | Tool Misuse and Exploitation | Policy declares permitted functions and action types per step. An action type not in policy returns DENY · ACTION_NOT_ALLOWED before the tool runs. | | **ASI03** | Agent Identity and Privilege Abuse | The sequence contract is the privilege boundary. Steps outside the declared order return DENY · UNKNOWN_STEP; sealed sequences cannot be extended. | ## What this evidences for compliance A pre-action receipt written before execution is a reconstruction anchor, not a post-hoc observation — the kind of evidence EU AI Act Article 12 logging and ISO/IEC 42001 A.6.1.6 operational-logging requirements point toward. It produces evidence toward those obligations; it does not by itself satisfy a risk-management or human-oversight requirement in full — those remain organisational work the receipt chain supports, not replaces. Run a sequence in the demo. Attempt a prohibited action. See the DENY receipt written before it executes. [Try the demo](https://agenticrail.nz/demo/) [Compliance report](https://report.agenticrail.nz/report) Related [Policy as Code for AI Agent Enforcement](https://agenticrail.nz/blog/policy-as-code-ai-agent-enforcement/) The full policy contract — step order, action types, and the enforcement gate that makes it operative. [Are AI Agents Deterministic or Probabilistic?](https://agenticrail.nz/blog/deterministic-vs-probabilistic-ai-agents/) Why an enforcement layer has to be deterministic, and what that means in practice. [AI Agent Audit Log Best Practices](https://agenticrail.nz/blog/ai-agent-audit-log-best-practices/) Deterministic replay and what an evidence-grade audit trail actually requires. [Automated Decisions and the Provable Safeguard](https://agenticrail.nz/spec/enforceable-safeguards/) Asserted, enforced, provable — and why the difference decided Robodebt. [← All posts](https://agenticrail.nz/blog/) --- # Cryptographic AI Audit Trail: What Makes It Cryptographic and Why It Matters > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/blog/cryptographic-ai-audit-trail/ > Site context: https://agenticrail.nz/llms.txt [AgenticRail](https://agenticrail.nz/)›[Blog](https://agenticrail.nz/blog/)›Cryptographic AI Audit Trail Security 2026-05-12 · reviewed 2026-07-22 Kade Cowper # Cryptographic AI Audit Trail: What Makes It Cryptographic and Why It Matters A regular audit log records what a system **says it did**. A cryptographic AI audit trail proves what it **actually did** — and that the record hasn't been touched since. Not a matter of degree: a specific set of mechanisms — a signature over a canonical serialisation, a key ID, a hash chaining each receipt to the one before it, and an independently held archive. This walks through what each one does, and what happens when you remove it. Every AgenticRail gate receipt is Ed25519-signed (legacy receipts before 2026-06-07 remain HMAC, verify-only) and independently verifiable offline. [Try the demo](https://agenticrail.nz/demo/) [Public keys](https://agenticrail.nz/spec/receipt-public-keys.json) ## What a regular audit log cannot prove Most AI agent deployments produce audit logs — step names, timestamps, decisions, inputs, living in a database or a log aggregator. When an auditor asks what the agent did, you export the records and present them. The problem isn't the content. It's that **nothing in the records proves they haven't changed** since they were written. A database row can be updated. A log file can be overwritten. An administrator with the right permissions can delete an inconvenient entry, and nobody outside the system can detect it. The trusted-log problem A regulator asks an AI operator to prove human oversight ran before each automated decision last quarter. The operator produces the logs. Every record shows the oversight step completed first. The regulator's question: how do we know these records haven't been updated since? The operator's answer: access controls and a change-management process. The regulator's problem: that requires trusting the operator. The point of the requirement was evidence that doesn't. ## The mechanisms that make an audit trail cryptographic Encryption protects data in transit and at rest — it says nothing about whether the data was modified. Cryptographic integrity is a different property, built from a specific set of mechanisms. Remove any one and the trail loses its tamper-evidence. - Mechanism 1 Signature over all fields (Ed25519) Every current receipt is Ed25519-signed over all its fields, verifiable offline by anyone with the published public key. If any field changes after signing — decision, timestamp, step, nonce, any input — the recomputed signature won't match the stored one. Receipts written before 2026-06-07 use HMAC-SHA256 instead, kept for legacy verification only; new receipts are never HMAC-signed. - Mechanism 2 Canonical JSON serialisation Signing operates on bytes, not objects. Before signing, the receipt is serialised to a canonical byte sequence — keys sorted alphabetically, no whitespace. Different serialisations of the same object produce different bytes and therefore different signatures; canonical form ensures the signer and any verifier, in any language, produce identical bytes for the same receipt. - Mechanism 3 Key ID in every record Each receipt stores the ID of the signing key used — e.g. `k2_2026-06-07_ed25519`. Signing keys rotate periodically. Without a key ID, a verifier checking receipts after a rotation can't tell which key to use. With one, verification selects the correct key regardless of when the receipt was written, across any number of rotations, with no re-signing. - Mechanism 4 A hash chaining each receipt to the one before it Every receipt carries `prev_receipt_hash` — a SHA-256 of the entire previous receipt's canonical content, signature included. Altering an earlier receipt breaks every hash after it, not just that record — a single tampered receipt is caught immediately, and where it broke is visible. - Mechanism 5 An independently held archive The hash chain alone has one honest gap: someone holding the signing key could rewrite an entire chain and re-sign it consistently — internally coherent, still wrong. Sealed sequences are additionally copied, at the moment of sealing, to a separate write-once store the operator doesn't control the same way. A rewrite by the operator is then detectable by comparison against that independent copy, not just against itself. ## What each mechanism catches | Attack or failure mode | Regular log | Cryptographic trail | | Modify a DENY to ALLOW after the fact | Undetectable | Signature breaks on verification | | Delete a record showing a violation | Undetectable | Breaks the hash chain from that point on | | Change a timestamp to alter apparent order | Undetectable | Timestamp is a signed field — signature breaks | | Rewrite an entire chain, re-signed with the real key | N/A | Not caught by the chain alone — caught by comparison against the independent archive | | Verify old receipts after key rotation | N/A | Key ID selects the correct historical key | | Third-party verification without system access | Impossible | Needs only the receipt and the public key | That third-to-last row is the honest one, worth sitting with rather than glossing over: the signature and the hash chain protect against tampering by anyone *without* the signing key. They don't, alone, protect against the operator itself rewriting history — that's what the independent archive is for, and it's the reason it exists rather than being a redundant extra layer. ## What a cryptographic receipt actually contains A real receipt shape — Ed25519, current ``` pack_id: "24449424...e020" // SHA-256 decision: "ALLOW" reasons: [] executed: true // permitted — not proof the downstream action ran meta: { model_id: "client:acme-underwriting", sequence_id: "underwriting-9f3a1", step: "bias_audit", function: "bias_audit", action_type: "VALIDATE_INPUT", policy_map_ids: ["msmd_policy_v1"] } payload_hash: "9080bd2a...86cb" prev_receipt_hash: "b6a18d23...338d" // hash of the FULL prior receipt ts_ms: 1747043892114 key_id: "k2_2026-06-07_ed25519" signature_alg: "Ed25519" signature: "TpQr8f3aXz9c2b1d..." // base64, over canonical JSON of everything above ``` None of these fields are metadata that can change after signing — every one is inside the signed content. `model_id`, `sequence_id`, `step`, `function`, and `action_type` live inside `meta`, not at the top level. ## Canonical JSON is not optional System A serialises with a plain `JSON.stringify()`. System B sorts keys first. If the receipt's keys aren't already alphabetical, the two produce different byte sequences from the same object — different signatures — and System B incorrectly reports a genuine receipt as tampered. The problem compounds across languages: Python's `json.dumps()`, JavaScript's `JSON.stringify()`, Go's `encoding/json` all serialise the same object differently by default. A receipt signed in one and verified in another fails unless both use the same canonical form. Canonical form Keys sorted alphabetically at every nesting level, no whitespace, consistent number formatting, arrays in order. The same shape as [RFC 8785 (JSON Canonicalization Scheme)](https://datatracker.ietf.org/doc/html/rfc8785) — any conforming implementation produces identical bytes. ## How the chain was actually tested, not just described On 2026-07-11, a sealed receipt was deliberately overwritten in storage with a fabricated version, without the real signing key. The live compliance report caught it immediately — signature invalid, chain broken. The receipt was restored and the report returned clean. Two things that test showed, worth stating plainly rather than just asserting: the hash chain alone can't protect its own last link (nothing commits to a chain's final receipt but its own signature), and a corruption made *with* the real signing key would re-sign cleanly and only be caught by the separate archive comparison — not by the chain or the signature alone. That's the honest division of labour between the two mechanisms, confirmed by actually trying to break it, not just claimed. ## What compliance frameworks actually require None of EU AI Act Article 12, ISO 42001 A.6.1.6, or NIST Measure 2.4 use the word "cryptographic." All three require properties only cryptographic signing provides — and a cryptographic audit trail produces evidence toward each, without itself constituting full compliance with any of them. EU AI Act · Article 12 Reconstruction of events Requires records a regulator can verify without trusting the operator. Cryptographic signing makes that verification independent of the operator being trustworthy or even reachable. ISO 42001 · A.6.1.6 Operational logging Certification auditors need records that prove behaviour, not records that describe it. A signed receipt is evidence a decision was made and hasn't changed since — a database row requires trusting whoever administers the database. NIST AI RMF · Measure 2.4 Tamper-evident monitoring Requires monitoring that detects unexpected behaviour and preserves the evidence. A DENY receipt that caught a violation can't be quietly removed once written. Run a sequence, generate a receipt, and verify it yourself against the published keys — no account, no callback to AgenticRail. [Try the demo](https://agenticrail.nz/demo/) [Verify a receipt](https://report.agenticrail.nz/report) Related [AI Agent Audit Log Best Practices](https://agenticrail.nz/blog/ai-agent-audit-log-best-practices/) What makes an audit trail evidence-grade rather than just a log — the requirements this post's mechanisms satisfy. [Are AI Agents Deterministic or Probabilistic?](https://agenticrail.nz/blog/deterministic-vs-probabilistic-ai-agents/) Why the enforcement layer has to be deterministic even when the agent it governs is not. [Pre-Action Authorization for AI Agents](https://agenticrail.nz/blog/pre-action-authorization-ai-agent/) Independent evidence that intercepting actions before execution beats catching them after. [The Completeness Specification](https://agenticrail.nz/spec/completeness/) The eight requirements separating an evidence-grade record from an ordinary log, vendor-independent. --- # ISO/IEC 42001 for Agentic AI: The Certification Evidence Gap That Policies Can't Close > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/blog/iso-42001-agentic-ai/ > Site context: https://agenticrail.nz/llms.txt Published 9 May 2026 · Updated 23 July 2026 · AgenticRail # ISO/IEC 42001 for Agentic AI: The Certification Evidence Gap That Policies Can't Close **ISO/IEC 42001:2023** is not a compliance checklist — it is a certification standard. The difference matters. A compliance checklist asks: do your policies say the right things? A certification audit asks: *show me the evidence that your controls ran.* For organisations deploying agentic AI, the most demanding ISO 42001 controls — **Annex A.6.1.6** (operational logging enabling reconstruction of AI system behaviour) and the human oversight controls — both require the same thing: documented proof of what the AI system did, at the moment it did it. This article covers - [What ISO/IEC 42001:2023 is and who needs it](#what-is-iso-42001) - [Where agentic AI creates control gaps](#controls-grid) - [Annex A.6.1.6 — Operational logging and reconstruction](#a-6-1-6) - [Clause 9.1 — Monitoring, measurement, analysis and evaluation](#clause-9-1) - [Human oversight controls — evidence, not the control itself](#human-oversight) - [The receipt chain as ISO 42001 audit evidence](#receipt-chain) - [Cross-framework: one chain, three standards](#cross-framework) ## What ISO/IEC 42001:2023 is — and why certification changes the evidence requirement ISO/IEC 42001:2023 is the international standard for AI management systems, published in December 2023. It provides a structured framework — modelled on ISO 9001 and ISO 27001 — for organisations to establish, implement, maintain, and continually improve how they develop and deploy AI systems. Organisations already certified to ISO 9001 (quality management) or ISO 27001 (information security) will find the clause structure familiar: policy, risk assessment, operational controls, performance evaluation, and improvement. The critical distinction between ISO 42001 and advisory frameworks like NIST AI RMF is what certification requires. **ISO auditors do not accept policy documents as evidence of control operation.** They require documented records — logs, receipts, decision records — that demonstrate controls ran during the period under audit. For agentic AI systems, this creates an acute problem: most AI governance tooling produces policies, dashboards, and reports. Very little produces per-action evidence that a control executed before the agent did. ISO/IEC 42001 is not legally mandated in most jurisdictions, but it is increasingly referenced in procurement requirements, enterprise partner questionnaires, and as a conformity path for risk management obligations under regulation. Organisations pursuing ISO 42001 certification for AI are typically those already operating under ISO management systems — financial services, healthcare, manufacturing, critical infrastructure. ## Where agentic AI creates control gaps ISO/IEC 42001 Annex A defines the normative controls. Four areas are where agentic AI systems most commonly create evidence gaps during certification audits: Evidence gap A.6 — AI System Lifecycle Operational controls for AI system deployment. A.6.1.6 requires logging sufficient to reconstruct AI system behaviour. Most agentic AI produces logs of what the model reported — not records of what the control layer enforced. Evidence gap A.7 — Human Oversight Controls requiring human review and intervention mechanisms. For agentic AI, the gap is structural: if the only way to stop the system is to ask the model to stop, human oversight is nominal — not a control. Measurement gap Clause 9 — Performance Evaluation Monitoring, measurement, and analysis of AI system behaviour. Clause 9.1 requires methods appropriate to the risk. For agentic AI, per-session metrics are insufficient — evidence must be per-action. Operational Clause 8 — Operation Risk treatment embedded in AI system operation. Clause 8 requires that risk controls are part of the operational process — not a parallel review exercise running separately from the AI system. The audit failure pattern is consistent: organisations demonstrate strong policy controls (Clause 5, Clause 6 planning) but cannot produce per-action evidence for operational controls (A.6, A.7) and performance evaluation (Clause 9). The gap is not in governance intent — it is in the mechanism that would produce the evidence. ## Annex A.6.1.6 — Operational logging and reconstruction of AI system behaviour A.6.1.6 Operational logging enabling reconstruction of AI system behaviour ISO/IEC 42001 Annex A.6.1.6 requires that organisations implement operational logging for AI systems at a level that enables **reconstruction of AI system behaviour**. The word "reconstruction" is precise. It is not sufficient to log that a sequence ran — the log must enable a complete picture of what the system did, in what order, at what time, and under what conditions. For agentic AI, the failure mode that this control targets is probabilistic behaviour: a model that skips a step, infers a condition was met, or proceeds without explicit authorisation. If the only log is a model-generated output report, reconstruction is impossible — the model's report of what it did may not reflect what actually ran. **How sequence enforcement addresses it:** Every gate decision — ALLOW or DENY — is written to tamper-evident storage before the agent step executes. The receipt records the sequence ID, step, function, action type, the gate decision, a UTC timestamp, a payload hash, the previous receipt's hash, the signing key ID and algorithm, and a cryptographic pack ID. Each receipt carries `prev_receipt_hash` — a SHA-256 of the previous receipt's full signed content — alongside `prev_receipt_id`, so altering any earlier receipt breaks the hash chain at the next link and is detectable. To reconstruct exactly what ran, in what order, at what time: read the chain. The chain is the reconstruction. It is not derived from model output — it is written by the enforcement layer at the moment each step is decided. **Audit evidence produced:** The verification report generates a full chain proof — per-step enforcement log, Ed25519 signature verification for every receipt, hash-link verification from step 0 → N, a comparison against an independently held archive copy, and a plain-language compliance narrative. This produces the documented, reconstructable record Annex A.6.1.6 calls for. It does not, on its own, discharge the obligation — that stays with the organisation — but it is the evidence an auditor asks to see. ## Clause 9.1 — Monitoring, measurement, analysis and evaluation Clause 9.1 Monitoring and measurement of AI system performance at appropriate intervals ISO/IEC 42001 Clause 9.1 requires that organisations determine what needs to be monitored and measured, what methods are appropriate, and when analysis and evaluation should occur. For agentic AI systems making consequential decisions, **appropriate intervals means per-action** — not per-session, not daily dashboards, not weekly reports. The common implementation gap is treating Clause 9.1 as a reporting requirement. Aggregate metrics satisfy the letter of the clause for low-risk systems. For agentic AI in regulated contexts — underwriting, hiring, clinical triage, access control — an auditor will ask: how do you know the system behaved correctly on this specific decision, at this specific time? Aggregate metrics cannot answer that question. **How sequence enforcement addresses it:** Gate statistics are recorded per-decision: total evaluations, ALLOW/DENY ratios, step distribution, sequence completion rates, and denial reason codes. These are written on every gate call and surfaced in the dashboard in real time. For Clause 9.1, this provides monitoring that is contemporaneous with execution at the granularity the clause asks for — every action, not every session. The receipt chain enables full retrospective analysis: which steps were denied, at what timestamps, for what reason, across how many sequences. ## Human oversight controls — the gate is the evidence, not the control A.7 Controls Human review and intervention mechanisms for AI system operation ISO/IEC 42001 Annex A.7 defines human oversight controls — the mechanisms by which humans can review AI system behaviour and intervene when needed. For agentic AI, the critical test is not whether a human *could* intervene, but whether the process actually routes decisions to human-controlled authorisation before the system proceeds. The audit failure here is structural: if the AI system can run a complete sequence without any human-controlled checkpoint, then human oversight is an option, not a control. A certification auditor will ask: show me the mechanism, and show me it fired. A policy that says "humans review outputs" is not a mechanism — it is a procedure. **Be precise about what enforcement is and isn't:** sequence enforcement does not, by itself, constitute the human review-and-intervention control A.7 describes. A person reading and approving an AI decision is an organisational measure, and it stays yours. What the gate provides is the evidence layer beneath that control. No agent step executes without clearing the gate; the model cannot self-authorise or replay a previously issued ALLOW; and where your process requires a human to authorise a step, that authorisation can be bound into the receipt as a signed attestation — so the record shows the human step happened, at that point, before the sequence continued. The oversight is yours to design and to run. The gate makes it evidenced rather than merely asserted. **Audit evidence produced:** Denial logs showing the gate blocked non-compliant steps before execution, with timestamps and reason codes. Bound human-authorisation attestations, where your process requires them. Sequence seal records showing that a completed sequence cannot silently accept new steps. Each DENY is evidence a step was stopped before it ran — a record written at the moment of the decision, not a report assembled afterward. ## The receipt chain as ISO 42001 audit evidence ISO 42001 certification audits require documented evidence. The receipt chain AgenticRail produces is designed to be that documentation — not a report generated after the fact, but a record written at the moment of each enforcement decision. Each receipt is cryptographically signed using a versioned key — Ed25519 for current receipts, legacy HMAC for anything signed before 2026-06-07. The signature covers a canonical JSON serialisation — alphabetically sorted, deterministic. Every receipt records the sequence ID, step, function, action type, gate decision, timestamp, a payload hash, the signing key ID and algorithm, and a pack ID. Receipts are hash-linked via `prev_receipt_hash` (a SHA-256 of the previous receipt's full signed content) alongside the `prev_receipt_id` reference. If every signature and hash link verifies, no receipt has been altered or reordered since it was written; if a link fails to verify, the break is provable. Optional attestation fields — KYC results, risk scores, approval IDs, document hashes — are signed into the receipt at the step they apply to. One honest limit, stated plainly because an auditor will ask it: the party running the gate holds the signing key, so the signatures and the hash chain alone cannot catch that same party rewriting an entire chain end to end. AgenticRail closes this by also writing a **write-once copy of each sealed record to a separately held archive**, and the verification report compares the live chain against it. A downstream rewrite shows up as a mismatch against a copy the operator cannot reach. The chain proves nothing was altered in place; the independent archive is what catches a wholesale rewrite. For an ISO/IEC 42001 certification audit, the receipt chain provides documented evidence against three control areas: - →**A.6.1.6 evidence:** Per-step enforcement log with timestamps. Full receipt chain enabling reconstruction of every sequence. Hash-link proof — tamper-evident from step 0 to seal, plus the independent-archive comparison. - →**Clause 9.1 evidence:** Per-action decision records. ALLOW/DENY statistics at sequence and step level. Denial reason codes enabling root-cause analysis of blocked steps. - →**A.7 evidence:** Denial records showing the gate blocked non-compliant steps before execution. Bound human-authorisation attestations where your process requires them. Sequence seal records — showing a completed sequence cannot silently accept new steps. You can verify any sequence yourself at the verification tool — paste a sequence ID and it returns the per-step enforcement log, the signature and hash-link checks, the independent-archive comparison, and a plain-language narrative: [report.agenticrail.nz/report](https://report.agenticrail.nz/report) The report is suitable for inclusion in ISO/IEC 42001 management system documentation, certification audit evidence packages, and management review records — as the record of what the enforcement layer did, alongside the organisational controls that remain yours. ## Cross-framework: one chain, three standards ISO/IEC 42001, the EU AI Act, and NIST AI RMF all converge on the same operational evidence requirement: proof that oversight mechanisms functioned during deployment. The clause numbering differs; the underlying gap is the same. - →**ISO/IEC 42001 Annex A.6.1.6** — operational logging enabling reconstruction of AI system behaviour. The receipt chain provides the reconstruction record. - →**EU AI Act Article 12** — record-keeping sufficient for post-market monitoring and traceability. The same receipt chain produces the logging evidence the article calls for. - →**NIST AI RMF Measure 2.4** — risk-appropriate performance monitoring with results used to inform risk treatment. The per-action receipt record is the monitoring evidence. You build the enforcement layer once, and the evidence it produces maps across all three frameworks — because all three are asking the same question: *can you show your controls actually ran?* The evidence maps. The obligations stay yours. See it working One enforcement layer. Evidence for ISO 42001, EU AI Act, and NIST AI RMF — the obligations stay yours. Run a demo sequence and generate a verification report in about a minute — no signup required. The report shows the receipt chain, the hash-link and signature proofs, the independent-archive comparison, and a per-step enforcement log suitable for ISO 42001 audit evidence. [Try the demo →](https://agenticrail.nz/demo/) [See a verification report →](https://report.agenticrail.nz/report) Related [EU AI Act vs NIST vs ISO 42001: Side-by-Side Comparison →](https://agenticrail.nz/resources/ai-governance-frameworks-2026/) [AgenticRail and the NIST AI RMF →](https://agenticrail.nz/spec/nist-ai-rmf/) [The evidence-completeness spec →](https://agenticrail.nz/spec/completeness/) [Back to AgenticRail](https://agenticrail.nz/) · [API documentation](https://agenticrail.nz/docs/) · [Live demo](https://agenticrail.nz/demo/) --- # AI Governance Frameworks 2026: EU AI Act, NIST AI RMF, ISO 42001 Compared > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/resources/ai-governance-frameworks-2026/ > Site context: https://agenticrail.nz/llms.txt Updated 12 May 2026 · Re-checked and republished 18 July 2026 · AgenticRail # EU AI Act, NIST AI RMF, ISO 42001: Three Frameworks, One Evidence Question Three frameworks dominate AI governance in 2026: the **EU AI Act** (binding regulation, high-risk obligations from December 2027), **NIST AI RMF 1.0** (voluntary US framework, widely adopted as enterprise baseline), and **ISO/IEC 42001:2023** (international management system standard with certification path). Each specifies different obligations. All three converge on a requirement that agentic AI systems cannot meet with logging alone: **evidence that oversight mechanisms were operational during deployment.** A framework is an *asserted* safeguard — it says what must happen. What every framework leaves to the operator is proof that it did. This page compares the three factually, then maps what a pre-execution receipt chain can — and deliberately cannot — evidence for each. (The general version of that distinction — asserted, enforced, provable — is [here](https://agenticrail.nz/spec/enforceable-safeguards/).) May 2026 — What's changed →**EU AI Act — high-risk enforcement December 2027.** High-risk AI obligations apply from **2 December 2027**, extended from 2 August 2026 by the Digital Omnibus on AI (May 2026). Agentic systems in Annex III sectors must satisfy Articles 9, 11, 12, and 14 or face penalties up to €35M. →**NIST — Critical Infrastructure Profile concept note (April 2026).** NIST published a concept note for *AI RMF Profile on Trustworthy AI in Critical Infrastructure*, extending the core framework to energy, finance, healthcare, and transport operators. It follows the Generative AI Profile (NIST AI 600-1, July 2024). The direction is sector-specific, risk-tiered guidance — consistent with the EU AI Act's regulatory approach. The profile is in concept phase; a draft for public comment is expected later in 2026. →**ISO/IEC 42001 — Adoption accelerating.** Certification bodies across the EU and UK report material upticks in ISO/IEC 42001 enquiries since Q1 2026, driven by organisations treating certification as evidence of conformity readiness ahead of the August EU AI Act deadline. ISO 42001 is not legally required, but certified organisations carry a stronger audit position. Key takeaways - **EU AI Act** is binding law — penalties up to €35M. High-risk AI deadline: **2 December 2027** (extended from 2 August 2026). - **NIST AI RMF** is voluntary. No penalties, no deadline. Widely adopted as US enterprise baseline. - **ISO/IEC 42001** is voluntary with optional certification. Aligns with ISO 9001/27001 management system structures. - All three require operational evidence of oversight — not just logs, but **proof the controls ran before actions executed.** This is why the deterministic vs probabilistic distinction matters at the regulatory level. - One receipt chain produces evidence toward all three simultaneously. **The evidence maps across frameworks; the obligations stay yours.** Jump to - [The three frameworks at a glance](#frameworks) - [Side-by-side comparison table](#comparison) - [How sequence enforcement maps to each framework](#mapping) - [Which framework applies to your system](#which-applies) - [Frequently asked questions](#faq) ## The three frameworks at a glance Binding regulation EU AI Act Regulation 2024/1689 · European Union Risk-based regulation classifying AI systems from unacceptable risk (banned) to minimal risk. High-risk AI — including agentic systems in hiring, lending, healthcare, law enforcement, and critical infrastructure — faces mandatory conformity assessment, technical documentation, CE marking, EU database registration, human oversight, and logging. **High-risk obligations apply from 2 December 2027** (extended from 2 August 2026, Digital Omnibus May 2026). [Full text →](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689) Voluntary framework NIST AI RMF 1.0 AI Risk Management Framework · NIST, USA Voluntary framework organising AI risk management across four functions: **Govern** (policies, culture), **Map** (context, risk identification), **Measure** (analysis, assessment), **Manage** (prioritisation, treatment). Adopted as baseline by US federal agencies and widely used in enterprise risk programmes globally. No certification mechanism; no legal deadline. [NIST AI →](https://www.nist.gov/artificial-intelligence) Certifiable standard ISO/IEC 42001:2023 AI Management Systems · ISO/IEC JTC 1/SC 42 International standard for AI management systems, structured like ISO 9001 (quality) and ISO 27001 (information security). Specifies requirements for establishing, implementing, maintaining, and continually improving an AI management system. Certification available via accredited bodies. Annex A includes 38 controls covering AI system design, data, operations, and incident management. [ISO standard →](https://www.iso.org/standard/81230.html) ## Side-by-side comparison | Property | EU AI Act | NIST AI RMF 1.0 | ISO/IEC 42001 | | Legal force | Binding regulation (EU) | Voluntary guidance | Voluntary; certification available | | Deadline | Dec 2027 (high-risk AI) | None | None (certification-led) | | Scope | All AI placed on EU market; risk-tiered | Any organisation using or developing AI | Any organisation developing or using AI | | Penalties | Up to €35M or 7% global turnover | None | None (loss of certification) | | Human oversight required | Yes — Article 14 (mandatory) | Yes — Manage 2.4 (recommended) | Yes — Clause 6.1 (required for certification) | | Logging / traceability | Yes — Article 12 (mandatory) | Yes — Measure 2.4 (recommended) | Yes — Annex A.6.1.6 (control) | | Technical documentation | Yes — Article 11 + Annex IV (mandatory) | Recommended (Map 5) | Yes — Clause 8.4 (required for certification) | | Incident reporting | Yes — Article 73 (serious incidents) | Recommended (Manage 4) | Yes — Clause 10.1 | | Conformity assessment | Yes — third-party for most Annex III | No | Yes — independent certification | | Agentic AI specific guidance | Implicit via risk classification | AI RMF Playbook (emerging) | Not explicitly addressed | ## How sequence enforcement maps to each framework Sequence enforcement — evaluating each agent action against a defined policy before execution, issuing a cryptographic receipt on every authorised pass — is not specific to any one framework. It produces the class of evidence all three converge on: oversight points that are operational during deployment, logging that is tamper-evident, and proof that prerequisites were met before actions executed. EU AI Act Regulation 2024/1689 — Articles 9, 11, 12, 14 Framework requirement **Article 14:** Human oversight measures — natural persons must be able to intervene or halt the system. Oversight must be effective (built into operation, not available as policy option). What the receipt chain evidences An enforcement gate does not satisfy Article 14 on its own — human oversight is an organisational measure, not a software feature. What the gate adds is the evidence layer oversight needs: every step requires authorisation before executing, an explicit HALT stops execution without relying on the model to comply, and each intervention point leaves a signed receipt. Whether oversight was exercised well is a question about people; whether it structurally could and did occur becomes provable. Framework requirement **Article 12:** Automatic log generation enabling post-market monitoring. Logs must be sufficient to determine the period of use, reference database used, and persons involved in verification. What the receipt chain evidences Every gate decision produces an Ed25519-signed receipt in tamper-evident, append-only storage, recording: step, sequence ID, decision, timestamp, payload hash, action type, and chain linkage (`prev_receipt_hash`). Sealed sequences are additionally copied to an independently held archive. Tampering breaks the chain detectably. Pre-action record — not post-action log. Framework requirement **Article 11:** Technical documentation demonstrating system operates as intended, including design logic, testing results, and risk management measures. What the receipt chain evidences The report endpoint generates a verifiable record for any sequence ID: the receipt chain with raw Ed25519 signatures and their exact signed bytes (so verification runs offline, in your own code), per-link hash-chain checks, and an independent-archive comparison for sealed sequences. It does not write your Article 11 documentation — it supplies the operational-evidence exhibits that documentation cites. NIST AI RMF AI Risk Management Framework 1.0 — Govern, Map, Measure, Manage Framework requirement **Manage 2.4:** Mechanisms are in place, and responsibilities assigned, to supersede, disengage, or deactivate AI systems that behave inconsistently with intended use. What the receipt chain evidences Gate access is controlled via API keys. Designated personnel can revoke keys, modify policy maps, or terminate sequences. The enforcement layer is separate from the model — human authority operates at the infrastructure level. Framework requirement **Measure 2.4:** The functionality and behaviour of the deployed AI system are monitored when in production. What the receipt chain evidences Gate statistics (total evaluations, ALLOW/DENY rates, HALT events, sequence completions) are recorded in KV and exposed via the dashboard. The receipt chain enables retrospective analysis of exactly which steps were blocked and why. See the [May 2026 updates section](#may-2026) at the top for the NIST Critical Infrastructure Profile concept note and EU AI Act enforcement timeline. ISO/IEC 42001 AI Management Systems Standard — Clauses 6, 8, 9 and Annex A Framework requirement **Clause 9.1:** Monitoring, measurement, analysis, and evaluation — the organisation shall determine what needs to be monitored and measured and the methods for valid results. What the receipt chain evidences Gate decisions are the measurement points. Every ALLOW and DENY is recorded with full metadata. The receipt chain constitutes the continuous operational record that Clause 9.1 requires — produced automatically, not as a separate measurement exercise. Framework requirement **Annex A, A.6.1.6:** AI system operational logging — the organisation shall implement logging of AI system operations to an extent sufficient to enable the reconstruction of AI system behaviour. What the receipt chain evidences The receipt chain enables complete reconstruction of agent sequence behaviour: which steps ran, in what order, what the gate decided, at what time. The Ed25519 signatures make the reconstruction tamper-evident — any alteration is detectable. ## Which framework applies to your agentic AI system? Most organisations building agentic AI in 2026 will need to address at least two of these frameworks simultaneously: - →**EU market + high-risk sector:** EU AI Act is mandatory. ISO/IEC 42001 certification provides a structured conformity path. NIST AI RMF aligns US operations. - →**US federal or regulated enterprise:** NIST AI RMF is baseline. ISO/IEC 42001 provides certification. EU AI Act applies if EU market activity exists. - →**Global enterprise, any sector:** ISO/IEC 42001 provides the management system foundation. EU AI Act applies to EU-facing deployments. NIST AI RMF fills voluntary gaps. - →**Agentic AI in any regulated context:** All three frameworks require operational evidence that oversight mechanisms functioned during deployment. Sequence enforcement produces this evidence — one receipt chain, citable under all three. - →**Outside these jurisdictions (including Aotearoa NZ):** none of the three binds directly — but local regulators ask the same underlying question: can you evidence that the safeguard ran? See the [NZ health](https://agenticrail.nz/spec/nz-health/) and [NZ education](https://agenticrail.nz/spec/nzqa-nz-education/) briefs for that question on home ground. The evidence layer is the same regardless of which framework you are working under. The receipt chain offered as Article 12 evidence is the same chain offered under ISO/IEC 42001 Annex A.6.1.6 and NIST AI RMF Measure 2.4 — build the evidence once, cite it three ways. The frameworks’ other obligations — risk management, documentation, and the oversight measures themselves — remain separate work that no receipt does for you. ## Frequently asked questions What is the difference between EU AI Act and NIST AI RMF? The **EU AI Act** is binding EU law — mandatory for any AI placed on the EU market, with penalties up to €35M or 7% of global turnover and a compliance deadline of 2 December 2027 for high-risk AI (extended from 2 August 2026). **NIST AI RMF 1.0** is a voluntary US framework with no penalties or legal deadlines. It organises risk management across four functions (Govern, Map, Measure, Manage) and is widely adopted as an enterprise baseline, particularly in US federal contexts. Is ISO 42001 required for EU AI Act compliance? No — ISO/IEC 42001 certification is not legally required for EU AI Act compliance. However, it provides a structured management system that can support the technical documentation and risk management evidence required under Articles 9 and 11. Many operators pursuing EU AI Act conformity assessment use ISO/IEC 42001 as a governance foundation alongside their notified body review. What does EU AI Act Article 12 require for logging? Article 12 requires that high-risk AI systems automatically generate logs enabling post-market monitoring. The logs must be sufficient to identify: the period of each use, the reference database against which output was verified, and **the persons involved in the verification.** In practice, logs an AI system writes about itself are weak evidence for exactly this purpose — an independent, tamper-evident record is what post-market monitoring can actually rely on. When does the EU AI Act apply to agentic AI? High-risk obligations apply from **2 December 2027** (extended from 2 August 2026, Digital Omnibus May 2026). Agentic AI systems operating in Annex III sectors — hiring, lending, healthcare triage, law enforcement, critical infrastructure — are classified as high-risk. These systems must satisfy Articles 9, 11, 12, and 14 by the deadline, including CE marking and EU database registration where required. Can one approach satisfy EU AI Act, NIST, and ISO 42001 simultaneously? One evidence layer can serve all three at once. All three frameworks ask for the same underlying capability: operational proof that oversight mechanisms functioned during deployment. Infrastructure-level sequence enforcement — gate-evaluating each agent action before execution and issuing a cryptographic receipt — produces a chain citable under EU AI Act Article 12, ISO/IEC 42001 Annex A.6.1.6, and NIST AI RMF Measure 2.4 simultaneously. What no single mechanism can do is satisfy any of these frameworks outright: risk management, technical documentation, and the oversight measures themselves remain organisational obligations. Evidence once; the obligations stay yours. See it working One receipt chain. Three frameworks’ evidence. The receipt chain cited under EU AI Act Article 12 is the same chain cited under ISO/IEC 42001 Annex A.6.1.6 and NIST Measure 2.4. Run a demo sequence and generate the report yourself in 60 seconds — no signup required. [Try the demo →](https://agenticrail.nz/demo/) [API documentation →](https://agenticrail.nz/docs/) Continue reading [Automated Decisions and the Provable Safeguard: Asserted, Enforced, Provable →](https://agenticrail.nz/spec/enforceable-safeguards/) [The Completeness Specification: Eight Requirements for Evidence-Grade Records →](https://agenticrail.nz/spec/completeness/) [Deterministic vs Probabilistic AI Agents →](https://agenticrail.nz/blog/deterministic-vs-probabilistic-ai-agents/) [Back to AgenticRail](https://agenticrail.nz/) · [API documentation](https://agenticrail.nz/docs/) · [Live demo](https://agenticrail.nz/demo/) --- # How Do You Prove a Human Checked an AI-Assisted Clinical Decision? — AgenticRail > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/ai-in-health-accountability/ > Site context: https://agenticrail.nz/llms.txt **Document type** Plain-language note for clinical and governance readers **Subject** A verifiable record for AI-assisted clinical decisions **Published by** TUARA KURI LIMITED — trading as AgenticRail, Hokianga, Aotearoa New Zealand **Date** 2026-06-26 (updated 2026-07-15) **Version** 1.3 **Status** Offered for consideration — open to feedback and correction **Related** NZ health gap analysis (/spec/nz-health/) · completeness specification (/spec/completeness/) # How Do You Prove a Human Checked an AI-Assisted Clinical Decision? When an AI helps make a clinical decision, what record proves what the AI did, whether a person checked it, and that no one altered the record afterward? This note describes that gap in plain terms, the instrument that closes it, and — just as carefully — what that instrument does *not* claim to do. It is written for clinicians, ethicists, lawyers, data scientists, and kaitiaki, not for engineers. It names no requirement that your own governance principles have not already named first. ## 1. The gap AI is already in New Zealand clinical care — drafting consultation notes for emergency and general-practice clinicians, summarising, suggesting. In almost every safe deployment, the stated safeguard is the same and it is a good one: **a clinician reviews and confirms.** The human holds the pen. But there is a quiet assumption underneath that safeguard. An AI can produce an answer that is confident, fluent, and plausible — and not grounded in the patient in front of it. (The technical word is *confabulation*: a well-formed output that isn't anchored to fact.) Under time pressure, in a busy clinic, the review that is supposed to catch this can become a glance. None of that is unusual or blameworthy; it is how pressure works on people. The gap, stated plainly The danger is not that the AI was wrong. The danger is that, right now, in most deployments, **there is no record of what the AI produced, whether the review actually happened, or proof that none of it was changed afterward.** The decision is documented; the AI's part in it, and the integrity of that account, usually is not. The blindness is the problem — not any single error. ## 2. What exists today, and what is missing Most systems already *log*. The finished note is saved; timestamps exist; the record can be produced on request. That is genuine and useful. But a log written by the same system whose conduct is in question answers a narrower thing than people assume. "We logged it" is not the same as "we can prove it." A log that can still be added to, edited, or tidied — after an incident, during a complaint, in the calm of hindsight — cannot establish that what it shows is the **complete account as it stood at the moment of care.** That is the missing property. It is not more logging. It is a different kind of record. ## 3. The instrument The instrument is a small, deliberate addition to whatever AI is already running. It does not change the AI, the clinician's judgment, or the workflow. It produces, alongside the decision, a record with three properties. We call each entry a **receipt** — in the everyday sense: proof that a thing happened, the way a receipt proves a transaction. - **The record** — what the AI did, and in what order. The AI produced a draft; a person reviewed it; a decision was confirmed. Each step is its own receipt. - **Tamper-evident** — once the sequence is finished it is *sealed*: any later addition, alteration, or reopening leaves a detectable break in the record. The account is fixed at the moment of care. - **Independently verifiable** — anyone can check the record is genuine and unaltered on their own, offline, without having to trust — or even contact — the people who produced it. The third property is the one that matters most for accountability. A record the operator can verify only by asking the operator is a promise. A record a patient's advocate, an auditor, or the Health and Disability Commissioner can verify themselves is evidence. ## 4. A worked example — the AI scribe Consider an AI scribe drafting a consultation note. Today: the scribe drafts, the clinician edits and signs, the note is saved. If a question arises months later — was the AI's draft actually reviewed, or waved through? — the honest answer is usually that the record cannot say, and could in principle have been edited since. With a sealed record, the same consultation also produces a short, fixed account. In plain language, it reads like this: What the sealed record says — in plain terms Step 1 — An AI scribe produced a draft note. Step 2 — The draft was presented to the clinician for review. Step 3 — The clinician confirmed the note and signed it. Sealed — The sequence was closed. Any later attempt to add or change a step is detectable. Anyone can check — that these steps occurred, in this order, and that the record has not been altered since. The record need not contain the clinical content itself to do its work — it can reference the note without copying it, so the sensitive material stays where it belongs (see §7). What the record establishes is the **shape and integrity of the decision**: that the AI's part happened, that a review step happened, and that the account is the original, not a later tidy-up. ## 5. What this proves — and what it does not This is the most important section, and the one we ask you to hold us to. An instrument that overstates itself is worse than none, because it invites a trust it has not earned. | It proves | It does not — and does not claim to | | That the AI produced output, and what step it occupied in the decision. | That the AI's output was clinically **correct**. The record is silent on clinical truth. | | That a review step occurred, and in what order. | That the review was **thorough**. It records that the step happened, not the quality of the clinician's attention. | | That the account is complete and unaltered since the moment of care. | That any **harm was prevented**. This is an evidence instrument, not a safety control on the AI itself. | | That an independent party can confirm all of the above without trusting the operator. | That the AI is **unbiased or equitable**. Those are properties of the model and its data, addressed elsewhere — not by this record. | In short: the instrument makes the decision **accountable and reviewable after the fact**. It does not make it correct, safe, or fair — those remain the work of clinicians, model developers, and your own governance. We think being exact about this boundary is what makes the instrument trustworthy. ## 6. How this relates to the governance framework's eight domains The Waitematā AI Governance Group's published framework evaluates any proposed AI across eight domains. This instrument speaks directly to two of them and supports one more. On a fourth — Māori perspectives — it is careful to disclaim more than it offers. It is honestly silent on the remaining four, which concern the AI itself, not the record of its use. | Governance domain | How the record relates | | **Ethical principles, including transparency** | **Directly.** The AI's role in a decision becomes legible and checkable after the fact, by people outside the system that produced it. | | **Legal and contractual requirements** | **Directly.** The framework describes this domain as "the need for clear accountability and responsibilities," the service's role as "guardians (kaitiakitanga)" of health information, and "responsibility for ongoing monitoring and audit, accountability if an AI tool should fail." A sealed, independently verifiable record is precisely that artefact: it fixes who did what and when, it is the monitoring-and-audit trail itself, and it survives a vendor being sold — because it can hold none of the clinical data itself, referencing rather than copying it, and verifies against published keys. | | **Māori perspectives** | **Does not provide sovereignty — and does not claim to.** This instrument does not offer data or language sovereignty; that is not what it is. The one honest, narrow thing it does for this domain: the record proves what happened by *referencing* clinical material rather than copying it, so using the record does not itself move data out of the system that already holds it (see §7). Control over where health data lives, and who may access it, stays exactly where it already sits. | | **Technical guidance** | **Supports.** The record is a cryptographic, security-grade artefact — signed and verifiable offline — aligned with the cyber-security considerations this domain raises. | | *Consumer perspectives · Equity and fairness · Clinical perspectives · Data issues* | *Not addressed by this instrument.* These concern the AI and its deployment, not the record of its use. We don't claim otherwise. | ## 7. What the record holds — and what it does not A record of accountability must not become a new place where sensitive information is copied or stored. So the instrument is built to hold as little as possible. A receipt can establish that a decision occurred, and prove its integrity, by referencing the clinical material — for example, by a one-way fingerprint of it — **without containing the material itself.** The patient's information stays in the system that already holds it, under the authority that already governs it. The record proves the event; it does not relocate the data. To be plain about the boundary: **this is not a data-sovereignty tool, and it does not claim to be.** It does not decide where health data lives, or who may access it — those remain the responsibility of the systems and authorities that already hold them. Data sovereignty is a real and unresolved question; this instrument does not answer it and does not pretend to. What it offers is narrower and honest: a record of what happened that does not itself move the data anywhere. ## 8. Who built this, and why This was built in Hokianga, by a New Zealand company, by someone who carries a kaitiaki responsibility for what gets recorded and how. The honest origin is personal: watching a clinician reach for an AI during a child's check-up, and realising that whatever the AI contributed, nothing in the room would ever record that it had. Not a scandal — a blind spot. The instrument is an attempt to fit the missing earth pin, quietly, to a system that is otherwise working. We are not claiming to have found a problem the field has missed; clinicians, the HDC, and your own group have all named the accountability question already. We are offering one concrete, verifiable way to answer part of it — and we would rather be corrected early than be polite and wrong. If something here is overstated or mistaken, we want to hear it. ## 9. See it for yourself The instrument is real and running, not a slide. The records it produces are signed and can be checked by anyone, with no login, against published keys: **Live verification** — check a real sealed record yourself · [report.agenticrail.nz/report](https://report.agenticrail.nz/report) **The completeness specification** — the neutral, vendor-independent measure behind the seal · [agenticrail.nz/spec/completeness/](https://agenticrail.nz/spec/completeness/) **NZ health gap analysis** — the deployment context, cited to NZ sources · [agenticrail.nz/spec/nz-health/](https://agenticrail.nz/spec/nz-health/) **Public verification keys** — verify records offline · [agenticrail.nz/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json) This note is offered, not pitched. If it is useful to your work, or if you can see where it falls short, the door is open: [hello@agenticrail.nz](mailto:hello@agenticrail.nz). Document Fingerprint — SHA-256 — v1.3 7939f3bedde8134bf561e86adaaffdce6bf7719228a4693f11cfa8e47ab5b781 This hash is SHA-256 of the canonical string below. It is reproducible independently of this page using any SHA-256 implementation, and lets any reader confirm this document has not been altered since publication. **Canonical string (pipe-delimited, UTF-8, no trailing newline):** `A Verifiable Record for AI-Assisted Clinical Decisions|1.3|2026-07-15|TUARA KURI LIMITED|gap:no-record-of-ai-part-or-integrity|instrument:record+tamper-evident+independently-verifiable|receipt|seal|scribe-worked-example|proves:accountable-reviewable|does-not:correct-safe-fair-unbiased|does-not:data-sovereignty|aigg-domain:direct-ethical-transparency|aigg-domain:direct-legal-contractual-accountability-audit|aigg-domain:maori-sovereignty-disclaimed|aigg-domain:supports-technical-security|record-references-not-copies-data|report.agenticrail.nz` Published: 2026-06-26 | Updated: 2026-07-15 (v1.3 — removed data-sovereignty claims; §6 and §7 now explicitly disclaim that the instrument provides data or language sovereignty. v1.2 fingerprint 0bc97c43… superseded.) | Offered for consideration and correction --- # How Do You Integrate AgenticRail's Sequence Enforcement API? — AgenticRail > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/docs/ > Site context: https://agenticrail.nz/llms.txt Developer Documentation # Zero to first gate call *in under 10 minutes.* One endpoint. One header. POST before each step — the gate returns **ALLOW** or **DENY**. Your agent only proceeds on ALLOW. Every ALLOW writes a cryptographic receipt — a signed, chained record of what ran, when, in what order, written before the action executed. The same gate answers the engineering question and the compliance question. Wrapper live — https://api.agenticrail.nz/v1/evaluate How it works ## Three steps. No magic. Every gate call follows the same path. Your agent sends a request. The gate enforces sequence. You get a receipt or a halt. 01 Send request POST to `/v1/evaluate` with your agent's current step, a unique nonce, and a timestamp. Auth via the `Authorization: Bearer` header. 02 Gate enforces sequence The gate validates step order, checks the nonce for replay, verifies `function` and `action_type` against the policy for this step, and confirms the sequence is not sealed. All checks must pass. 03 Receive receipt or halt On pass: a cryptographic receipt with decision `ALLOW` — Ed25519-signed, chained, stored immutably in R2. That receipt is your compliance record: structural proof of what ran, when, in what order. On failure: a `DENY` with a reason code. Your agent only proceeds on ALLOW. Authentication ## One header. Every request. All requests to the wrapper require the `Authorization: Bearer` header. The demo key is public and rate-limited — use it to test without signing up. Demo key — public, free to use DEMO-AGENTICRAIL-PUBLIC-2026 Add to every request: `Authorization: Bearer DEMO-AGENTICRAIL-PUBLIC-2026` The wrapper expects the `Authorization` header; the gate uses `x-slp8-key`. For production use, contact [hello@agenticrail.nz](mailto:hello@agenticrail.nz) for a private key with no rate limits. Service Architecture ## Wrapper, Gate, and Report AgenticRail deploys three public services: 01 Wrapper (front door) **Endpoint:** `https://api.agenticrail.nz/v1/evaluate` **Auth:** `Authorization: Bearer ` Adds API key management, rate limiting, D1 logging, and demo key bypass. All client requests should use this endpoint. 02 Gate (enforcement) Pure sequence enforcement layer — validates step order, nonce, function/action_type policy, and sequence seal. Called internally by the wrapper via service binding. Not publicly accessible — all client traffic enters through the wrapper. 03 Report (compliance) **Endpoint:** `https://report.agenticrail.nz/report` **Auth:** `x-slp8-key: ` Generates HTML/JSON compliance reports for any sequence. Read-only; no state mutation. Demo key `DEMO-AGENTICRAIL-PUBLIC-2026` works with all three services. Wrapper prefixes demo sequence IDs with `demo-` and isolates receipts. Request format ## Fields, one by one. All requests are `Content-Type: application/json` via POST. Fields are validated in order — a missing required field halts at gate step 1. | Field | Type | Description | | schema_version | string | Always `"1.0"` | | sequence_id | string | Unique per sequence — e.g. a UUID or session ID. Groups steps together. | | step | string | Your step name — must match `function`. Must be a valid step in your configured sequence, called in the defined order. e.g. `"verify_identity"`, `"assess_risk"`, `"execute_transfer"`. | | function | string | Canonical function name — must equal `step`. e.g. `"verify_identity"`, `"assess_risk"`. Used for policy lookup. | | action_type | string | Canonical action type for this step. Must be in the allowed set for the function. e.g. `"CHECK_STATE"`, `"RECORD_RESULT"`, `"WAIT_FOR_SIGNAL"`. | | model_id | string | Your agent identifier — e.g. `"my-agent-v2"`. When using the demo key, the wrapper transforms this to `"client:demo"` before passing to the gate. | | nonce | string | Unique string per request (any format). Used for replay protection — never reuse. | | action | string | Descriptive action label for this step. e.g. `"verify identity"`, `"assess risk"`. | | ts_ms | number | Unix timestamp in milliseconds. Required — use `Date.now()` or equivalent. Must be within ±300 seconds of current time when received by the gate. | | inputs | object | Optional. Any context you want to log alongside the step. | | attestation | object | Optional. Evidence object signed into the receipt at this step — e.g. `{"aml_check": "passed", "approved_by": "risk-committee-id"}`. The full object is stored immutably in R2 alongside the receipt. Use it to embed proof of deliverables, external check results, or human approvals directly in the audit trail. Can contain hashes, IDs, and long strings — excluded from poison hardening. | | step_order | string[] | Required on every call. Array of all step names in execution order — e.g. `["verify_identity", "assess_risk", "execute_transfer"]`. The gate reads it from each payload to resolve the step's position. The gate does not store it between calls. | **Timestamp freshness:** The gate enforces a ±300 second window around the current time. If your request arrives more than 5 minutes early or late, it will be rejected with reason `STALE_TIMESTAMP`. Always generate `ts_ms` fresh using `Date.now()` or equivalent. Quickstart ## Copy. Paste. Run. This example works against the live wrapper right now. Each snippet generates a fresh timestamp, a unique nonce, and a unique sequence ID on every run, so it returns **ALLOW** the moment you paste it. curl — bash / mac / linux ``` # Paste the whole block. Fresh timestamp, unique nonce + sequence id - runs every time. TS=$(( $(date +%s) * 1000 )) NONCE=$(openssl rand -hex 8) SEQ="my-seq-$(date +%s)" curl -X POST https://api.agenticrail.nz/v1/evaluate \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer DEMO-AGENTICRAIL-PUBLIC-2026' \ -d "{ \"schema_version\": \"1.0\", \"model_id\": \"my-agent\", \"sequence_id\": \"$SEQ\", \"step\": \"verify_identity\", \"function\": \"verify_identity\", \"action_type\": \"CHECK_STATE\", \"action\": \"verify identity\", \"nonce\": \"$NONCE\", \"ts_ms\": $TS, \"inputs\": {}, \"step_order\": [\"verify_identity\", \"assess_risk\", \"execute_transfer\", \"audit_ledger\"] }" ``` powershell — windows ``` # Paste the whole block into PowerShell $ts = [DateTimeOffset]::UtcNow.ToUnixTimeMilliseconds() $nonce = -join ((1..16) | ForEach-Object { '0123456789abcdef'[(Get-Random -Maximum 16)] }) $seq = "my-seq-$ts" $body = '{"schema_version":"1.0","model_id":"my-agent","sequence_id":"' + $seq + '","step":"verify_identity","function":"verify_identity","action_type":"CHECK_STATE","action":"verify identity","nonce":"' + $nonce + '","ts_ms":' + $ts + ',"inputs":{},"step_order":["verify_identity","assess_risk","execute_transfer","audit_ledger"]}' $headers = @{ "Content-Type" = "application/json"; "Authorization" = "Bearer DEMO-AGENTICRAIL-PUBLIC-2026" } (Invoke-WebRequest -UseBasicParsing -Uri https://api.agenticrail.nz/v1/evaluate -Method POST -Headers $headers -Body $body).Content ``` `ts_ms` is a required field — the current Unix time in milliseconds, within 300 seconds of server time. The snippets generate it for you. Note: `date +%s%3N` is GNU-only; the cross-platform form `$(( $(date +%s) * 1000 ))` works on macOS and Linux. javascript ``` // One gate call — adapt into your agent loop const res = await fetch('https://api.agenticrail.nz/v1/evaluate', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': 'Bearer DEMO-AGENTICRAIL-PUBLIC-2026', }, body: JSON.stringify({ schema_version: '1.0', model_id: 'my-agent', sequence_id: 'my-seq-' + Date.now(), step: 'verify_identity', function: 'verify_identity', action_type: 'CHECK_STATE', action: 'verify identity', nonce: crypto.randomUUID().replace(/-/g, '').slice(0, 16), ts_ms: Date.now(), inputs: {}, step_order: ['verify_identity', 'assess_risk', 'execute_transfer', 'audit_ledger'], }), }); const gate = await res.json(); if (gate.decision === 'ALLOW') { // Proceed with your step } else { // Halt — do not proceed console.error('DENY:', gate.reasons); } ``` Response reference ## ALLOW or DENY. Nothing in between. The wrapper returns a flattened response with all decision details at the top level. There is no `pack` wrapper — the `decision`, `reasons`, and `executed` fields are directly in the response object. The nested `receipt` object carries the receipt metadata for that decision — `key_id`, `signature_alg`, `payload_hash`, and `version`. ✓ ALLOW — step accepted ``` { "decision": "ALLOW", "executed": true, "pack_id": "80fe6e6887ca024d2325260f83224c86c3d2157b10ef60cc73ee8fded4661552", "reasons": [], "sequence_id": "demo-test-seq-001", "step": "verify_identity", "function": "verify_identity", "action_type": "CHECK_STATE", "model_id": "client:demo", "result": { "status": "submitted", "data": { "state": null } }, "receipt": { "pack_id": "80fe6e6887ca024d2325260f83224c86c3d2157b10ef60cc73ee8fded4661552", "key_id": "k2_2026-06-07_ed25519", "signature": null, "signature_alg": "Ed25519", "payload_hash": "201031e1bce583b179f7b9b8b9c794de2cd8514da84adae974232ed3f2ff0774", "prev_receipt_id": null, "ts_ms": 1780732058107, "version": "slp8_receipt_v2", "attestation": null }, "log": { "ok": true, "error": null } } ``` ✗ DENY — sequence violation ``` { "decision": "DENY", "executed": false, "pack_id": "1493ba42f5e0ffb81227e700eda1e03e762058fd9da4080f320c432b6fa23c2f", "reasons": ["SEQUENCE_VIOLATION"], "sequence_id": "demo-replay-test-seq", "step": "execute_transfer", "function": "execute_transfer", "action_type": "CHECK_STATE", "model_id": "client:demo", "result": { "status": "skipped", "message": "No execution triggered" }, "receipt": { "pack_id": "1493ba42f5e0ffb81227e700eda1e03e762058fd9da4080f320c432b6fa23c2f", "key_id": "k2_2026-06-07_ed25519", "signature": null, "signature_alg": "Ed25519", "payload_hash": "9f2c1a77b4e83d0516a8c4f9e2b7d3061c5a8e94f0b2d6713a9e4c8051f7b2d4", "prev_receipt_id": "80fe6e6887ca024d2325260f83224c86c3d2157b10ef60cc73ee8fded4661552", "ts_ms": 1780732061488, "version": "slp8_receipt_v2", "attestation": null }, "log": { "ok": true, "error": null } } ``` **About the signature.** The inline `receipt` carries the decision metadata and the `payload_hash`. The signature itself is finalized in the durable, immutable receipt written to storage — it is not echoed in the synchronous response, so the calling system cannot verify it at the moment of decision, only afterward. That's deliberate: the synchronous path stays lean, and every verification is forced through the one durable, tamper-evident record rather than trusting an ephemeral API response. To verify it, call [report.agenticrail.nz](https://report.agenticrail.nz) — the compliance report includes each receipt's raw `signature` (base64) and its exact `signed_canonical` preimage, so you can run `ed25519_verify(public_key, signed_canonical, signature)` yourself, entirely offline, against the published key at [/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json) — no callback to AgenticRail, no trust in our own verification claim required. Reason code Meaning SEQUENCE_VIOLATION Step arrived out of order — e.g. `execute_transfer` before `verify_identity` has completed. REPLAY_NONCE Nonce has already been used. Generate a fresh nonce per request. STALE_TIMESTAMP Timestamp (ts_ms) is outside the allowed ±300 second window from current time. Always generate ts_ms fresh using Date.now() or equivalent. SEALED_SEQUENCE This sequence has already been completed. Start a new `sequence_id`. ACTION_NOT_ALLOWED `action_type` is not in the allowed set for this function/step. UNKNOWN_STEP `step`/`function` is not present in this sequence's own declared `step_order`. An unrecognised name alone does not deny — it falls through to a permissive generic policy so custom `step_order` sequences work. Only a name absent from your declared `step_order` is rejected. *(Corrected 2026-07-05 — supersedes the previously-documented but unreachable `NO_POLICY_MATCH`.)* FUNCTION_STEP_MISMATCH `function` and `step` fields do not match. ARTIFACT_UNBOUND A witness step's `attestation.witnessed_pack_id` did not match the real prior receipt — missing, wrong, or unverifiable against the durable record. missing_* Required field absent — e.g. `missing_function`, `missing_action_type`, `missing_nonce`. BAD_JSON Request body is not valid JSON. Check your JSON syntax. BAD_CONTENT_TYPE Content-Type header is missing or not application/json. BODY_TOO_LARGE Request body exceeds the size limit. METHOD_NOT_ALLOWED Request was not a POST. Only POST is accepted. UNAUTHORIZED Missing or invalid `Authorization: Bearer` header (wrapper) or `x-slp8-key` header (gate). Sequence rules ## The rules the gate enforces. These aren't soft guidelines. A violation on any one of them returns DENY immediately. **Steps must run in the configured order.** No skipping. Each step must follow the one before it — for example, `verify_identity` → `assess_risk` → `request_approval` → `execute_transfer`. An out-of-order step returns `SEQUENCE_VIOLATION`. **Nonces are single-use.** Each request must supply a unique nonce. Reusing any nonce — even from a prior sequence — returns `REPLAY_NONCE`. **function and action_type must be valid.** `function` must match `step`. `action_type` must be in the allowed set for that function. Invalid combinations return `ACTION_NOT_ALLOWED` or `FUNCTION_STEP_MISMATCH`. **Sequences seal after completion.** Once `settle` is accepted, the sequence locks. Any further request on that `sequence_id` returns `SEALED_SEQUENCE`. Start a new sequence with a fresh ID. **Only POST is accepted.** GET, PUT, PATCH and all other methods return `METHOD_NOT_ALLOWED` immediately. Attestation ## Embed evidence in the receipt. Each step can carry an `attestation` object — arbitrary evidence that travels with the request and gets **signed into the R2 receipt**. Use it to prove what happened at each step: an AML check passed, a human approved the action, an external system returned a specific result. The attestation is stored immutably alongside the receipt and appears in every compliance report generated for that sequence. It's not a separate log entry — it's part of the cryptographic chain. Python — attestation per step ``` from agenticrail import RailClient import time client = RailClient(api_key="DEMO-AGENTICRAIL-PUBLIC-2026") seq = client.sequence("payment-run-001", [ "verify_identity", "assess_risk", "request_approval", "execute_transfer", "audit_ledger" ]) # Attach evidence at each step — signed into the receipt seq.next("verify_identity", attestation={ "kyc_provider": "acme-kyc", "result": "pass", "checked_at": int(time.time() * 1000), }) seq.next("assess_risk", attestation={ "risk_score": 23, "threshold": 50, "decision": "below_threshold", }) seq.next("request_approval", attestation={ "approved_by": "risk-committee-id-7f3a", "approval_ref": "APR-2026-00412", }) seq.next("execute_transfer") # attestation optional — omit if nothing to prove seq.next("audit_ledger") # seals sequence — all attestations locked in chain ``` JavaScript — attestation per step ``` import { RailClient } from "@agenticrail/core"; const client = new RailClient({ apiKey: "DEMO-AGENTICRAIL-PUBLIC-2026" }); const seq = client.sequence("payment-run-001", [ "verify_identity", "assess_risk", "request_approval", "execute_transfer", "audit_ledger" ]); // Attach evidence at each step — signed into the receipt await seq.next("verify_identity", { attestation: { kyc_provider: "acme-kyc", result: "pass", checked_at: Date.now() } }); await seq.next("assess_risk", { attestation: { risk_score: 23, threshold: 50, decision: "below_threshold" } }); await seq.next("request_approval", { attestation: { approved_by: "risk-committee-id-7f3a", approval_ref: "APR-2026-00412" } }); await seq.next("execute_transfer"); // attestation optional await seq.next("audit_ledger"); // seals sequence — all attestations locked in chain ``` The `attestation` field accepts any plain JSON object. Values can include strings, numbers, and nested objects. Large binary blobs are not supported — store those in your own system and include a reference ID or hash here instead. Compliance Reports ## One command. Full provenance report. The report worker reads every receipt for a sequence, verifies the cryptographic chain, and produces a human-readable compliance report. This is the deliverable your lawyer, auditor, or regulator asks for — proof of what ran, verified independently of what the agent claims. Not a log export. Chain-verified receipt evidence, generated on demand for any sequence. 01 Request a report **Endpoint:** `POST https://report.agenticrail.nz/report` **Headers:** `Content-Type: application/json`, `x-slp8-key: ` **Body:** `{ "sequence_id": "your‑sequence", "format": "html"|"json" }` Demo key restricts to sequences prefixed `demo‑`. Production key accesses any sequence. 02 Report generation Worker scans R2 for all receipts matching the sequence ID, verifies each pack ID hash (multi‑generation logic), validates the receipt chain, and builds a compliance narrative via Claude (if `ANTHROPIC_API_KEY` configured). 03 Output formats **HTML:** Full‑page report with cover, sequence summary, enforcement log, chain proof, and compliance narrative. **JSON:** Structured data containing all verified receipts and verification results. Read‑only; no state mutation. curl — generate HTML report ``` # Replace SEQUENCE_ID with your sequence (demo‑ prefix for demo key) curl -X POST https://report.agenticrail.nz/report \ -H 'Content-Type: application/json' \ -H 'x-slp8-key: DEMO-AGENTICRAIL-PUBLIC-2026' \ -d '{ "sequence_id": "demo‑my‑seq‑001", "format": "html" }' ``` Reports are deterministic — the same sequence always yields identical output. Verification uses multi‑generation hash checking to handle Gen‑1 and Gen‑2 receipts. Compliance Evidence ## What the receipt chain proves — and to whom. Every gate call produces enforcement output (ALLOW/DENY). It also produces a compliance record — a signed, chained, immutable receipt that answers the question regulators and lawyers actually ask: *"Can you prove what the AI did?"* These are the same facts. Different audience, different frame. Engineering question "Did the agent proceed correctly? Was the step blocked? Why?" Answered by the gate decision: `ALLOW`, `DENY`, reason codes. Compliance question "Can you prove what the AI did last Tuesday — not what it reported, what it actually executed?" Answered by the receipt chain: signed, chained, tamper-evident. ### Receipt field reference — what each field proves | Receipt field | What it proves | | pack_id | Unique identifier for this enforcement decision — the canonical reference for this chain link. | | signature (Ed25519) | Tamper evidence. An Ed25519 signature (base64) over the canonical receipt, verifiable offline against the published public key (/spec/receipt-public-keys.json). If the receipt was altered after writing, verification fails. Legacy receipts before 2026-06-07 use HMAC-SHA256. | | prev_receipt_id | `pack_id` of the previous receipt — an identifier reference establishing chain order. On its own, proves something with that identifier came before; see `prev_receipt_hash` below for content-tamper protection. | | prev_receipt_hash | SHA-256 of the previous receipt's full canonical JSON, signature included (added 2026-07-08). An in-place edit to any earlier receipt breaks this link even if `prev_receipt_id` references still match — this is what actually invalidates the report on tampering. Null for the chain's first receipt and for any link whose anchor predates this field. | | ts_ms | Timestamp to the millisecond — when the gate decision was made. Written at enforcement time, not retrieved or reconstructed later. | | payload_hash | SHA-256 of the raw request body — the fingerprint of your payload, not the payload itself. Your agent's input data never enters immutable storage. An auditor can verify the receipt is cryptographically bound to a specific payload without ever seeing that payload's contents. | | attestation | Per-step evidence signed into the receipt — AML check results, human approval tokens, risk scores, KYC references. Proves what justified this specific decision. | Key distinction Logs are self-reported — the AI agent tells you what it did. Receipts are structural — the gate wrote them before the agent acted, independent of the agent's own reporting. An auditor cannot distinguish a genuine log from a reconstructed one. They can verify a receipt chain cryptographically. That difference is what makes AgenticRail evidence rather than documentation. Next steps ## Ready to go further? The demo key is open for testing. When you're ready for production — dedicated rate limits, private key, support, and integration help — get in touch. ### Get a production key No rate limits. Private key. Direct support. Contact us and we'll have you set up within 24 hours. [hello@agenticrail.nz →](mailto:hello@agenticrail.nz) Looking for the formal side instead? The [enforcement specification](https://agenticrail.nz/spec/) (versioned, fingerprinted, frozen) and the published briefs — [evidence completeness](https://agenticrail.nz/spec/completeness/), [provable safeguards for automated decisions](https://agenticrail.nz/spec/enforceable-safeguards/), sector gap analyses for [NZ health](https://agenticrail.nz/spec/nz-health/) and [NZ education](https://agenticrail.nz/spec/nzqa-nz-education/) — all live under [/spec/](https://agenticrail.nz/spec/). --- # AgenticRail — it won't let your AI skip a step > Markdown mirror for AI agents, generated 2026-07-23 from the live page. > Canonical: https://agenticrail.nz/ > Site context: https://agenticrail.nz/llms.txt Deterministic enforcement · Ed25519-sealed receipts # It won't let your AI skip the step that matters. AgenticRail is a deterministic gate that blocks an AI agent from acting out of order — **before the action runs**, not after. Every decision it's allowed to make is sealed into a signed receipt anyone can verify offline, with no callback to us. It doesn't make the AI right. It makes the order **unskippable, and the record impossible to quietly change.** ## The gap The harm that leaves no trace Almost everywhere AI now makes or drafts a decision, a human is meant to check it — and almost nowhere is there proof the check happened. The safeguard is real; the record of it is missing. That silence, not the AI's mistakes, is the dangerous part: when something goes wrong, there is nothing to point to. ## What it does Two powers, at the one boundary you can't avoid — the moment before an AI acts. - 1**Refuse.** A step that is out of order, replayed, or not permitted is denied — deterministically, before it runs. Not an AI guessing whether to allow it; a computed decision that can't hallucinate its own verdict. - 2**Witness.** Every decision — ALLOW or DENY — is written to a signed, chain-linked receipt in immutable storage, before the action executes. Nothing is recorded after the fact; nothing can be altered without breaking the chain. ``` agent → gate → ALLOW / DENY → sealed receipt ``` ## The proof — verify it yourself Don't take our word for it. Every receipt is signed with **Ed25519** and verifiable **offline** against a public key we publish — no callback to AgenticRail. Re-hash the record and check the signature in your own code, or paste a sequence ID into the [report tool](https://report.agenticrail.nz/report). Signed receipt · illustrative shape decisionALLOW stepreview_and_sign payload_hashsha256 of the exact record signature_algEd25519 key_idk2_2026-06-07_ed25519 signaturebase64 — verify offline or at /report sealedtrue ## The AI wrote the note. What proves the doctor checked it? AI scribes now draft clinical notes, and a clinician is required to review each one before it is saved — but nothing proves the review happened. This is where AgenticRail fits. Placed at the sign-off, it seals a receipt — **bound to a fingerprint of the exact note** — recording that this report was reviewed and signed by this clinician, at this time, and cannot be altered afterward without breaking the seal. It can't force a careful read, and it doesn't claim to. What it ends is *"the AI did it"* as an answer — and it protects the clinician who *did* review, by making that review provable. ## What it is — and isn't | It is | It is not | | Deterministic enforcement — the verdict is computed, not an AI's guess | A lie-detector for the AI. It proves *what* was done, not that the AI was *right* | | A tamper-evident, offline-verifiable record | A stop on hallucination, or a force on human attention | | Metadata and hashes only — no clinical content inside a receipt | A claim to data sovereignty — it is a bounded instrument; keys and governance stay with you | ## Where it comes from AgenticRail was derived from **whakairo** — the carver's discipline, where order is law and the finished form is sealed. That lineage is the reason for the seal, not decoration on it. [The whakapapa →](https://agenticrail.nz/whakapapa/) ## Published briefs & specifications Written to be cited, fingerprinted to be checked. Each carries a SHA-256 fingerprint you can recompute yourself. **[Automated Decisions and the Provable Safeguard](https://agenticrail.nz/spec/enforceable-safeguards/)** — three tiers of safeguard (asserted, enforced, provable), why the difference decided Robodebt, and a five-minute test anyone can run. **[AI in NZ Health Care: The Missing Evidence Layer](https://agenticrail.nz/spec/nz-health/)** — sector gap analysis: national AI-scribe rollout, the human-review safeguard, and the record that doesn't yet exist. **[AI in NZ Education Assessment: The Missing Evidence Layer](https://agenticrail.nz/spec/nzqa-nz-education/)** — sector gap analysis: NCEA authenticity, moderation, and the self-attested evidence chain. **[The Completeness Specification](https://agenticrail.nz/spec/completeness/)** — eight requirements (R1–R8) that separate an evidence-grade enforcement record from an ordinary log. **[The Enforcement Specification](https://agenticrail.nz/spec/)** — the canonical spec: decision architecture, receipt fields, signing, and the sealed chain. Versioned and frozen. **[Writing](https://agenticrail.nz/blog/)** — technical posts, each re-checked claim-by-claim against the current system before republication. **Verify a receipt, or start a conversation.** [Verify a sequence](https://report.agenticrail.nz/report) · [hello@agenticrail.nz](mailto:hello@agenticrail.nz) Hokianga Harbour Heads, Northland, Aotearoa — where AgenticRail is built He toi whakairo, he mana tangata