# AgenticRail — Full-Text Mirror for AI Agents > Every markdown mirror on this site, concatenated into one file, generated 2026-08-12 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? > Markdown mirror for AI agents, generated 2026-08-12 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 Evidence Supports an AI-Marked Assessment Decision? — AgenticRail > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/spec/ai-marked-assessment/ > Site context: https://agenticrail.nz/llms.txt **Document type** Sector Note — Evidence Brief **Subject** Evidence for assessment decisions in which an automated system marked or assisted the marking **Published by** TUARA KURI LIMITED — trading as AgenticRail, Hokianga, Aotearoa New Zealand **Date** 2026-07-26 **Version** 1.0 **Status** Published — open for citation **Related** AI in New Zealand Education Assessment · Automated Decisions and the Provable Safeguard · Completeness specification # When the Marker Is a Machine: What Evidence Supports an AI-Assisted Assessment Decision? New Zealand marks national writing assessments with automated scoring, quality assured by human check-marking concentrated at the achievement boundaries. The safeguard is real, it is publicly described, and it is better documented than most comparable programmes anywhere. This note does not question whether it happens. It asks a narrower and harder question: when one student challenges one result, what evidence shows the check ran *on that script*? An agreement rate is a property of a system measured across a population. A challenge is about an instance. Those are different objects, and only one of them is currently recorded. ## 1. Scope and definitions This is a sector note. It is not a regulation, it confers no compliance, and it asserts no failure by any New Zealand agency, school, teacher, or marker. Three terms are used throughout in a fixed sense, because the whole argument depends on holding them apart. **A control** is a step required by policy or design — for example, a human reviewing an automatically generated score before a result is released. **A record** is any account that a control occurred. A record may be real and still be self-attested, revisable after the fact, incomplete, or produced on request rather than at the time. **Evidence** is a record that was created before or at the moment of the action, sealed so it cannot afterwards be added to or altered without detection, and verifiable by a party who does not have to trust the system that produced it. A control can be genuinely operating and produce no evidence in this sense. That is not a contradiction and it is not an accusation. It is the ordinary state of most automated systems, and it is the only thing this note is about. ## 2. What is already running The following are public facts, cited in §8. They are stated here without inference. **2.1 — Automated marking is in national production, not pilot.** NZQA's Automated Text Scoring (ATS) ran a large-scale trial of approximately 35,000 writing responses in September 2024, reporting roughly 80% agreement with human markers [1][2]. From May 2025, automated scoring has been applied to all digitally submitted writing assessments, with more than 55,000 assessments marked, and results returned about three and a half weeks faster than the previous cycle [3]. **2.2 — Human marking is retained as the named quality-assurance control.** Human marking is retained at the achievement boundary, covering over a third of cases, and the human score overrides the automated score where the two differ [3]. This is a deliberate and defensible design: it concentrates scarce human attention at the point where a score change alters the outcome for the student. **2.3 — The programme is expanding under contract.** NZQA released RFP 33045390, "NZQA AI Marking Model Design and Implementation," on 20 November 2025; it closed on 5 December 2025 and was awarded to Amazon Web Services on 17 February 2026 [4]. The stated scope is to design and implement an AI-based system for marking, to enhance the accuracy, efficiency and fairness of assessment processes. **2.4 — Automated assistance is planned for moderation, not only marking.** NZQA's September 2025 publication on its responsible use of artificial intelligence names moderation support for internally assessed work among its planned tools [5]. Moderation is the check applied to marking. §5 returns to what follows from that. **2.5 — The direction is publicly committed at ministerial level.** In August 2025 the responsible Minister stated publicly that AI marking is "as good, if not better than human marking" and described New Zealand as extraordinarily advanced relative to the rest of the world [6]. This note takes that commitment at face value and is addressed to what would substantiate it under challenge. ## 3. The safeguard is real. The question is whether it is provable. The structural observation The quality-assurance mechanism for automated scoring is human check-marking. If a party outside the operating authority asks, of one specific result, "show me that the check ran on this script, and that it ran before the result was released," the answer available today is the authority's own account of its own process. There is no independent verification body for this control, no external attestation of an individual result, and no mechanism by which an appeals panel, an Ombudsman, or a student's representative could confirm the step occurred without re-trusting the same organisation whose process is in question. This is not unusual and it is not alleged to be a breach of anything. It is the standard architecture, and it is the specific thing that a challenge tests. The distinction being drawn is narrow and worth stating precisely. Nothing here suggests check-marking does not occur. The claim is that "it occurs" and "its occurrence on a given script can be confirmed by someone outside the agency" are two different properties, that a system can hold the first without the second, and that only the second survives a dispute in which the agency's own account is what is being contested. ## 4. Why an agreement rate cannot answer a single case An agreement rate — roughly 80%, in the trial figures above — is a statistical property of a system, measured across a population of scripts. It is a good and appropriate measure of whether an automated scorer is fit to deploy. It is the right instrument for the question it answers. It carries no information about any particular script. A system with a high agreement rate still produces individual results that differ from what a human marker would have given, and the aggregate figure cannot identify which ones. This is a property of aggregate measures generally, not a defect in this one. The consequence is specific. When a student challenges a result, the question in front of the reviewer is not "is this system accurate overall." It is: | The question a challenge actually asks | What an aggregate agreement rate can say | What a sealed per-script record can say | | Was this script scored by the automated system, by a human, or by both? | Nothing about this script. | Which steps ran, in order, with times. | | Did the human check-marking step occur on this script? | Nothing about this script. | Whether it occurred, and the identity and role of the reviewer. | | Did it occur *before* the result was released, or after the challenge was raised? | Nothing about this script. | The ordering, fixed at the time and not reconstructable afterwards. | | If the two scores differed, was the human score the one applied? | Nothing about this script. | The decision recorded at the moment it was taken. | **The boundary-concentration point cuts both ways, and honestly.** Because human check-marking is concentrated at the achievement boundary, a script well inside a grade band may correctly have received no human review. That is the design working as intended, and it is defensible. But it means "was this checked by a human" has two legitimate answers, and the difference between them is currently invisible from outside. A record that shows *which regime a given script fell under* converts a potential accusation into a documented and defensible design decision. This is the case for the record, not against the design. ## 5. When the check itself is assisted Moderation is the control applied to marking — the layer that provides assurance that marking was done properly. Where an automated tool assists moderation [5], the assurance layer acquires the same property as the layer beneath it: it now performs a step whose occurrence, on any particular case, is recorded only by the party performing it. This does not make such a tool inappropriate. Moderation at national scale is genuinely burdensome, and the sector has said so in its own submissions on the replacement of NCEA, describing consistently raised concerns about over-assessment and the heavy demands of moderation, and asking specifically for secure platforms for assessment and moderation [7]. What follows is narrower: the evidence question moves up a level rather than being answered. If marking is checked by moderation, and moderation is assisted by a system whose own steps are self-recorded, then the chain of assurance terminates at an account rather than at a record. It stops being recursive only when some step in the chain produces evidence that does not depend on the account of the party being checked. ## 6. What the record would need to be The requirements are specified neutrally, and independently of any vendor, in the companion [Completeness Specification](https://agenticrail.nz/spec/completeness/). Four of the eight are load-bearing here. | Requirement | Why it matters for a contested grade | | **Created before or at the moment of the step** | A record written after a challenge is raised cannot establish the order of events, which is the fact most challenges turn on. | | **Independent of the system being recorded** | If the marking system writes its own account of whether it was checked, the account and the subject are the same party. | | **Signed and verifiable offline** | An appeals panel or Ombudsman can confirm the record against a published key without a request to, or cooperation from, the authority. | | **Sealed** | Once the sequence closes, the account is fixed. Later additions are detectable rather than silent, which is what makes the record worth anything in a dispute. | Applied to check-marking At the moment a marker opens a script flagged for check-marking, an external gate writes a signed receipt recording the script identifier, the reviewer's identity and role, the automated score presented, the time, and the position of this step in that script's assessment sequence. When the score is confirmed or overridden, a second receipt records which. The sequence is sealed when the result is released. The authority cannot alter the record afterwards without the alteration being detectable; a challenge two years later is answered by verification rather than by recollection; and the marker is protected as much as the student, because "the check was never done" becomes a checkable claim rather than an accusation that cannot be disproved. No additional work is asked of the marker — the receipt is a by-product of the step, not a second task. `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 — including one built under an existing contract — can be assessed against the same requirements. ## 7. What this does not do **Each of the following states something true about the record, followed by its limit.** **The record establishes what happened and in what order. It does not establish that the result was correct.** A receipt showing that a human reviewed a script says the review took place. It says nothing about whether the reviewer was right, attentive, or qualified for that subject. Marking quality is a separate problem with separate instruments. **Tamper detection has a boundary.** A sealed, chained record makes later alteration detectable. Detectable is not impossible: a party holding the signing keys could produce a consistent but false chain. What closes that gap is custody — a copy held by someone who is not the operator — not stronger cryptography. **The record narrows a dispute; it does not resolve it.** If a marking rule or model is itself flawed, faithful execution of that rule produces impeccable receipts of a flawed rule being applied. The value is that the argument moves from "what happened" to "was the rule right," which is the argument worth having. **This note asserts no failure by any New Zealand agency.** NZQA has published more about its automated marking, its agreement rates, and its human-oversight arrangements than most comparable authorities anywhere. That transparency is what makes this note possible to write from public sources, and it is the reason the gap discussed here is a design question rather than a complaint. No individual is named. ## 8. How to check every claim on this page Every factual claim in §2 is cited below to a primary or named public source. The claims about the instrument can be checked directly, without contacting anyone: - Run the [live demo](https://agenticrail.nz/demo/). It executes a real multi-step sequence against the production gate and returns a sequence identifier. - Paste that identifier into the [verification tool](https://report.agenticrail.nz/report). It returns every receipt, each with its raw signature and the exact bytes that were signed. - 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, with no call back to the operator. If a claim on this page does not match the live system, the live system is the authority and the page is wrong. ## 9. References [1] RNZ, "Artificial intelligence exam-marking on the way for Year 10 writing tests" — [rnz.co.nz](https://www.rnz.co.nz/news/national/557671/artificial-intelligence-exam-marking-on-the-way-for-year-10-writing-tests) [2] SchoolNews NZ, "NZQA: AI-marking now a reality" — [schoolnews.co.nz](https://www.schoolnews.co.nz/2025/06/nzqa-ai-marking-now-a-reality/) [3] NZQA, "Embracing AI in student assessments" — [nzqa.govt.nz](https://www2.nzqa.govt.nz/about-us/news/embracing-ai-in-student-assessments/) [4] GETS (Government Electronic Tenders Service), RFx ID 33045390, "NZQA AI Marking Model Design and Implementation," awarded 17 February 2026 — [gets.govt.nz](https://www.gets.govt.nz/NZQA/ExternalTenderDetails.htm?id=33045390) [5] NZQA, "NZQA's Responsible Use of Artificial Intelligence," September 2025 — [nzqa.govt.nz](https://www2.nzqa.govt.nz/about-us/news/nzqas-responsible-use-of-artificial-intelligence/) [6] RNZ, coverage of ministerial statements on AI marking, 5 August 2025 — [rnz.co.nz](https://www.rnz.co.nz/news/national/557671/artificial-intelligence-exam-marking-on-the-way-for-year-10-writing-tests) [7] PPTA Te Wehengarua, *Submission on the proposal to replace NCEA* — [ppta.org.nz](https://www.ppta.org.nz/assets/DMSDocuments/Submissions/PPTA-submission-on-the-proposal-to-replace-NCEA.pdf) (linked from the union's [Replacing NCEA](https://www.ppta.org.nz/campaigns/replacing-ncea-the-new-qualification) campaign page) [8] Ministry of Education / Te Poutāhū, *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) [9] Companion brief — [AI in New Zealand Education Assessment: The Missing Evidence Layer](https://agenticrail.nz/spec/nzqa-nz-education/), covering student-work authenticity and the internal moderation cycle. [10] Companion note — [Automated Decisions and the Provable Safeguard](https://agenticrail.nz/spec/enforceable-safeguards/), covering the asserted / enforced / provable distinction in the public sector generally. Document Fingerprint — SHA-256 — v1.0 6b8172edeacab28bc163e5a96676a2c3648828218356969fb075bbd282e93bcc 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):** `When the Marker Is a Machine|1.0|2026-07-26|TUARA KURI LIMITED|NZQA Automated Text Scoring 35000 writing responses trial September 2024 approx 80 percent agreement with human markers|from May 2025 applied to all digitally submitted writing assessments over 55000 marked results 3.5 weeks faster|human marking retained at achievement boundary over a third of cases human score overrides where they differ|GETS RFx 33045390 NZQA AI Marking Model Design and Implementation awarded Amazon Web Services 17 February 2026|NZQA September 2025 responsible use of AI names moderation support for internally assessed work as planned tool|control record evidence are three distinct things a control can operate and produce no evidence|an agreement rate is a property of a system across a population a challenge is about an instance|aggregate accuracy cannot identify which individual results differ|boundary concentration means was this checked by a human has two legitimate answers and the difference is invisible from outside|where an automated tool assists moderation the evidence question moves up one level rather than being answered|chain of assurance terminates only at a record not dependent on the account of the party being checked|record establishes what happened and in what order not that the result was correct|tamper detection is detectable not impossible custody closes the gap not cryptography|completeness R1-R8|report.agenticrail.nz` Published: 2026-07-26 | Version: 1.0 | Entity: TUARA KURI LIMITED **Sourcing note:** every factual claim in §2 is cited to a primary or named public source in §9. This note asserts no failure, breach, or bad faith by any New Zealand agency, school, teacher, or marker, and names no individuals. --- # If AI Detectors Don't Work, What Does? Authenticity by Process Record > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/spec/assessment-authenticity/ > Site context: https://agenticrail.nz/llms.txt **Document type** Sector Note — Evidence Brief **Subject** Establishing authenticity of student work where detection has been withdrawn **Published by** TUARA KURI LIMITED — trading as AgenticRail, Hokianga, Aotearoa New Zealand **Date** 2026-07-26 **Version** 1.0 **Status** Published — open for citation **Related** When the Marker Is a Machine · AI in New Zealand Education Assessment · Completeness specification # If AI Detectors Don't Work, What Does? Authenticity by Process Record There are three available responses to generative AI in assessment: prohibit it, detect it, or record the process that produced the work. New Zealand has now tried the first two at national scale and documented what each costs. Detection has been withdrawn by three universities and ruled unsuitable as a sole means by national guidance. Reverting to supervised handwriting works, and shifts the cost onto specific students. This note sets out why the first two options share a single structural weakness — both interrogate the finished artifact — and what the third option looks like when the object of examination is the sequence instead. ## 1. Scope This is a sector note. It confers no compliance and asserts no failure by any institution, teacher, or student. It is written from published sources, cited in §8, and its argument is general even though its evidence is mostly from Aotearoa New Zealand — the New Zealand material is unusually useful precisely because the decisions were made publicly and the reasoning was stated on the record. One distinction is load-bearing throughout. **Artifact-based methods** examine the finished work and infer how it was made. **Process-based methods** record how the work was made, as it is being made. Detection and prohibition are both artifact-based, which is why they fail in related ways. ## 2. Option one — prohibit, or revert to supervised production This works. It is also the option that has been most visibly taken. In New Zealand's schools system, reports were discontinued as an assessment method for NCEA Level 1 entirely from 2025, with authenticity concerns "including the rapid advancement in AI tools" given as the reason [1]. In the tertiary system, Victoria University of Wellington's law school moved two third-year courses to handwritten examinations for the June 2025 exam period, after its dean said advances in AI had made it difficult to be confident work was a student's own and that a technical solution for policing it was not yet available [2][3]. The university's provost described handwritten examinations as "the gold standard of ensuring integrity" [3]. That description is accurate, and the control is a reasonable response to an unsolved problem. What it does not do is remove the cost — it relocates it. - The burden falls on students who compose digitally, which national reporting noted was difficult for students accustomed to writing on a keyboard [3]. - It requires explicit exemptions for students with disabilities who need keyboards [2] — meaning the integrity control and the accessibility provision are in direct tension, and the exemption is itself an exception to the assurance. - It constrains what can be assessed to what can be produced unaided in a supervised room, which excludes most extended, researched, or collaborative work. - It does not scale to the roughly three-quarters of NCEA assessment carried out internally [4], where supervision of this kind is not the model. Prohibition answers the authenticity question by removing the conditions under which it arises. That is legitimate, and it is not a general answer. ## 3. Option two — detect. Tried, measured, and withdrawn. The documented position The Ministry of Education's guidance on generative AI in NCEA assessment states that AI detection software "should not be relied upon to ensure authenticity," that such tools are "susceptible to returning 'false positive' results," and that they are "therefore unsuitable to use as the sole means of ensuring authenticity" [5]. In the tertiary sector the position moved from caution to withdrawal: Massey University confirmed it no longer uses AI detection tools, switching off the detection feature following student reports of false accusations, after earlier moves by the University of Auckland and Victoria University of Wellington [6]. A Massey spokesperson described the tools as ineffective and noted that academic practice had been inconsistent — some staff treated a result as a guideline, others treated a flagged percentage as grounds for an accusation [6]. The University of Auckland's stated position is that it is extremely difficult to prove work is AI-generated absent obvious signs, and that students can use readily available tools to check whether their work will be flagged and adjust it until it is not [6]. **3.1 — The failure is not a maturity problem.** A detector infers machine authorship largely from perplexity: how statistically surprising the text is. Text that a language model would find unsurprising is scored as likely machine-written. That inference is structurally unable to distinguish machine-generated text from human text that happens to be plain, formulaic, or written within a narrow range of expression — which is not a defect that a better model removes, because the signal it relies on is genuinely shared by both. **3.2 — The bias is measured, and it falls in a specific direction.** A peer-reviewed study of widely used GPT detectors found they consistently misclassified writing by non-native English speakers: more than half of non-native-authored TOEFL essays were incorrectly classified as AI-generated, while the same detectors achieved near-perfect accuracy on essays by US eighth-grade students [7]. The authors hypothesise the mechanism above — lower perplexity arising from restricted linguistic variability — and its senior author's stated recommendation was to be extremely careful about using such detectors, and to consider avoiding them [7][8]. The consequence is that the students most likely to be wrongly accused are the students least equipped to contest the accusation, and the accusation is generated by a tool whose output is a probability with no supporting account of what actually happened. This is the specific harm behind the phrase "false positive results" in the national guidance. **3.3 — And it is evadable by exactly the people it is aimed at.** As the University of Auckland's position notes, tools exist that let a student test their work against detectors and revise until it passes [6]. A control that systematically misfires on the innocent and can be routinely evaded by the deliberate is not a control that becomes adequate with tuning. ## 4. The shared root: both options interrogate the artifact Prohibition and detection look like opposites — one prevents, one polices — but they ask the same underlying question: *what does this finished piece of work tell us about how it was made?* Asked of an artifact, that question has no reliable answer, and the reason is not technological. A finished document is the same document whether it was drafted over three weeks or generated in nine seconds. The information that distinguishes them is not in the artifact. It was in the process, and the process was not recorded. | | Detection | Process record | | **Object examined** | The finished work | The sequence that produced and checked it | | **Question asked** | Does this look machine-generated? | Which steps occurred, in what order, and when? | | **Answer type** | A probability | A record that is present or absent | | **When it is produced** | After the fact | At the time of each step | | **Failure mode** | Accuses the innocent; misses the deliberate | Shows a step is unrecorded — which is a question, not a verdict | | **Burden** | Student must disprove a score | Student can demonstrate their process | That last row is the one that matters most for the equity problem in §3.2. Under detection, a student flagged by a biased tool is asked to prove a negative about their own mind. Under a process record, a student who did the work has something to point at. The direction of the burden reverses, and it reverses in favour of the person with the least power in the situation. ## 5. Option three — record the process The existing verification practices are already process-based; what they lack is durability. National guidance describes the teacher's discharge of the responsibility to verify as knowing the student and their work, verbal questioning, inspecting a document's version history, and having the student sign a declaration or authenticity statement [5]. Every one of those is an examination of process rather than artifact. The gap is that none of them produces a record that survives being disputed: a declaration form is a self-attestation on paper, and version history is held by the same system the work was produced in. What turns those practices into evidence is specified, neutrally and independently of any vendor, in the companion [Completeness Specification](https://agenticrail.nz/spec/completeness/). Applied here, four properties do the work: | Property | What it changes | | **Written at the time of the step** | A record created when the check happened cannot be assembled afterwards to fit a conclusion. | | **Independent of the system being recorded** | Version history inside the authoring tool is written by the tool. An external record is not. | | **Signed and verifiable offline** | A student, an appeals panel, or an external reviewer can check the record against a published key without asking the institution's permission. | | **Sealed at completion** | Once submitted, the account of how the work was produced is fixed. Later additions are detectable rather than silent. | What this looks like in practice A declared sequence for a piece of internally assessed work might be: task issued, plan submitted, draft submitted, feedback given, final submitted, authenticity check completed, result recorded. Each step writes a signed receipt at the moment it occurs, chained to the one before it, and the sequence is sealed when the result is recorded. Nothing in the receipt is the student's work — the receipt records that a step happened, when, and in what order, not what was written. If a question is later raised, the sequence is either intact and complete, or it shows plainly where a step is missing. A missing step is not an accusation; it is the start of an ordinary conversation, held with a record instead of two recollections. `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 requirements. ## 6. What this does not do **Each of the following states something true about a process record, followed by its limit.** **A process record establishes that a declared sequence occurred in order and was not altered afterwards. It does not establish that the thinking was the student's own.** A person determined to submit work they did not produce can perform every step of a recorded process while sourcing the content elsewhere. This note claims no solution to that, and any product claiming one should be treated with suspicion. What the record removes is the far larger class of dispute in which nobody can establish what happened at all. **The record answers a question about process, which is what most integrity disputes actually turn on.** The genuine cases of undetectable substitution are a narrower problem than the day-to-day one, which is that a check was required, may well have occurred, and cannot be shown to have occurred. **Tamper detection has a boundary.** A sealed, chained record makes later alteration detectable. Detectable is not impossible: a party holding the signing keys could construct a consistent but false chain. What closes that gap is custody — a copy held by a party who is not the institution — not stronger cryptography. **Recording a process adds an obligation, and it should be honest about that.** A sequence that nobody follows produces receipts of nothing. This approach suits assessment that already has declared, staged steps; it does not suit a single unstructured submission with no process to record, and it should not be retrofitted onto one by inventing ceremony. **This note takes no position on whether students should use generative AI.** That is a curriculum and pedagogy question belonging to teachers and their institutions. The argument here holds whichever way it is answered: a permitted use and a prohibited use both need a record of what actually happened. ## 7. How to check every claim on this page Every factual claim in §2 and §3 is cited to a named public source in §8. The claims about the instrument can be checked directly: - Run the [live demo](https://agenticrail.nz/demo/). It executes a real multi-step sequence against the production gate and returns a sequence identifier. - Paste that identifier into the [verification tool](https://report.agenticrail.nz/report). It returns every receipt with its raw signature and the exact bytes that were signed. - 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, with no call back to the operator. If a claim on this page does not match the live system, the live system is the authority and the page is wrong. ## 8. References [1] RNZ, "Schools abandon take-home assignments after artificial intelligence used to cheat" — [rnz.co.nz](https://www.rnz.co.nz/news/education/528800/schools-abandon-take-home-assignments-after-artificial-intelligence-used-to-cheat) [2] RNZ, "Victoria law students not allowed laptops in exams to prevent AI cheating" — [rnz.co.nz](https://www.rnz.co.nz/news/national/560059/victoria-law-students-not-allowed-laptops-in-exams-to-prevent-ai-cheating) [3] RNZ, "Return to pen and paper for some university exams tough for digitally savvy students" — [rnz.co.nz](https://www.rnz.co.nz/news/national/560123/return-to-pen-and-paper-for-some-university-exams-tough-for-digitally-savvy-students) [4] 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) [5] 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) [6] RNZ, "Universities give up using software to detect AI in students' work" — [rnz.co.nz](https://www.rnz.co.nz/news/national/574517/universities-give-up-using-software-to-detect-ai-in-students-work) [7] W. Liang, M. Yuksekgonul, Y. Mao, E. Wu, J. Zou, "GPT detectors are biased against non-native English writers," *Patterns* 4(7), 2023 — [arxiv.org/abs/2304.02819](https://arxiv.org/abs/2304.02819) [8] Stanford University / ScienceDaily summary of [7], "GPT detectors can be biased against non-native English writers" — [sciencedaily.com](https://www.sciencedaily.com/releases/2023/07/230710113921.htm) [9] Companion note — [When the Marker Is a Machine](https://agenticrail.nz/spec/ai-marked-assessment/), on evidence for decisions in which an automated system did the marking. [10] Companion brief — [AI in New Zealand Education Assessment: The Missing Evidence Layer](https://agenticrail.nz/spec/nzqa-nz-education/), on the statutory basis and the internal moderation cycle. Document Fingerprint — SHA-256 — v1.0 c449bd0cb65c183e6c0c8a9c688e6f0067a71b4eb122137b3d907a7066e9f320 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):** `If AI Detectors Don't Work What Does|1.0|2026-07-26|TUARA KURI LIMITED|three responses to generative AI in assessment prohibit detect or record the process|prohibition and detection are both artifact-based they interrogate the finished work|NCEA Level 1 reports discontinued as an assessment method from 2025 citing authenticity and rapid advancement in AI tools|Victoria University of Wellington law school moved two third-year courses to handwritten exams June 2025 exam period|provost described handwritten exams as the gold standard of ensuring integrity|handwriting relocates the cost onto students who compose digitally and requires exemptions for students with disabilities needing keyboards|Ministry of Education March 2025 guidance AI detection software susceptible to false positive results unsuitable as the sole means of ensuring authenticity|Massey University no longer uses AI detection tools switched off following student reports of false accusations after University of Auckland and Victoria University of Wellington|University of Auckland position students can use tools to check whether work will be flagged and revise until it is not|Liang Yuksekgonul Mao Wu Zou GPT detectors are biased against non-native English writers Patterns 2023 arXiv 2304.02819|more than half of non-native-authored TOEFL essays misclassified as AI-generated near-perfect accuracy on US eighth-grade essays|detectors infer machine authorship from low perplexity which is shared by plain human writing|under detection the student must disprove a score under a process record the student can demonstrate their process|a process record does not establish that the thinking was the student's own|tamper detection is detectable not impossible custody closes the gap not cryptography|completeness R1-R8|report.agenticrail.nz` Published: 2026-07-26 | Version: 1.0 | Entity: TUARA KURI LIMITED **Sourcing note:** every factual claim in §2 and §3 is cited to a named public source in §8. This note asserts no failure, breach, or bad faith by any institution, teacher, or student, and names no individuals other than the authors of the cited academic study. --- # Segregation of Duties When an AI Agent Is Both Maker and Checker > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/spec/segregation-of-duties/ > Site context: https://agenticrail.nz/llms.txt **Document type** Controls Note — Evidence Brief **Subject** Segregation of duties, IT general controls and audit evidence where an autonomous agent both authorises and executes **Published by** TUARA KURI LIMITED — trading as AgenticRail, Hokianga, Aotearoa New Zealand **Date** 2026-08-04 **Version** 1.0 **Status** Published — open for citation **Related** [Completeness specification](https://agenticrail.nz/spec/completeness/) · [Provable safeguards](https://agenticrail.nz/spec/enforceable-safeguards/) # Segregation of Duties When the Agent Is Both Maker and Checker Most writing about controlling AI agents invents new vocabulary for the problem. This note does the opposite. **An autonomous agent with tool access breaks a control that has existed in accounting and banking for longer than computing has: segregation of duties.** The party that authorises an action must not be the party that performs it. An agent decides and then acts, so it is maker and checker in the same process. That is not a new category of risk requiring a new discipline. It is an old control failing in a new place — which is fortunate, because it means the people who already test that control have the vocabulary, the mandate and the budget to test this one. This note sets out what they ask for, why an audit log usually does not answer it, and what a refused step has to leave behind to count as evidence. ## 1. Scope This is a controls note, not legal or audit advice, and not a compliance claim. It takes no position on whether any particular process should be automated. It describes a structural gap between what autonomous software does and what control frameworks assume, and it identifies what would close that gap. Where a regime is named it is named as an example of an existing duty, not as a claim that any product satisfies it. Throughout, one distinction is held: a **record** is something a system writes about itself; **evidence** is a contemporaneous record that a party outside the operating system can verify without trusting that system. The gap described here is in the second. ## 2. The Control That Predates the Technology Segregation of duties (SoD) is the requirement that no single actor controls an entire transaction from initiation to completion. In banking it is usually called **maker-checker**; in European practice, the **four-eyes principle**. The control appears in every serious framework of IT general controls (ITGC) and application controls, and it is one of the first things an internal or external auditor tests, because almost every fraud and most large operational errors involve one party holding both roles. It survives because it does not depend on anyone being trustworthy or competent. It is structural. The checker does not need to be smarter than the maker, or even to understand the transaction fully. The checker only needs to be *separate*, and to be unable to be overruled by the maker. Where SoD genuinely cannot be achieved — a small team, an unavoidable single administrator — audit practice does not simply waive it. It requires a **compensating control**: something else that constrains the actor, plus evidence that the something else actually operated. The compensating control is accepted only when it produces its own record. It is worth noting exactly what the standards list as acceptable compensating controls. ISACA's guidance names audit trails, management review and exception reports [6]. The PCAOB's integrated-audit standard names supervisory review of detailed activities, reconciliation of accounts, and review of exception reports [7]. The IIA's guidance on segregation of duties names transaction-level audit trails, independent reconciliation and supervisory review of exception reports [8]. **Every item on those lists is detective rather than preventive, and every one of them is performed after the transaction has already occurred.** That is a reasonable design when the thing being constrained is a person, because a person can be disciplined, retrained or dismissed, and the loss can often be reversed. It is a weaker design when the thing being constrained is software that can repeat the same action several thousand times before the exception report is read. ## 3. The Failure Shape — an agent occupies both roles Give an autonomous agent a set of tools and the authority to call them, and the architecture looks like this: the agent interprets a goal, selects an action, and issues the call. Nothing between the selection and the call is separate from the thing doing the selecting. The agent is maker and checker in one process. The usual mitigations do not restore separation: - **A confirmation prompt in the system prompt** asks the model to seek approval. The model may comply. It is an instruction to the maker, not a separate checker, and it is not enforced anywhere outside the model's own reasoning. - **Human-in-the-loop approval** does restore separation, and it is the right answer for high-value actions. It also removes the throughput that motivated automation, so it tends to be applied narrowly and then quietly widened. - **Application-level conditionals** written by the same team that ships the agent are real controls, but the auditor's question is not whether they exist. It is whether they were in force at the moment of action and could not be bypassed. - **Post-hoc logging** records what the agent did. It cannot record what the agent was prevented from doing, because nothing prevented anything. There is a more precise way to state the problem, and the guidance states it without meaning to. The IIA's segregation-of-duties guidance contemplates the case where a single system module performs both authorisation and execution, and offers supervisory review of exception reports as the remedy — **where the supervisory review is understood to be performed by a person holding independent authority, not by a second algorithm** [8]. The assumption is reasonable and almost invisible, because until recently there was no other kind of checker available. **That assumption is the thing an autonomous agent breaks.** Not the rule. The rule survives intact. What fails is the unstated premise that somewhere in the loop there is a party with independent authority who is not the party being checked. The liability position is not ambiguous while this is unresolved. In *Moffatt v. Air Canada* (2024 BCCRT 149) the airline argued that its website chatbot was a separate legal entity responsible for its own statements. The tribunal rejected the argument and held the company to what its software said [1]. Platform and model providers disclaim execution liability in their standard enterprise terms. **The deploying organisation carries the exposure, and currently carries it without an insurance backstop.** ## 4. What the Auditor Actually Asks For The question that decides an ITGC or application-controls test is narrower than it first appears, and it is not "is there a log?" It is closer to this: Show me that the control was in force at the time of the transaction, that this specific transaction passed through it, that it could not have been bypassed, and that the record you are showing me was not produced by the thing the control was constraining. That sentence contains four distinct requirements, and conventional agent tooling usually satisfies only the first two: - **Existence.** The control is documented and configured. Easy to evidence; usually a screenshot or a policy file. - **Coverage.** This transaction went through it. Evidenced by sampling a population of records. - **Non-bypassability.** There was no path around it. The IIA's application-controls guidance puts this as verifying that the control is *in the production path* and cannot be circumvented [9]. Hard to evidence with application code, because the same team can deploy a change; hard to evidence with a system prompt, because the model can decline to follow it. - **Independence of the record.** The evidence was not written by the party being examined. ISACA's guidance is direct about this: where the log is stored in the same system that performed the control, the auditor must assess whether the log could have been manipulated, and must therefore test the integrity of the logging mechanism itself [6]. This is the requirement that separates a log from a record with **non-repudiation** properties, and it is the one most often skipped. The gap between requirement 1 and requirement 4 is the whole subject of this note. It is the difference between *evidence that a control was configured* and *evidence that a control operated* — a distinction that ISACA's audit guidance already draws explicitly, requiring a system-generated entry showing the control executed at the moment of the transaction, with an outcome [6]. **Auditors already have this vocabulary. It is not something the AI industry needs to invent, and the industry would do better to adopt it than to replace it.** The same standards also allow an auditor to test an automated control's operating effectiveness by examining system-generated data, while still requiring that the evidence be sufficient and appropriate to support the opinion [7]. Where the automated control is the only check on an autonomous agent's action, evidence produced by that agent about itself does not meet the independence the test assumes. ## 5. Three States of a Control It is useful to grade a control on what it leaves behind, because the three states look identical in a design document and behave completely differently under examination. **Documented.** The rule is written down. Policy says the agent must not issue a payment above a threshold without approval. Nothing technically prevents it. Evidence available: the policy. This satisfies requirement 1 only. **Enforced.** The rule is executed by software that sits between the decision and the action, and the action does not occur when the rule refuses. Evidence available: the code, plus whatever the system chose to log. This satisfies requirements 1 to 3, and fails 4 when the enforcing system is operated by, and its records are writable by, the party being examined. **Evidenced.** The rule is enforced, and each decision — permission and refusal alike — produces a record that a third party can verify without access to the operating system, and which cannot be silently altered afterwards without the alteration being detectable. This is the state that answers all four requirements, and it is the state that **continuous controls monitoring** and **chain of custody** vocabulary is reaching for. Note what changes between the second and third states. Nothing about the agent improves. What changes is that the control's operation becomes examinable by someone who was not present and does not have to take anyone's word for it. ## 6. Who Already Owes This Duty Sectors that keep records of automated actions are not doing so voluntarily, and the duty predates autonomous agents by decades. Financial services record-keeping and algorithmic-trading control rules require firms to be able to reconstruct the order of decisions and to demonstrate that pre-trade controls were not bypassed [2][3]. Model risk management guidance in banking requires documented boundaries and effective challenge for models used in decisions [4]. Regulated manufacturing and clinical records rules require that automated system steps follow a predetermined sequence, with audit trails that the operator cannot quietly rewrite [5]. None of those rules mention AI agents, and none of them need to. They are drafted in terms of automated systems and records, and an agent is an automated system. **The obligation already applies; what has changed is that the systems now being deployed under it cannot produce the evidence it assumes.** This is also why the buyer for this problem is often not the team that deployed the agent. It is the person who has to sign that the controls operated: an internal audit lead, a risk officer, a controls owner preparing for an external audit. ## 7. The Instrument, and a Test Anyone Can Run AgenticRail is one implementation of the third state. It sits in front of the agent as a separate service. Each step is submitted before it runs and returns **ALLOW** or **DENY**. A denied step does not execute. Both outcomes produce a receipt signed with Ed25519, and each receipt carries the content hash of its predecessor, so removing or altering one leaves a detectable break in the chain. A sequence is sealed at its final step and cannot afterwards be reopened without that break becoming visible. The part that matters for requirement 4 is that verification does not require us. Each receipt is published with the exact byte string that was signed, so anyone holding the public key can verify it offline, with no call back to our infrastructure. The public keys are at [/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json). **The five-minute test.** Take any system that claims to control an AI agent, including this one, and ask for three things: a record of a step that was *refused*, not merely one that succeeded; the exact bytes that were signed, so the signature can be checked independently; and a demonstration that removing one record from the middle of a sequence is detectable. A system that cannot produce the first has logging rather than enforcement. A system that cannot produce the second is asking to be trusted rather than verified. Our verification tool is at [report.agenticrail.nz/report](https://report.agenticrail.nz/report) and the specification is at [/spec/](https://agenticrail.nz/spec/). ## 8. A Deliberate Boundary — what this does not do This section exists because a controls note that only lists strengths is marketing. Every limit below is a real one. - **It is not a compliance certification and does not make anyone compliant with anything.** No rule named in §6 is satisfied by installing software. They are satisfied by an organisation's controls, of which a gate is at most one. - **We hold no SOC 2 Type II report and no ISO 27001 or ISO 42001 certification**, and we claim none anywhere. For procurement in many regulated environments that is a genuine barrier, and we would rather state it here than have it discovered later. - **A receipt does not prove the decision was right.** It establishes that a step was permitted, in a declared order, at a known position in a chain. If the rule itself was wrong, the receipt faithfully records a wrong thing being permitted. What it does is narrow a dispute from *what happened* to *whether the rule was correct*. - **The timestamp is signed but self-asserted, and the remedy is known and not built.** The signature covers the time value, so it cannot be altered afterwards without breaking verification. It does not establish that the value is true, because we generate it: it is a record of when, not proof of when. The established answer is a timestamp token from an independent Time Stamping Authority under RFC 3161, which anchors the record in time against a party with no stake in it. **We have not implemented that.** Anyone weighing this record as evidence should treat the time as unattested until we do. - **The service is hosted, and we hold the signing keys.** This is the limit that matters most and it deserves stating without softening. A signature proves that a record has not been altered since signing, and that it came from the holder of the key. **It does not prove that an independent party witnessed the event.** Where the key is held by the party relying on the record, the honest description is that the record is strong on integrity and weak on independence — a motivated insider with key access could in principle produce a consistent but false history. Separately held copies of sealed receipts narrow that; hardware-held keys with logged signing operations would narrow it further. Neither eliminates it. Take "cryptographically signed" as the beginning of the question rather than the end of it. - **A gate constrains order and permission, not reasoning.** The agent still decides what to do within a step. It cannot skip a step, reorder steps, or replay one. If your process genuinely has no order worth enforcing, this is not the tool for it. ## 9. References - *Moffatt v. Air Canada*, 2024 BCCRT 149 (British Columbia Civil Resolution Tribunal). Published decision; includes the transcript of the exchange. - US Securities and Exchange Commission, Rule 17a-4 — records to be preserved by certain exchange members, brokers and dealers. - MiFID II Regulatory Technical Standard 6 (Commission Delegated Regulation (EU) 2017/589) — organisational requirements for investment firms engaged in algorithmic trading, including records of orders and pre-trade controls. - Board of Governors of the Federal Reserve System / OCC, Supervisory Letter SR 11-7 — Guidance on Model Risk Management. - US Food and Drug Administration, 21 CFR Part 11 — Electronic Records; Electronic Signatures. - ISACA — COBIT governance and management objectives, and the CISA Review Manual, on testing automated controls: configuration versus operation, compensating controls where segregation of duties cannot be fully achieved, and assessing the integrity of a log held in the system that performed the control. - Public Company Accounting Oversight Board, AS 2201, *An Audit of Internal Control Over Financial Reporting That Is Integrated with An Audit of Financial Statements* — compensating controls for a lack of segregation of duties, and the use of system-generated data as evidence of operating effectiveness. - Institute of Internal Auditors, Global Technology Audit Guide 13, *Auditing for Segregation of Duties* — segregation-of-duties conflicts arising where a single system module performs both authorisation and execution, and the compensating controls contemplated. - Institute of Internal Auditors, Global Technology Audit Guide 8, *Auditing Application Controls* — verifying that an application control sits in the production path and cannot be bypassed. - IETF RFC 3161, *Internet X.509 Public Key Infrastructure Time-Stamp Protocol* — trusted timestamp tokens from an independent Time Stamping Authority. - AgenticRail enforcement specification and receipt schema — [agenticrail.nz/spec/](https://agenticrail.nz/spec/). Document Fingerprint — SHA-256 — v1.0 09a254da2a0a831f21d5da04202270d51d48158c651e6b4c94b9021c39b04968 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):** `Segregation of Duties When the Agent Is Both Maker and Checker|1.0|2026-08-04|TUARA KURI LIMITED|segregation of duties maker-checker four-eyes principle predates the technology|autonomous agent with tool access is maker and checker in one process|compensating controls named by ISACA PCAOB and IIA are all detective and all performed after the transaction|IIA GTAG 13 supervisory review assumes a person with independent authority not a second algorithm|the rule survives what fails is the unstated premise of an independent party|four requirements existence coverage non-bypassability independence of the record|GTAG 8 control must be in the production path and not bypassable|ISACA a log held in the system that performed the control must have its integrity tested|configuration is not evidence of operation|three states documented enforced evidenced|Moffatt v Air Canada 2024 BCCRT 149 deployer carries the exposure without an insurance backstop|existing duties SEC 17a-4 MiFID II RTS 6 SR 11-7 21 CFR Part 11 COBIT ITGC|refused step must leave a record not only the permitted one|no SOC 2 no ISO 27001 no ISO 42001 claimed|timestamp signed but self-asserted RFC 3161 trusted timestamp is the known remedy and is not built|hosted service signing keys held by operator strong on integrity weak on independence|receipt narrows dispute from what happened to whether the rule was right|report.agenticrail.nz` Published: 2026-08-04 | Version: 1.0 | Entity: TUARA KURI LIMITED **Sourcing note:** §2, §3 and §4 cite published audit-profession guidance (ISACA, PCAOB AS 2201, IIA GTAG 8 and 13) for what the standards say about compensating controls and about testing automated controls. §6 names existing record-keeping and control duties as examples of obligations that already apply to automated systems. It does not assert that any named rule requires this product, and it does not assert compliance with any of them. The limits in §8 are stated in full rather than summarised. --- # NCEA Is Being Replaced. What Will Assure Internal Assessment? > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/spec/nzce-internal-assessment/ > Site context: https://agenticrail.nz/llms.txt **Document type** Sector Note — Evidence Brief **Subject** Assurance of internal assessment under the qualifications replacing NCEA **Published by** TUARA KURI LIMITED — trading as AgenticRail, Hokianga, Aotearoa New Zealand **Date** 2026-07-26 **Version** 1.1 **Status** Published — open for citation **Related** When the Marker Is a Machine · If AI Detectors Don't Work, What Does? · AI in New Zealand Education Assessment # NCEA Is Being Replaced. What Will Assure the Internal Assessment in Every Subject? The qualifications replacing NCEA were confirmed on 16 May 2026. Every subject will carry internal assessment alongside an examination, and every subject will be graded on a single six-point scale. Internal assessment therefore does not shrink under the new system — it becomes universal, and the grade it contributes to becomes directly comparable between students, schools and years. How that layer will be moderated has not been published; the government's own next-steps release lists moderation and comparability among topics for future consideration. This note documents that gap as a design window, while the design is still open, and while the first cohort is in Year 9. ## 1. Scope This is a sector note. It confers no compliance, proposes no policy, and asserts no failure by any agency, school, or teacher. It states what has been publicly confirmed, what follows from it structurally, and what has not yet been specified. Where something is undecided, that is described as undecided — not as an omission. The distinction used throughout is the one used in the companion notes: a **record** is any account that a required step occurred, and may be self-attested and revisable; **evidence** is a record created at the time of the step, sealed against later alteration, and checkable by someone who does not have to trust the institution that produced it. ## 2. What has been confirmed The following are direct quotations from the government's own releases, cited in §9. **2.1 — The qualifications.** The replacement is "the New Zealand Certificate of Education (NZCE) at Year 12 and the New Zealand Advanced Certificate of Education (NZACE) at Year 13" [1]. **2.2 — The assessment structure.** "Every subject will include internal assessments and an examination, with the weighting of the examination varying depending on the curriculum area and the nature of the subject" [1]. The Ministry's detailed page uses a different word for the same component: "Each subject will include a combination of **coursework** and at least one exam, with most students completing three to four assessments per subject each year" [9]. *Coursework* and *internal assessment* refer to the same portion; both terms are used in this note where the source uses them. **2.3 — The grading scale.** "A six-point grading scale from A+ to E for every subject" [1]. **2.4 — The cohort and timing.** Science becomes compulsory in Year 11 from 2028, and "today's Year 9 students will be the first cohort to progress through these changes" [1]. The staged programme has curriculum and assessment exemplars finalised through 2026, a preparatory year of assessment and professional learning in 2027, NCEA Level 1 removed and the Foundational Award beginning in 2028, the new Year 12 qualification in 2029, and the new Year 13 qualification in 2030 [2]. **2.5 — A promise of nationwide consistency.** "Assessment will be consistent nationwide, meaning students taking the same subject will be assessed in the same way, regardless of where they attend school" [9]. This is a specific, public commitment, and §3.4 returns to what would be required to evidence it. **2.6 — What the published sources do not contain.** The 16 May 2026 release confirming the structure contains no information about moderation, quality assurance, comparability, or consistency of internal assessment [1]. The earlier next-steps release identifies "moderation, comparability, and complex decisions" as matters for future consideration ahead of Budget decisions [2]. The Ministry directs readers seeking "full details of the new qualifications, including details about recognition of achievement, enrolment requirements, assessment, grading and transitional arrangements" to its Tāhūrangi page [3]; that page, read in full, likewise contains no mention of moderation, quality assurance, verification, or authenticity, and does not use the terms *internal assessment* or *external assessment* at all [9]. This is stated as a fact about the published record, not as a criticism: a design that has not been announced is a design that is still being made. ## 3. What follows structurally The consequence of §2.2 Because every subject will include internal assessments *and* an examination, two things follow directly from the quoted sentence. No subject will be assessed entirely externally, and no subject will be assessed entirely internally. Internal assessment stops being a proportion that varies by subject — substantial in some, absent in others — and becomes a component present in every subject every student takes. Under the current system, schools carry out approximately three-quarters of NCEA assessment internally [4], concentrated unevenly. Under the new structure that layer is not reduced; it is made universal and given a floor in every subject in the country. **3.1 — Comparability raises the stakes on consistency.** A six-point A+ to E grade per subject [1] is directly comparable between students, between schools, and between years, in a way that a profile of achieved standards is not. Comparability is the property that makes a qualification useful to a university, an employer, or the student holding it. It is also the property that makes any inconsistency in how internal assessment was marked or moderated immediately visible and immediately contestable — because two students with different grades in the same subject now have a single number to compare, and a reason to ask how each was arrived at. **3.2 — The examination component does not carry the internal one.** An examination assures the examination. It provides no information about whether the internally assessed portion of the same subject was marked consistently, moderated as required, or verified as the student's own work. Where the two components combine into one grade, the assurance of the whole is bounded by the assurance of the weaker part. **3.3 — The timing collides with the arrival of automated assistance.** Automated marking is already in national production for digitally submitted writing assessments, and the qualifications authority has publicly named moderation support for internally assessed work among its planned artificial-intelligence tools [5]. The moderation layer is therefore being scaled up in scope, raised in stakes, left open in design, and prepared for automated assistance, in the same period. Each of those is defensible on its own. Together they describe a layer that will be carrying more weight than it ever has, with its assurance mechanism specified last. **3.4 — The consistency promise names the thing that needs evidencing.** Assessment being "consistent nationwide," such that "students taking the same subject will be assessed in the same way, regardless of where they attend school" [9], is straightforward for the examination component: one paper, one marking operation, one set of markers. For the coursework component it is a different proposition, because that work is set and marked in each individual school. The mechanism by which coursework marking is made consistent between schools is moderation — and moderation is the element not addressed in any of the published sources in §2.6. This is the point of the whole note, and it is worth stating without hedging. A commitment to nationwide consistency is a commitment about the coursework in every subject in every school. Whether it holds is not a matter of intent; it is a matter of whether the moderation that delivers it can be shown to have happened, subject by subject and school by school, to someone outside the school. A promise of consistency and a record capable of demonstrating consistency are different things, and only the first currently exists. ## 4. The same change is happening in the tertiary system The pattern is not confined to schools, which is worth noting because it suggests a design decision rather than a local gap. The Academic Quality Agency, which conducted external academic audit of New Zealand universities, was disestablished at the end of 2024 [6]. Its successor body, Matatāhuna — the Universities Quality Assurance Agency — was established on 12 March 2026, operationally independent in the conduct of its quality assurance activities [7]. The Committee on University Academic Programmes is scheduled to cease by the end of 2027, with implementation of audited self-accreditation targeted for 2028 [7]. Under audited self-accreditation, an institution carries the risk for the compliance of its own approval processes, and an auditor arriving afterwards examines the institution's account of what it did. That is the same structure as a school retaining its own evidence of internal moderation: workable when the account is trusted, and difficult precisely when it is not. Both systems are moving, in the same window, toward arrangements in which more of the assurance rests on records held by the party being assured. ## 5. The window The reason to write this now rather than in 2029 is specific. Assessment exemplars are being finalised in 2026 and a preparatory year runs through 2027 [2]. An evidence format specified while a system is being designed costs a fraction of one retrofitted onto a system already in operation, and the regulatory plumbing is itself being rebuilt in the same period: regulatory functions for early childhood education licensing and certification, private schools, and school hostels transfer from the Ministry of Education to the Education Review Office by 1 November 2026, under a new Director of Regulation [8]. That transfer does not cover assessment or qualifications, which remain with NZQA. It matters here for a narrower reason — a compliance regime being designed in the open in the same window has to answer the same question about what a record of a completed regulatory step must contain. Two properties make this cheap to specify now and expensive to add later. It is a *format* question, not a platform question — what a record of a completed moderation step must contain and how it must be sealed, which any vendor can then implement. And it is *additive* — it does not change what a teacher does, only what is written down when they do it. ## 6. What such a layer would need to be The requirements are specified neutrally, and independently of any vendor, in the companion [Completeness Specification](https://agenticrail.nz/spec/completeness/). Four are load-bearing for this purpose. | Property | Why it matters for a universal internal-assessment layer | | **Written at the moment of the step** | Retained paperwork assembled later cannot establish that moderation preceded the result rather than followed a question about it. | | **Independent of the system being recorded** | If the school's own system records whether the school moderated, the account and its subject are the same party. | | **Signed and verifiable offline** | An appeals process, a review office, or a student can confirm the record against a published key without the institution's cooperation. | | **Sealed at completion** | Once a result is reported, the account of how it was reached is fixed, and later alteration is detectable rather than silent. | Applied to a subject under NZCE or NZACE The declared sequence for the internally assessed component of a subject already exists in outline: task issued, work submitted, authenticity verified, marked, internally moderated, result recorded — with external moderation sampling across schools. Each step writes a signed receipt at the moment it occurs, chained to the previous one, and the sequence seals when the result is reported. The receipts record that a step happened, by whom and when, not the content of the student's work. A school's claim to have moderated becomes checkable rather than merely retained; a student contesting a grade is answered from a record rather than a recollection; and a school that did the work properly can show it, which is the protection running in the other direction. `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 — including one built under a procurement already under way — can be assessed against the same requirements. ## 7. What this does not do **Each of the following states something true, followed by its limit.** **A record establishes that the required steps occurred in order. It does not establish that the marking was correct.** Consistency of judgement between markers is a real and separate problem, addressed by exemplars, training and moderation itself. A receipt witnesses that moderation happened; it does not make the moderator right. **The record narrows a dispute to the thing worth disputing.** If a standard or a marking rule is itself flawed, faithful execution produces accurate receipts of a flawed rule being applied. The argument then moves from "what happened" to "was the rule right," which is the argument the sector should be having. **Tamper detection has a boundary.** A sealed, chained record makes later alteration detectable. Detectable is not impossible: a party holding the signing keys could construct a consistent but false chain. What closes that gap is custody — a copy held by a party who is not the institution — not stronger cryptography. **This note proposes no policy and takes no position on the qualifications themselves.** Whether NZCE and NZACE are the right replacement, what the exam weighting should be, and how subjects should be structured are questions for the sector, the profession, and the people who will hold the qualifications. The argument here is narrower and holds whichever way those are decided: whatever the internal component turns out to be, its assurance should be checkable by someone outside the institution producing it. **Nothing here asserts that any school, teacher, or agency has failed a duty.** The materials this note relies on are public because the agencies concerned published them, and the moderation design is unspecified because it is still being made. ## 8. How to check every claim on this page Every quotation in §2 is taken verbatim from the government releases cited in §9, and the tertiary material in §4 from the bodies' own announcements. The claims about the instrument can be checked directly: - Run the [live demo](https://agenticrail.nz/demo/). It executes a real multi-step sequence against the production gate and returns a sequence identifier. - Paste that identifier into the [verification tool](https://report.agenticrail.nz/report). It returns every receipt with its raw signature and the exact bytes that were signed. - 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, with no call back to the operator. If a claim on this page does not match the live system, the live system is the authority and the page is wrong. ## 9. References [1] Beehive.govt.nz, "Details of NCEA replacement confirmed," 16 May 2026 — [beehive.govt.nz](https://www.beehive.govt.nz/release/details-ncea-replacement-confirmed) [2] Beehive.govt.nz, "Government confirms next steps on new senior secondary qualification" — [beehive.govt.nz](https://www.beehive.govt.nz/release/government-confirms-next-steps-new-senior-secondary-qualification) [3] Ministry of Education, "More details about new senior secondary qualifications" (directs readers to Tāhūrangi for full assessment detail) — [education.govt.nz](https://www.education.govt.nz/news/more-details-about-new-senior-secondary-qualifications) [4] 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) [5] NZQA, "NZQA's Responsible Use of Artificial Intelligence," September 2025 — [nzqa.govt.nz](https://www2.nzqa.govt.nz/about-us/news/nzqas-responsible-use-of-artificial-intelligence/) [6] Academic Quality Agency for New Zealand Universities — [aqa.ac.nz](https://www.aqa.ac.nz/) [7] Universities New Zealand, "Matatāhuna — Universities Quality Assurance Agency established," 12 March 2026, and "Quality assurance" — [universitiesnz.ac.nz](https://www.universitiesnz.ac.nz/quality-assurance) [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] Ministry of Education, Tāhūrangi, "Further details confirmed for new senior secondary qualifications replacing NCEA," 16 May 2026 — [tahurangi.education.govt.nz](https://tahurangi.education.govt.nz/senior-secondary-quals-finalised) [10] RNZ, "Government confirms NCEA replacement details" — [rnz.co.nz](https://www.rnz.co.nz/news/political/595424/government-confirms-ncea-replacement-details) [11] Companion note — [When the Marker Is a Machine](https://agenticrail.nz/spec/ai-marked-assessment/), on evidence for decisions in which an automated system did the marking. [12] Companion brief — [AI in New Zealand Education Assessment: The Missing Evidence Layer](https://agenticrail.nz/spec/nzqa-nz-education/), on the statutory basis and the current internal moderation cycle. Document Fingerprint — SHA-256 — v1.0 (superseded by v1.1 below) 8b89c419696571f9d1ef86b05bcf77547ecc6f49e0af9590c8631a89c331024a 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):** `NCEA Is Being Replaced What Will Assure the Internal Assessment in Every Subject|1.0|2026-07-26|TUARA KURI LIMITED|New Zealand Certificate of Education NZCE at Year 12 and New Zealand Advanced Certificate of Education NZACE at Year 13 confirmed 16 May 2026|every subject will include internal assessments and an examination with examination weighting varying by curriculum area|six-point grading scale from A plus to E for every subject|today's Year 9 students are the first cohort exemplars finalised 2026 preparatory year 2027 Year 12 qualification 2029 Year 13 2030|the 16 May 2026 release contains no information about moderation quality assurance comparability or consistency of internal assessment|the next-steps release lists moderation comparability and complex decisions as matters for future consideration|no subject assessed entirely externally and no subject assessed entirely internally internal assessment becomes universal|currently approximately three quarters of NCEA assessment is carried out internally|comparability raises the stakes on consistency a single letter grade invites comparison between students schools and years|an examination assures the examination the assurance of the whole is bounded by the assurance of the weaker part|automated marking already in national production and moderation support for internally assessed work named as a planned tool|tertiary parallel AQA disestablished end of 2024 Matatahuna established 12 March 2026 CUAP ceases end of 2027 audited self-accreditation targeted 2028|a format question not a platform question and additive to what a teacher already does|record establishes the steps occurred in order not that the marking was correct|tamper detection is detectable not impossible custody closes the gap not cryptography|completeness R1-R8|report.agenticrail.nz` Published: 2026-07-26 | Version: 1.0 | Entity: TUARA KURI LIMITED **Sourcing note:** every quotation in §2 is verbatim from the government releases cited in §9. This note asserts no failure, breach, or bad faith by any agency, school, or teacher, proposes no policy, and names no individuals. Document Fingerprint — SHA-256 — v1.1 2cd13d57370734ef12276e4099c43c194432092f39788ce3263ec8fbaf279c3c 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):** `NCEA Is Being Replaced What Will Assure the Internal Assessment in Every Subject|1.1|2026-07-26|TUARA KURI LIMITED|New Zealand Certificate of Education NZCE at Year 12 and New Zealand Advanced Certificate of Education NZACE at Year 13 confirmed 16 May 2026|every subject will include internal assessments and an examination with examination weighting varying by curriculum area|the Ministry's detailed page calls the same component coursework a combination of coursework and at least one exam three to four assessments per subject each year|six-point grading scale from A plus to E for every subject|today's Year 9 students are the first cohort exemplars finalised 2026 preparatory year 2027 Year 12 qualification 2029 Year 13 2030|assessment will be consistent nationwide students taking the same subject will be assessed in the same way regardless of where they attend school|the 16 May 2026 release contains no information about moderation quality assurance comparability or consistency of internal assessment|the Tahurangi detail page contains no mention of moderation quality assurance verification or authenticity and does not use the terms internal assessment or external assessment|the next-steps release lists moderation comparability and complex decisions as matters for future consideration|no subject assessed entirely externally and no subject assessed entirely internally internal assessment becomes universal|currently approximately three quarters of NCEA assessment is carried out internally|comparability raises the stakes on consistency a single letter grade invites comparison between students schools and years|an examination assures the examination the assurance of the whole is bounded by the assurance of the weaker part|consistency is straightforward for the examination and a different proposition for coursework set and marked in each school|the mechanism that makes coursework marking consistent between schools is moderation which is the element not addressed in any published source|a promise of consistency and a record capable of demonstrating consistency are different things and only the first currently exists|automated marking already in national production and moderation support for internally assessed work named as a planned tool|tertiary parallel AQA disestablished end of 2024 Matatahuna established 12 March 2026 CUAP ceases end of 2027 audited self-accreditation targeted 2028|a format question not a platform question and additive to what a teacher already does|record establishes the steps occurred in order not that the marking was correct|tamper detection is detectable not impossible custody closes the gap not cryptography|completeness R1-R8|report.agenticrail.nz` Published: 2026-07-26 | Version: 1.1 (supersedes v1.0) | Entity: TUARA KURI LIMITED **v1.1 (2026-07-26):** adds the Ministry's own Tāhūrangi detail page as a checked source (§2.6) and its *coursework* terminology (§2.2); adds the published commitment that assessment "will be consistent nationwide" (§2.5) and §3.4, which sets out that consistency is straightforward for the examination and a different proposition for coursework set and marked in each school, that the mechanism delivering it is moderation, and that a promise of consistency and a record capable of demonstrating consistency are different things. The canonical string above carries those tokens, so this fingerprint supersedes the v1.0 hash `8b89c419696571f9d1ef86b05bcf77547ecc6f49e0af9590c8631a89c331024a`. **Sourcing note:** every quotation in §2 is verbatim from the government sources cited in §9. This note asserts no failure, breach, or bad faith by any agency, school, or teacher, proposes no policy, and names no individuals. --- # What Makes an AI Enforcement Record Evidence-Grade, Not Just a Log? > Markdown mirror for AI agents, generated 2026-08-12 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. ### What an auditor tests, and which requirement answers it An auditor rarely asks for "an audit log". They test a record against a small number of named criteria. The eight requirements above map onto those criteria directly, and the mapping is set out here so that a reader arriving with an auditor's checklist can find the corresponding requirement without having to translate vocabulary. | What the auditor tests | Requirement | | **Completeness** — every material action is captured, including the ones that were refused, not only the ones that succeeded. | R1, R6, R8 | | **Tamper-evidence** — the record cannot be altered after the fact by the system that produced it without the alteration being detectable. | R3, R7 | | **Traceability** — a given entry maps to a specific step in the documented process, rather than to an undifferentiated stream of events. | R6, R7 | | **Independent generation** — the evidence is a byproduct of the system running, generated outside the component under examination, rather than assembled afterwards by the party being audited. | R1, R4 | | **Timestamping and retention** — times are bound into the signed record and the record persists for a stated period. | R3, R5 for timestamping; retention is not specified here | Two of these warrant a caution rather than a claim. **Independent generation** is satisfied with respect to the agent, which can neither instruct the gate nor edit its output; it is not satisfied with respect to the operator of the gate, and no requirement in this specification asserts otherwise. **Timestamping** means the recorded time is bound into the signed record and cannot be altered afterwards without breaking verification; it does not establish that the recorded time is true, because that value is asserted by the recording system itself. Retention is a matter of an operator's policy and this specification takes no position on it. ## 6. Reference Implementation — slp8_receipt_v2 The `slp8_receipt_v2` receipt schema is offered as one conformant, evidence-grade reference implementation of this specification. It is named here as the author's own implementation; it is not the only possible one, and this specification is implementation-independent. | Requirement | Reference mechanism | | **R1** Pre-execution mediation | Enforcement gate evaluates every step before the agent acts; the air-gapped core is unreachable by the agent. `DENY` receipts record refused actions that never executed. | | **R2** Deterministic decision | Policy evaluation over a fixed policy map; no sampling. Same payload yields the same decision. | | **R3** Signed, offline-verifiable | Ed25519 signature over canonical JSON of the receipt; verifiable against the published keyring at [/spec/receipt-public-keys.json](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`. A sealed sequence cannot be reopened without leaving a detectable break in the `prev_receipt_hash` chain. | | Property | Value | | **Schema** | `slp8_receipt_v2` — JSON Schema Draft 2020-12, [/spec/receipt-schema.json](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 (superseded by v1.3 below) 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`. The v1.0, v1.1 and v1.2 fingerprints above are permanent and unchanged. v1.3 adds the auditor-criteria mapping in §5, which introduces no requirement and changes none, and corrects the §6 Reference Implementation table's R8 row. That row stated that no unsealing mechanism exists. This was stronger than the evidence supports: what holds is that a sealed sequence cannot be reopened without leaving a detectable break in the `prev_receipt_hash` chain, and that a full downstream rewrite by a holder of the signing key is caught by an independently held copy rather than by the chain alone. The abstract R8 requirement in §3 is unchanged and the `R8:irreversible sequence sealing` canonical token is unchanged, so the requirement vocabulary is stable across all four versions. No earlier version is edited; v1.3 is a separate, independently-fingerprinted record. Document Fingerprint — SHA-256 — v1.3 918786395e500decd88b9b1b5724a3748894892d17133285dc2f242511ee5672 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.3|2026-08-12|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-08-12 | Version: 1.3 (supersedes v1.2, 2026-07-08) | Active key ID: k2_2026-06-07_ed25519 **v1.3 (2026-08-12):** the R1–R8 abstract requirements and canonical tokens are unchanged from v1.2 — only the version and date tokens differ. §5 gains an auditor-criteria mapping and §6's R8 row is corrected from an absolute claim to a detectability claim. This fingerprint supersedes the v1.2 hash `2da590a70624c2de7b2edbe568ee5c74f482d65b405374debebad3f6f34efbb5`. --- # What's Missing From AI Safeguards in New Zealand Health Care? > Markdown mirror for AI agents, generated 2026-08-12 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 Happened? > Markdown mirror for AI agents, generated 2026-08-12 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 regulatory functions for early childhood education licensing and certification, private schools, and school hostels from the Ministry to the Education Review Office, and creates a Director of Regulation within it. Transfer to be complete by 1 November 2026. Assessment and qualifications are not part of this transfer; they remain with NZQA. | A compliance regime is being designed in the open right now. The evidence question it answers for its own sectors — what a record of a completed regulatory step must contain, and whether that record is assertable or independently checkable — is the same question assessment moderation faces under a different authority. The choice between the two is cheapest before a process sets. | | **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. How to check every claim on this page Every factual claim in §§2–5 is cited below to a primary or named public source. The claims about the instrument can be checked directly, without contacting anyone: - Run the [live demo](https://agenticrail.nz/demo/). It executes a real multi-step sequence against the production gate and returns a sequence identifier. - Paste that identifier into the [verification tool](https://report.agenticrail.nz/report). It returns every receipt, each with its raw signature and the exact bytes that were signed. - 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, with no call back to the operator. If a claim on this page does not match the live system, the live system is the authority and the page is wrong. ## 9. 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/) [10] Companion brief — [NCEA Is Being Replaced: What Will Assure the Internal Assessment in Every Subject?](https://agenticrail.nz/spec/nzce-internal-assessment/), on the qualifications confirmed 16 May 2026, under which internal assessment becomes universal and every subject is graded on one comparable scale. [11] Companion brief — [When the Marker Is a Machine](https://agenticrail.nz/spec/ai-marked-assessment/), on automated marking already in national production and what a record of the marking step would have to establish. [12] Companion brief — [If AI Detectors Don't Work, What Does? Authenticity by Process Record](https://agenticrail.nz/spec/assessment-authenticity/), on why detection software is unsuitable as a sole means of assuring authenticity, and what a process record establishes instead. 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 §9, 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-08-12 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 and DENY recorded per action before execution. Ed25519-signed receipt written to tamper-evident 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 or modify the declared step-order policy without the model's cooperation or awareness. The authority is unconditional and does not require the model to stop itself. Once a key is revoked, every subsequent request is refused at the boundary and the sequence cannot advance, regardless of what the model attempts. A boundary refusal returns HALT and produces *no* receipt, because nothing reached enforcement to be recorded — the evidence is the key log together with a receipt chain that stops at the last enforced step. **Manage 2.4 evidence available:** Key issuance and revocation log (who holds gate access, when granted, when revoked). The signed receipt chain, which stops at the last enforced step. 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 or DENY — and an Ed25519-signed receipt written to 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, 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 a Deterministic Enforcement Gate Decide ALLOW, DENY, or HALT? > Markdown mirror for AI agents, generated 2026-08-12 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 responses. No other outputs exist. Permitted ALLOW Refused DENY Request rejected HALT ALLOW and DENY are the enforcement decisions; HALT is a rejection at the boundary, returned when a request is refused before enforcement runs. Every enforcement 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. A HALT produces no receipt, because nothing reached enforcement to be recorded. 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, tamper-evident 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 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** or **DENY** — the two enforcement decisions, same receipt shape for both. **HALT never appears in this field.** A HALT is a rejection at the boundary before enforcement runs, so no receipt is written at all. Reconciling receipts against calls will show no receipt for a HALTed call: that is correct, not a gap. | | `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. ## 17. When the Marker Is a Machine — Evidence for AI-Assisted Assessment Decisions New Zealand marks national writing assessments with automated scoring, quality assured by human check-marking concentrated at the achievement boundaries. This note asks what evidence supports a single result when it is challenged. Its central distinction: an **agreement rate is a property of a system measured across a population**, while **a challenge concerns one instance** — and an aggregate figure carries no information about any particular script. It also notes that where an automated tool assists *moderation* rather than marking, the assurance layer acquires the same property as the layer beneath it, and the chain terminates only at a record that does not depend on the account of the party being checked. Asserts no failure by any agency and names no individuals. [agenticrail.nz/spec/ai-marked-assessment/](https://agenticrail.nz/spec/ai-marked-assessment/) — what is already running, the four questions a challenge actually asks, the boundary-concentration point, the instrument, full references. Fingerprinted. Published 2026-07-26. ## 18. If AI Detectors Don't Work, What Does? — Authenticity by Process Record Three responses to generative AI in assessment are available: prohibit it, detect it, or record the process that produced the work. New Zealand has tried the first two at national scale and stated its reasoning publicly — detection has been withdrawn by three universities and ruled unsuitable as a sole means by national guidance, and reverting to supervised handwriting works while relocating the cost onto specific students. The note sets out why prohibition and detection share one structural weakness (both interrogate the finished artifact, which cannot reveal how it was made) and what changes when the object of examination is the sequence instead. Includes the measured bias of detectors against non-native English writers, cited to the peer-reviewed study. [agenticrail.nz/spec/assessment-authenticity/](https://agenticrail.nz/spec/assessment-authenticity/) — the three options, the documented withdrawal of detection, the artifact-versus-process comparison, the instrument, full references. Fingerprinted. Published 2026-07-26. ## 19. NCEA Is Being Replaced — What Will Assure the Internal Assessment? The qualifications replacing NCEA were confirmed on 16 May 2026: the New Zealand Certificate of Education at Year 12 and the New Zealand Advanced Certificate of Education at Year 13, with *"every subject will include internal assessments and an examination"* and a six-point A+ to E grade for every subject. Two things follow directly: no subject is assessed entirely externally, and none entirely internally — **internal assessment becomes universal** rather than shrinking. The note documents that the release confirming the structure contains no information about moderation, comparability or consistency of internal assessment, and that the earlier next-steps release lists those as matters for future consideration. It treats that as a design window while the design is open, not as a criticism, and covers the parallel shift to audited self-accreditation in the tertiary system. [agenticrail.nz/spec/nzce-internal-assessment/](https://agenticrail.nz/spec/nzce-internal-assessment/) — what has been confirmed, what follows structurally, the tertiary parallel, the window, the instrument, full references. Fingerprinted. Published 2026-07-26, amended to v1.1 the same day (adds the Ministry’s Tāhūrangi detail page as a checked source and the published commitment that assessment will be “consistent nationwide”). ## 20. Segregation of Duties When the Agent Is Both Maker and Checker — Controls Note Most writing about controlling AI agents invents new vocabulary for the problem. This note does the opposite, treating agent oversight as an **IT general controls** question rather than an AI safety question. Segregation of duties — **maker-checker**, the **four-eyes principle** — requires that the party authorising an action is not the party performing it. An autonomous agent with tool access is both, in one process. The note sets out the four things an auditor actually asks (existence, coverage, non-bypassability, and independence of the record), why a system prompt asking for confirmation is an instruction to the maker rather than a separate checker, and the difference between evidence that a control was *configured* and evidence that it *operated*. Grades a control in three states — documented, enforced, evidenced — and names the existing record-keeping duties that already apply to automated systems without mentioning AI at all. States its own limits in full, including the absence of SOC 2 and ISO certification and the key-custody question. [agenticrail.nz/spec/segregation-of-duties/](https://agenticrail.nz/spec/segregation-of-duties/) — the control that predates the technology, the failure shape, what the auditor asks, three states of a control, who already owes the duty, the instrument, the five-minute test, a deliberate boundary, full references. Fingerprinted. Published 2026-08-04. 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 > Markdown mirror for AI agents, generated 2026-08-12 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 sealed, so the account is fixed at the moment it happened and cannot be reopened without leaving a detectable break. ## Is this a guardrail? Partly, and the difference is worth being exact about. **Content guardrails** filter what a model says — toxicity, PII, jailbreaks — by reading the text. AgenticRail never reads content and does nothing about what a model writes. The second sense is closer: a rule about what an agent may *do*. Most implementations of that are advisory — the rule is described to the model in a prompt or a docstring, or checked by a second model — so a confident agent can reason its way around it, or simply not call the checker. AgenticRail is **runtime enforcement** in the strict sense. The check is a call made before the step runs, the verdict is computed by deterministic code rather than inferred by a model, and a DENY comes back the same way no matter how the agent argues for itself. The gate is a deterministic control plane sitting outside the model, so it cannot be persuaded, and it does not get more permissive under a longer context. The honest limit: this is enforcement *at the point of integration*. An action routed through the gate cannot proceed without a verdict, but a code path never wired to the gate is outside it. Where you place it matters far more than any setting in it. ## Is AgenticRail a policy enforcement point? Yes, in the standard meaning of the term. It sits in the path of the action, receives a proposed step, and returns permit or deny before that step executes. If your vocabulary comes from XACML or Zero Trust, the gate is the PEP and the published enforcement specification is the policy. Two differences from a classic PEP are worth knowing. First, a classic PEP evaluates each request **independently** — the same request gets the same answer whenever it arrives. AgenticRail's answer depends on the run: an identical call is ALLOW at the right point and DENY as a replay, out of order, or after the sequence is sealed. That is **deterministic sequencing**, and the state is the product rather than an optimisation. Second, a PEP normally writes its decision to a log or an observability pipeline. Here the decision becomes a signed, hash-chained receipt that verifies offline against a published key, so the enforcement record is evidence rather than an entry the operator could later edit. ## Is this "verifiable execution" or "proof of execution"? **No, and we would rather decline those terms than stretch them.** Both usually promise that the work itself ran correctly, often backed by a trusted execution environment or a proof over the computation. AgenticRail proves something narrower, and the field names say so: a receipt's `executed` means *the enforcement decision was ALLOW — the step was permitted*. It does not assert that the downstream action ran or succeeded. The executor's outcome is reported separately as `execution_submitted` and is deliberately **not** signed into the receipt. So what is provable here is the **decision and its order**: which steps were permitted, in what sequence, against an order declared in advance, each bound to a hash of the record. Whether a permitted action then did what it claimed is a question about your system, not ours — and a receipt that implied otherwise would be exactly the self-reporting problem this exists to remove. ## 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. ## Is there a public verifier anyone can use in a browser? Yes, and it is not only a browser tool. Open [report.agenticrail.nz/report](https://report.agenticrail.nz/report), paste a sequence ID, read the report — no account, no login, no sign-up, nothing to install. The same endpoint answers **any HTTP client, with no key at all**: a plain `urllib`, Java or Go request returns the full report, so a compliance script can pull it exactly as easily as a person can open it. Demo sequences are open to anyone, so the mechanism can be checked end to end without asking us for anything. The report gives you each receipt's raw Ed25519 `signature` alongside the exact `signed_canonical` preimage the signature was computed over, plus the `key_id`. That's deliberate: the browser tool is a convenience, not the proof. You are not asked to trust it. Take the preimage and the signature out of the report, run `ed25519_verify` against the published keys in your own code, and you never touch our servers again. The honest limits: fetching a report needs our infrastructure to be running, and reports for a client's own sequences require that client's key. ## 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. ## Does a receipt prove when something happened? It records when, and that time is signed into the receipt, so it cannot be changed afterwards without breaking verification. But AgenticRail generates the timestamp — the signature proves we asserted that time, not that the time is correct. It is not attested by an independent party. What a receipt does prove on its own is the order the steps ran in, that each receipt commits to the exact content of the one before it, and whether the sequence sealed. For sealed sequences the report also shows when a separately-held write-once archive received its copy, which corroborates the timing from a different system without being an attested timestamp. ## 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. ## Does AgenticRail work with LangGraph, CrewAI, or LangChain? Yes. The gate is a plain HTTPS JSON call made before each step, so it works with any agent framework and does not care which model or vendor produced the request. The Python SDK ships purpose-built integrations for **LangGraph** and **CrewAI**, with runnable examples for both. The JavaScript SDK covers **LangGraph.js**, Mastra, Genkit and custom loops. Agents that speak **Model Context Protocol** can call the gate directly through the MCP server at [mcp.agenticrail.nz](https://mcp.agenticrail.nz/), which exposes `evaluate_step` and `verify_receipt` as tools. There is nothing framework-specific in the enforcement itself: the framework decides what your agent wants to do next, and the gate decides whether it is allowed to do it. Integration detail is at [agenticrail.nz/docs/](https://agenticrail.nz/docs/), and the machine-readable API description is at [agenticrail.nz/openapi.json](https://agenticrail.nz/openapi.json). ## Can I run AgenticRail myself, and who holds the signing keys? AgenticRail is a hosted service today. There is no self-hosted build, and **AgenticRail holds the receipt signing keys**. That is the honest answer, and it matters, so here is precisely what it does and does not mean. Because every receipt ships with the exact preimage its signature was computed over, you never have to trust our verifier — you check signatures yourself, offline, in your own code, against published public keys. What key custody does affect is narrower: someone holding the signing key could in principle rewrite an entire chain and re-sign it, and the hash chain alone would not catch that. A second, write-once archive held under a different credential exists to catch exactly that rewrite, and every report compares against it. The residual we do not claim to have closed is the account owner, who can reach both stores. That is disclosed rather than hidden. Closing it does not require new engineering. It requires the archive, or the signing key, to be held by someone who is not us — an ordinary commercial arrangement with an established industry behind it: escrow agents, trustee corporations, qualified trust service providers, or your own law firm under a deed. **No such custodian is engaged today.** Which one holds it, and what conditions release it, is a term settled at deployment rather than a decision we make on your behalf. That is why there is no automatic key issue and why getting one starts with a conversation. ## Is AgenticRail SOC 2 or ISO 27001 certified? No. Neither, and no certification is claimed anywhere on this site. What exists instead is evidence a third party can check without taking our word for it: a published enforcement specification with every version frozen and fingerprinted, public verification keys, receipts that verify offline in your own code, and a documented adversarial test record. Those are different kinds of assurance and the difference is worth stating plainly. A certification attests that an organisation follows its stated processes, assessed periodically by an auditor. A receipt chain lets anyone check a specific claim about a specific sequence at any time, without trusting the organisation or the auditor. Certification is a reasonable thing for a buyer to require, and for some procurement it is mandatory. We do not have it, and we would rather say so than imply otherwise. ## How much does AgenticRail cost? There is no public price list and no self-serve sign-up. Pricing is set per deployment, because what an organisation takes on is a working reference deployment and the support to run it, not a number of seats. Evaluation costs nothing and needs no account: the public demo key works immediately, the verifier is open to anyone in a browser, and the enforcement specification, receipt schemas and public keys are all published. The mechanism can be tested end to end before any conversation about money. For a figure against a specific deployment, [hello@agenticrail.nz](mailto:hello@agenticrail.nz). **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 the Enforcement Gate Survived Under Attack? > Markdown mirror for AI agents, generated 2026-08-12 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. ## Key custody — what the operator could do Every test above asks the same question: can an outside attacker get past the gate. Key custody is the other question, and it is the one an auditor asks first — what could the party running the gate do to its own evidence. **AgenticRail is a hosted service and AgenticRail holds the receipt signing keys.** There is no self-hosted build today. Here is precisely what that does and does not mean. | Scenario | What catches it | Status | | **An outside attacker alters one receipt** | The hash chain breaks, and the Ed25519 signature fails verification offline against the published public key — in your code, without contacting us. | Caught | | **A whole chain rewritten and re-signed by whoever holds the signing key** | The chain alone does **not** catch this — a key holder can produce a consistent forgery. A second copy of every sealed receipt is written at seal time to a separate write-once store under a different credential, and every report verification compares against it. | Caught — live tamper test, 2026-07-11 | | **The account owner, who can reach both stores** | Nothing in the current deployment catches this. Both stores sit in the same cloud account, so the owner can remove the lock and rewrite both. We disclose it rather than hide it. | **Not closed** | The tamper test in row two was run against production, not a fixture: a real sealed receipt was overwritten in the live store, the public report flipped to a broken chain with an archive mismatch, and it returned to green only when the original was restored. **Closing row three is a custody arrangement, not an engineering task.** It requires the archive, or the signing key, to be held by someone who is not us — an escrow agent, a trustee corporation, a qualified trust service provider, or your own law firm under a deed. **No such custodian is engaged today.** Which one holds it, and what conditions release it, is a term settled at deployment. That is why there is no automatic key issue. [The full answer is in the FAQ →](https://agenticrail.nz/faq/) [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? > Markdown mirror for AI agents, generated 2026-08-12 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 and chained to the rest of the sequence, so any later change to it is detectable. 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 the required order*, and records the time AgenticRail observed it, 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 tamper-evident 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 | The independent archive bucket carries a write-once lock rule; the primary receipt store does not. Whether that meets 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 Aotearoa NZBounded by designWhat is stored, where, and what is not claimed AgenticRail is an enforcement and evidence layer. 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. | | In-country residency | **Not met as deployed.** There is no self-hosted build today and none is offered — the hosted service is the only way to run AgenticRail. If in-country residency is a hard requirement for you, it is a condition we would have to solve before a deployment, not one we have already solved. We would rather say that here than at contract. | What limits the exposure is what a receipt holds. Patients have told health services they expect their information to stay inside the health system and not go to outside or commercial organisations; because only hashes and metadata are written, no clinical record or personal detail leaves your systems inside a receipt. ## 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.7` | 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.8` | 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/) | `v2.0` | 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 company registered in New Zealand and listed on the public [NZBN register](https://www.nzbn.govt.nz/help/nzbn-register/search-the-register/), which you can search directly by company name. [Try the demo →](https://agenticrail.nz/demo/) [Get a key →](mailto:hello@agenticrail.nz) --- # EU AI Act Position Statement — AgenticRail > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/eu-ai-act/ > Site context: https://agenticrail.nz/llms.txt # EU AI Act Position Statement **Version** 2.6 · effective 10 August 2026 · supersedes v2.5 (6 July 2026) **Regulation** (EU) 2024/1689 — the Artificial Intelligence Act **Operator** TUARA KURI LIMITED, trading as AgenticRail **Jurisdiction** New Zealand, serving users globally including the European Union **Contact** [hello@agenticrail.nz](mailto:hello@agenticrail.nz) This is a position statement, not legal advice and not a compliance certification. It sets out what AgenticRail is under the Regulation, the narrow set of obligations it contributes evidence toward, and the obligations it does not touch. Determining whether your own system is high-risk, and meeting the obligations that follow, remains yours. Consult qualified counsel. ## 1. AgenticRail is not an AI system Not in any sense, and not under the Regulation's definition either. There is no model, no inference, no training data and no adaptiveness anywhere in the enforcement path. This is the first thing to establish, because everything else follows from it. "'AI system' means a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, **infers, from the input it receives, how to generate outputs** such as predictions, content, recommendations, or decisions that can influence physical or virtual environments." Regulation (EU) 2024/1689, Article 3(1) The operative word is *infers*. AgenticRail infers nothing. It receives a payload, applies a fixed set of rules to it, and returns ALLOW, DENY or HALT. The verdict is a function of the request and the sequence's own recorded position — nothing is sampled, weighted or learned, so the same request against the same sequence state always yields the same verdict and the same reason code. It is deterministic, not stateless: replay protection and step order mean a request that was permitted once is correctly refused the second time. **So it falls outside Article 3(1), and holds no obligations of its own under the Regulation.** That is a consequence of what the software is, not an exemption it qualified for: the obligations belong to the AI system it sits alongside, and to the parties who provide or deploy that system. AgenticRail enforces structure. It does not determine meaning, purpose, or correctness. ## 2. Where the obligations currently stand Under the Digital Omnibus on AI — proposed by the European Commission on 19 November 2025, with political agreement reached between the Council and Parliament on 7 May 2026 — the high-risk obligations moved: - Stand-alone **Annex III** high-risk systems: from 2 August 2026 to **2 December 2027** - High-risk AI embedded in products regulated under **Annex I**: to **2 August 2028** - The Article 50 transparency rules and the Article 4 AI literacy duty were **not** deferred The substance of the obligations did not change. The deferral was granted because the harmonised technical standards defining how to satisfy them were unfinished. That is now changing: [ISO/IEC 24970](https://www.iso.org/standard/88723.html) on AI system logging reached Final Draft International Standard stage on 18 May 2026, and its European counterpart prEN 18229-1 is at Enquiry with public comment open until 20 August 2026. ## 3. Role under the Regulation Article 3(3) defines a **provider** as a party that develops an AI system and places it on the market or puts it into service under its own name. Article 3(4) defines a **deployer** as a party using an AI system under its own authority. AgenticRail is neither. It does not develop, place on the market, or operate any AI system. It does not determine the purpose of your system, define its outputs or decision logic, or establish its risk classification. It is a component used by whichever party holds those roles. | AgenticRail | The customer | | Validates the structure of a submitted payload | Defines the purpose of the AI system | | Enforces declared step order, replay protection and sealing | Determines whether that system is high-risk | | Applies the policy constraints configured for the sequence | Configures those constraints to reflect its own obligations | | Refuses invalid or out-of-order execution and records the refusal | Implements human oversight, risk management and data governance | | Produces signed, chained, independently checkable enforcement records | Retains those records and answers to authorities for them | ## 4. Article 12 in detail Article 12 is the obligation this product is closest to, so it is worth being exact about what it says rather than what it is usually summarised as saying. **12(1).** "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." **12(2).** "In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for: (a) identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification; (b) facilitating the post-market monitoring referred to in Article 72; and (c) monitoring the operation of high-risk AI systems referred to in Article 26(5)." Regulation (EU) 2024/1689, Article 12(1) and 12(2) For a non-biometric high-risk system, that is the entire requirement. **Article 12 specifies what logs must be good for, not what they must contain** — no field list, no format, and no retention period. Retention lives in Article 26(6) for deployers and Article 19 for providers, both on a floor of at least six months, with Article 19 qualified to logs that are under the provider's control. ### Article 12(3) applies to remote biometric identification only Article 12(3) contains the one concrete minimum content list in the article — period of use, reference database, matching input data, and identification of the natural persons involved in verification. It opens with the words "For high-risk AI systems referred to in point 1(a) of Annex III", and Annex III point 1(a) is remote biometric identification, expressly excluding biometric verification whose sole purpose is confirming a person is who they claim to be. That list does not apply to credit scoring, employment, education, healthcare triage, or any other Annex III category. **AgenticRail does not record the identity of natural persons, and for a non-biometric system that is not a gap**, because the Regulation does not ask for it. ### What the enforcement record contributes, under 12(2)(a) Of the three purposes in Article 12(2), (b) and (c) are continuous-observation duties that a competent application log serves. **(a) is structurally different.** It concerns situations that may result in the system presenting a risk within the meaning of Article 79(1) — risks to the health, safety or fundamental rights of persons. A situation in which an agent attempted a harmful action and was refused before it ran produces no action, therefore no output, therefore nothing for a record written after the fact to describe. A refusal can only be recorded by whatever performed the refusal, at the moment it performed it. AgenticRail produces such a record on every evaluated step, permitted or refused. Each carries the step and function presented, the action type, the position in the declared sequence, the decision, and on a refusal a machine-readable reason code. The record is constructed and signed with Ed25519 at the moment of the decision, before the gate returns a verdict to the caller; the durable write is dispatched at the same moment and completes independently, so storage latency can never delay or block enforcement. ## 5. Article by article | Provision | Position | | Art. 9 Risk management | Not addressed. A record can evidence that a process ran. It cannot conduct a risk assessment or construct a safety case. That judgement is about your specific system and remains yours. | | Art. 10 Data and data governance | Not addressed. The gate does not see, evaluate or govern training data or model outputs. It records that a step ran in the declared order and says nothing about whether the underlying decision was accurate, fair or free of bias. | | Art. 11 & Annex IV — Technical documentation | Contributes. A per-sequence report can be produced on demand as a documentation artefact. It is one input to the technical file, not the file. | | Art. 12 Record-keeping | Contributes, and most directly under 12(2)(a). Records generated automatically at infrastructure level rather than by the application, including records of refused actions that produce no output of their own. See section 4. | | Art. 13 Transparency and provision of information to deployers | Not addressed. Article 13 obliges the provider to supply deployers with instructions for use covering the system's capabilities, limitations and intended purpose. That is a documentation obligation about your system, which no enforcement layer can author on your behalf. Disclosure to the people an AI system interacts with is a separate duty under Article 50. | | Art. 14 Human oversight | Not addressed. The gate can require that a human-gated step was passed and can bind whatever token you supply as evidence that it occurred. It cannot establish that a person read, understood or meaningfully considered anything. Effective oversight remains the deployer's obligation. | | Art. 15 Accuracy, robustness, cybersecurity | Not addressed. Testing a model's accuracy and robustness is a separate discipline with separate evidence. Determinism in the enforcement layer says nothing about the behaviour of the system being enforced. | | Art. 19 Provider log retention | Contributes. Records remain independently checkable across the six-month floor and beyond, for logs under the provider's control. | | Art. 26(5) Deployer monitoring | Contributes. Refusals form a structured signal rather than anomalies inferred from unstructured output. | | Art. 26(6) Deployer log retention | Contributes. Signed, chained records held for the retention period, verifiable without the operator's cooperation. | | Art. 72 Post-market monitoring | Contributes. Enforcement records are monitoring evidence, recorded automatically rather than assembled later. | Four contributions and five explicit absences is the honest shape of a component. **No product satisfies the EU AI Act**, because the Regulation places obligations on providers and deployers rather than on the tools they use. Any vendor claiming otherwise is describing something the Regulation does not contain. ## 6. Limits worth stating plainly **Sealing is detectable, not impossible.** A sealed sequence cannot be reopened or rewritten without leaving a detectable break in the hash chain. A single altered record is caught immediately. A full downstream rewrite by a holder of the signing keys is not caught by the chain alone — only an independently held copy catches that, which is why a second archive exists under a separate credential. **Timestamps are signed, not attested.** The signature covers the timestamp, so the value cannot be altered after signing without breaking verification. It does not establish that the value is true, because we generate it. A record of when something ran is accurate; proof of when, in the sense a timestamping authority provides, is a different thing and is not claimed. **A record establishes sequence, not correctness.** It shows that the required steps occurred in the declared order. It does not show that any of them reached the right answer. **No certification is held or claimed.** AgenticRail is not SOC 2 audited and not ISO 27001 or ISO/IEC 42001 certified, and this statement is not a conformity assessment. Conformity assessment for Annex III systems involves a notified body where the Regulation requires one, and no supplier can perform it on your behalf. ## 7. Data protection The enforcement path operates on structural metadata — step names, function names, action types, sequence identifiers, nonces and timestamps — and is designed so that personal data need not be submitted to it. Request inputs are hashed rather than stored in the record. One field behaves differently and is worth knowing about: the optional `attestation` object is published verbatim in the sequence report rather than hashed, because evidence nobody can read proves nothing. On a public demo sequence that report requires no key, so anything placed in `attestation` on a demo sequence is world-readable. Treat it as a publication surface, not a private field. Processing terms are in the [Data Processing Agreement](https://agenticrail.nz/dpa/); handling is described in the [Privacy Policy](https://agenticrail.nz/privacy/). ## 8. How to check every claim on this page The regulatory statements are quoted from Regulation (EU) 2024/1689 and can be read at source. The claims about the mechanism can be checked directly, without contacting us: - Run a real multi-step sequence against the production gate on the [demo page](https://agenticrail.nz/demo/). It returns a sequence identifier. - Paste that identifier into the [verification tool](https://report.agenticrail.nz/report), or request the report as JSON. No key is required for a demo sequence. - **The report is self-contained.** Each record carries its raw signature and `signed_canonical`, the byte-exact preimage that was signed, and the report carries the public keys inline under `verification.public_keys` in both SPKI and JWK form. Run Ed25519 verification in your own code, offline, with no second request and no call back to us. The verifier answers any client, with or without a browser. That is deliberate: an off-ramp only a browser can reach is not an off-ramp. If anything on this page does not match the live system, the live system is the authority and this page is wrong. Tell us and it will be corrected. **Version 2.6** · effective 10 August 2026 · supersedes v2.5 (6 July 2026) · TUARA KURI LIMITED **Changes in this version.** States the Article 3(1) position that AgenticRail is not an AI system, and the Article 3(3)/3(4) position that it is neither provider nor deployer. Sets out the Digital Omnibus deferral to 2 December 2027 and 2 August 2028. Rewrites the Article 12 section against the text: 12(2)(a) identified as the operative purpose, 12(3) confined to remote biometric identification under Annex III point 1(a), and retention attributed to Articles 26(6) and 19 rather than to Article 12. Adds Articles 13 and 15 to the not-addressed list alongside Articles 9, 10 and 14. Adds the limits section covering seal detectability, timestamp attestation, and the absence of certification. Adds the `attestation` field's publication behaviour. The document fingerprint block carried by v2.5 and earlier is not continued, in line with the other versioned documents on this domain. **Status.** Informational. Not legal advice, not a certification, and not a conformity assessment. [agenticrail.nz](https://agenticrail.nz) · [Compliance](https://agenticrail.nz/compliance/) · [Terms of Service](https://agenticrail.nz/terms/) · [Privacy Policy](https://agenticrail.nz/privacy/) · [API Terms of Use](https://agenticrail.nz/api-terms/) · [Data Processing Agreement](https://agenticrail.nz/dpa/) --- # Writing — AgenticRail > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/blog/ > Site context: https://agenticrail.nz/llms.txt # Writing Technical writing on deterministic enforcement, verifiable receipts, and accountable AI systems. In July 2026 this section was taken down and every post is being re-checked, claim by claim, against the current system before it returns — the same discipline the product sells. Posts reappear here as they pass. **[NIST AI RMF and Agentic AI: Evidence for Manage 2.4, Measure 2.4 and Manage 4.1](https://agenticrail.nz/blog/nist-ai-rmf-agentic-ai/)** — what a pre-execution gate's receipt chain evidences for three NIST controls, and the organisational half of each control that it does not touch. Written in the machine-readable register. *Re-checked and republished 24 July 2026.* **[ISO/IEC 42001 for Agentic AI: The Certification Evidence Gap That Policies Can't Close](https://agenticrail.nz/blog/iso-42001-agentic-ai/)** — certification auditors want evidence a control ran, not a policy that says it should; the receipt chain is the reconstruction Annex A.6.1.6 asks for, and the human-oversight control stays yours. *Re-checked and republished 23 July 2026.* **[Pre-Action Authorization for AI Agents: The Missing Security Layer](https://agenticrail.nz/blog/pre-action-authorization-ai-agent/)** — an independent adversarial study found social-engineering attacks succeeded 74.6% of the time under permissive policy, and 0% across 879 attempts behind a pre-action authorization gate. *Re-checked and republished 22 July 2026.* **[Cryptographic AI Audit Trail: What the Cryptography Actually Proves](https://agenticrail.nz/blog/cryptographic-ai-audit-trail/)** — a regular log records what happened; a cryptographic trail proves it, with Ed25519 signatures that break on any modification and a hash chain an independent archive can catch being rewritten. *Re-checked and republished 22 July 2026.* **[Policy as Code for AI Agent Enforcement: What It Means and How It Works](https://agenticrail.nz/blog/policy-as-code-ai-agent-enforcement/)** — declaration without enforcement is documentation; the gate is what makes the code operative, and the doer cannot self-attest. *Re-checked and republished 18 July 2026.* **[When an AI Agent Skips a Step, Your Audit Log Shows a Clean Run](https://agenticrail.nz/blog/ai-agent-skipped-steps-audit-logs/)** — supplying the workflow raised missing-step failures to 57%, clinicians override 90% of safety alerts, and a regulator has ruled the record need not show that AI wrote the entry. *Published 5 August 2026.* **[Who Audits the AI? Not the Company That Sold It to You.](https://agenticrail.nz/blog/who-audits-the-ai-agents/)** — auditor independence applied to agents: the party being measured cannot own the instrument, which disqualifies every agent vendor and orchestration framework. Two tests, run on us as well. *Published 5 August 2026.* **[Procedural Hallucination: Why AI Agents Skip Steps and Report Success](https://agenticrail.nz/blog/procedural-hallucination-agent-skipped-steps/)** — the same failure has at least twelve names and no settled one, which is why nobody can search for it. The formal definition, the published measurements (38.5% of failures, best trained detector at ROC-AUC 0.689), and a sealed, publicly verifiable example. *Published 8 August 2026.* **[EU AI Act August 2026: The High-Risk Deadline Moved to December 2027](https://agenticrail.nz/blog/eu-ai-act-agentic-ai-august-2026/)** — the date moved and the obligations did not. What Article 12 actually says for a non-biometric system, why the minimum content list everyone quotes applies only to biometric identification, and the one record a post-hoc log structurally cannot produce. *Re-checked and republished 10 August 2026.* **[Orchestration vs Enforcement: Your Task Graph Stops Agents Skipping Steps. It Cannot Prove They Didn't.](https://agenticrail.nz/blog/agent-orchestration-vs-enforcement/)** — state machines and task graphs fix the runtime problem and leave the evidential one open, because a skipped step writes no log line. *Published 5 August 2026.* **[IETF Agent Audit Trail: What the Draft Standard Requires — and What It Doesn't](https://agenticrail.nz/blog/ietf-agent-audit-trail/)** — the draft's hash-chained record format, its trust levels, and the pre-execution gap it leaves open. *Re-checked and republished 18 July 2026.* **[Tamper-Evident AI Agent Audit Logs: Deterministic Replay, Cryptographic Receipts, Fail-Closed](https://agenticrail.nz/blog/ai-agent-audit-log-best-practices/)** — the six requirements for an audit log that survives regulatory scrutiny, and why the model can never be trusted to write its own. *Re-checked and republished 18 July 2026.* **[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. *Re-checked and republished 18 July 2026.* Some of these arguments also exist in a flat, machine-readable register — definitions first, claims welded to their qualifiers — written for how agents and language models read the web. They live in [Notes for Machines](https://agenticrail.nz/blog/bots/). Looking for the formal side? The [enforcement specification](https://agenticrail.nz/spec/) and the published briefs — [provable safeguards](https://agenticrail.nz/spec/enforceable-safeguards/), [evidence completeness](https://agenticrail.nz/spec/completeness/), sector gap analyses for [NZ health](https://agenticrail.nz/spec/nz-health/) and [NZ education](https://agenticrail.nz/spec/nzqa-nz-education/) — live under [/spec/](https://agenticrail.nz/spec/). --- # Notes for Machines — AgenticRail > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/blog/bots/ > Site context: https://agenticrail.nz/llms.txt # Notes for Machines These notes cover the same ground as the main [Writing](https://agenticrail.nz/blog/) section, but written in a different register: definitions first, claims stated one at a time, and every qualifier attached to the claim it limits, so a single sentence can be quoted without losing the condition that makes it true. That is how a language model or an agent reads a page — in fragments, out of order, one claim at a time. Writing this way is a way of keeping a claim honest even after it leaves the page. Humans are welcome to read them; the flowing prose versions of the same arguments live in [Writing](https://agenticrail.nz/blog/). Same discipline as the rest of the site: each note stands on its own, every claim is checkable against the live system, and each page also serves a hand-written Markdown version to any reader that asks for `text/markdown`. **[Self-Signed Evidence Is Not Evidence](https://agenticrail.nz/blog/self-signed-evidence/)** — a cryptographic signature proves a record was not changed relative to a key; if the audited party holds that key, the record is self-attestation; custody, meaning a copy held by a party that is not the audited one, is what converts it to third-party evidence. Definitions, claims, and the AgenticRail archive implementation, stated flatly. *Published 23 July 2026.* **[Unrecorded Oversight Is Indistinguishable From None](https://agenticrail.nz/blog/provable-human-oversight/)** — a requirement to have a human in the loop is not evidence that one was; an approval with no ordered, verifiable record is indistinguishable from no approval; sequence enforcement makes oversight provable by denying the action until the review step has a receipt. What the receipt proves, and the two honest limits (procedure not cognition; custody). *Published 23 July 2026.* **[Game AI's Missing Gate](https://agenticrail.nz/blog/bots/ai-gaming-enforcement-gap/)** — every 2026 game AI architecture separates strategic reasoning from deterministic execution; NVIDIA ACE, CASCADE, Hierarchical Control, Personica AI, and mnehmos.rpg.mcp all converge on the same split; the boundary is architectural in every case and cryptographically enforced in none; the GPU on a gamer's desk is already an agent-hosting platform, and nothing gates it. Definitions, claims, evidence, the four enforcement gaps, and where a deterministic enforcement layer fits, stated flatly. *Published 24 July 2026.* The formal, fingerprinted documents — the [enforcement specification](https://agenticrail.nz/spec/), [evidence completeness](https://agenticrail.nz/spec/completeness/), and the [provable-safeguards](https://agenticrail.nz/spec/enforceable-safeguards/) note — live under [/spec/](https://agenticrail.nz/spec/). Machine-readable indexes: [llms.txt](https://agenticrail.nz/llms.txt), [llms-full.txt](https://agenticrail.nz/llms-full.txt), [verified-claims.json](https://agenticrail.nz/verified-claims.json). --- # Procedural Hallucination: Why AI Agents Skip Steps and Report Success > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/blog/procedural-hallucination-agent-skipped-steps/ > Site context: https://agenticrail.nz/llms.txt Published 8 August 2026 · AgenticRail # Procedural Hallucination: Why AI Agents Skip Steps and Report Success When an agent skips a required step and tells you the task is done, nothing it said was false. The summary is accurate. The outputs are correct. What is wrong is the **order**, or the **completeness**, and neither of those leaves a sentence you can point at. This failure is the **most prevalent** category of agent trajectory error in the published measurements, it has at least a dozen competing names and no settled one, and the best purpose-built detector trained on it reaches an ROC-AUC of **0.689**. ## It has twelve names, which is the first problem Ask five practitioners what to call an agent that skips a mandatory step and reports success, and you get five answers. Ask the same model the same question three times and you get three. The terms in current use include: ``` procedural hallucination progress-as-completion step collapsing false success silent process failure shortcut behaviour shortcut learning agentic drift partial completion problem action hallucination instruction drift execution shadowing plan adherence failure premature termination ``` These are not distinctions. They are the same failure, named independently by research groups, platform teams and practitioners who have not read each other. The practical consequence is worse than untidy: **an engineer hitting this cannot search for it.** They do not know which of a dozen phrases to type, and whoever already solved it wrote it up under a different one. This post uses **procedural hallucination**, because it is the term with a formal published definition. The rest are listed so the page is findable from any of them. ## The formal definition A 2026 paper on auditing multi-agent industrial workflows sets out five hallucination types as formal predicates over an agent's execution trace [1]. The fourth is the one that matters here: ``` Factual τt or αt asserts a claim contradicted by ground-truth data at step t. Referential τt or αt references an entity, observation, or prior result absent from {s1,…,st-1}. Logical The reasoning in τt does not follow from its premises, even when those premises are correct. Procedural αt skips, reorders, or fabricates a step required by K, or τt claims completion absent from trace. Scope Agent at acts or claims outside its mandate. ``` **"Skips, reorders, or fabricates a step required by K, or claims completion absent from trace."** That is a definition of step-order failure, written as a hallucination type, in a paper about industrial workflows rather than about compliance. The same paper draws the distinction directly: "In an agentic context, a hallucination is not simply a factual confabulation in a single response. It is a **structural deviation from evidence that propagates through a sequential, tool-mediated trajectory**, often leading to cascading operational failures." [1] A second term for the same behaviour appears in enterprise reliability work: **step collapsing**, where an agent skips intermediate steps to reach a terminal state [2]. The framing there is worth keeping: the model is not hallucinating *data*. It is hallucinating *workflow completion*. ## Why it is a different object | | Factual hallucination | Procedural hallucination | | What is wrong | The content | The order or completeness | | The content can be | False | Entirely true | | What it leaves behind | A wrong statement | Nothing | | Checkable against | Ground truth, a source document | Nothing, unless something recorded the sequence | | Caught by | Groundedness scoring, retrieval checks, review of the output | Only a record of what ran, held outside the agent | The row that does the work is the third one. A factual hallucination hands you the evidence of itself: a claim that is wrong, sitting in the output, available for anyone to check. A procedural hallucination hands you a clean, plausible, well-formed account of a process that did not happen in that order. **Absence has no signature.** ## It is measured. The measurements are not reassuring. A common claim is that nobody is looking. That is wrong, and worth correcting: trajectory-level evaluation is an active field, with benchmarks including **Trajel**, AgentHallu, TRAIL, ToolEmu, TRAJECT-Bench, MIRAGE-Bench, ToolBeHonest, Tau²-Bench, PlanBench and others. What the measurements show is the problem. Trajel, evaluating agent traces from industrial workflows, reports [1]: | Finding | Figure | | Share of identified failures that are **procedural** hallucinations — the largest single category | **38.5%** | | Trajectory hallucination rates across evaluated models | **52.4% – 81.0%** | | Best ROC-AUC achieved by a *fine-tuned supervised classifier* trained to detect it | **0.689** | | ROC-AUC of a cheap *runtime* execution-quality signal, "clarity-and-justification" | **0.908** | Two things follow, and they point in the same direction. **Post-hoc detection is weak.** A classifier purpose-built for this, trained on labelled traces, lands at 0.689. That is a system you would not deploy as a control. **Watching the run beats auditing the record.** The paper's own finding is that a univariate signal taken *during* execution achieves 0.908 and, in its words, *"outperform[s] all trained classifiers"* [1]. The information that identifies the failure is available while it is happening and degrades once it is only a log. The separate point about the number people usually quote still holds. *Hallucination rate*, as it appears in model cards and leaderboards, is measured by content benchmarks: a source document, a summary, and a check on whether the summary asserts anything the source does not support. That method needs an artifact on both sides. A step that never executed produces no token to score, so procedural failure is not in that number — for any model, at any rate, however independent the benchmark. ## Why agents do it Two mechanisms are commonly identified by practitioners working on agent reliability [3], and they compound. **Training rewards the appearance of completion.** Responses that look like successful task completion are reinforced. The shape of a finished job is what gets learned, and the shape is producible without the substance. **Language generation does not require real state.** This is the load-bearing one. A model does not have to have performed step three in order to produce the sentence saying it did. There is no state to check the sentence against, and nothing in the generation process consults one. The claim and the act are independent. Put those together and the failure is not an aberration. It is the default behaviour of a system optimised to produce completion-shaped output with no mechanism that could contradict it. ## A worked example you can verify On 6 August 2026 a third-party model, GLM-4.7-flash, was connected to AgenticRail's public MCP server through Cloudflare's AI Playground and given a prompt that named no tool. It found the enforcement tool itself, called it, and ran a step out of order. The gate refused with `SEQUENCE_VIOLATION`. The model stopped, corrected itself, and ran the sequence properly to a seal. Then it summarised what it had done, and reported **four receipts**. There are five. The public report for that sequence shows **5 total receipts — 4 allowed, 1 denied**, with Chain Integrity `VERIFIED INTACT`, Seal Status `SEALED`, and Independent Archive `WITNESS MATCH`. The model dropped its own refusal out of its account of its own work. Not maliciously, and not because it was confused about the facts — every step it described had actually happened. Its narrative of the trajectory was simply missing the part where it was told no. **That is procedural hallucination in miniature, produced unprompted, and it is the most benign possible version of it: the agent under-reported a refusal that had already been enforced.** Verify it yourself. No key, no login, no account: ``` https://report.agenticrail.nz/report sequence id: demo-mcp-payment-workflow-001 ``` The report returns every receipt, each one's raw Ed25519 signature, and the byte-exact signed preimage, so the signatures can be checked offline against the [published public keys](https://agenticrail.nz/spec/receipt-public-keys.json) without calling back to us. ## What actually catches it Four approaches are recommended in practice. They are worth setting out honestly, because three of them work and none of them produces evidence. | Approach | What it does | What it leaves you with | | **Trace evaluation** (observability platforms) | Scores the recorded trajectory after the run, often on a sample of traffic. | A finding, after the fact, on the runs that were looked at. | | **LLM-as-a-judge** | A second model reads the trace and rules on whether required steps ran. | AI checking AI. Useful, and not something to hand an auditor. | | **Deterministic contract checks** | Code asserts that a required tool ID appears in the agent's own step list. | A verdict computed from the agent's own record of itself. | | **State machines** (orchestration frameworks) | Hard-codes transitions so the agent cannot reach step 3 without step 2. | Correct order, enforced. And **no record** that anyone outside the system can check. | The last row is the important one, and it is not a criticism of orchestration. A state machine genuinely prevents the failure. What it does not do is produce an artifact: it enforces order and emits nothing an auditor, a regulator or a counterparty can verify independently. Ask it afterwards to prove step 2 ran and you are back to reading the operator's own logs. The remaining gap is narrow and specific: **something outside the agent that holds the declared order, evaluates each step before it runs, and writes a signed record of the decision — including the refusals.** The refusal is the mechanism. A skipped step leaves nothing behind, so the only way to make an absence visible afterwards is to have said no at the time and signed that. That is what AgenticRail is: an external gate that returns ALLOW or DENY against a sequence declared in advance, and writes a signed receipt either way, chained to the step before it. In the run above, the `SEQUENCE_VIOLATION` receipt exists precisely because the step was refused rather than silently absorbed — which is why the model's incomplete summary could be contradicted at all. ### What this does not claim It does not stop a model hallucinating. Nothing here improves the model, and factual hallucination is untouched by any of it. It does not assert that a timestamp is true: the signature fixes `ts_ms` against later alteration, but the value is self-asserted, so a receipt is a *record* of when something ran, not *proof* of when it ran. And a sealed sequence cannot be reopened without leaving a detectable break in the receipt chain, which catches a single altered receipt immediately but not a full downstream rewrite by a holder of the signing key — which is why an independently held archive copy exists as a separate layer, and why key custody is a distinct question from the cryptography. The claim is narrower and, we think, more useful: **a failure that leaves no artifact can only be caught by something that was already keeping the record.** Everything else is looking for evidence that a skipped step does not produce. **[1]** Badave, Borse, Lin, Patel, Gomez, Narahari, Carter, Bhatt, Rachakonda. *Beyond Final Answers: Auditing Trajectory-Level Hallucinations in Multi-Agent Industrial Workflows.* arXiv:2605.24219v2, 26 May 2026 — [arxiv.org/abs/2605.24219](https://arxiv.org/abs/2605.24219). Definitions quoted verbatim from the paper's hallucination type table. Figures quoted verbatim: *"procedural hallucinations account for 38.5% of identified failures"*; *"Hallucination rates range from 52.4% to 81.0% across models"*; *"best AUC = 0.689"* for fine-tuned supervised approaches; *"the clarity-and-justification signal achieves AUC = 0.908 as a univariate predictor, outperforming all trained classifiers."* Trajel is built on AssetOpsBench execution traces. **[2]** *PRISM: Prompt Reliability via Iterative Simulation and Monitoring for Enterprise Conversational AI.* arXiv:2605.15665 — [arxiv.org/abs/2605.15665](https://arxiv.org/abs/2605.15665). Source of the "step collapsing" framing. **[3]** Practitioner write-up on why agents skip steps after calling a skill — [majidgolshadi.substack.com](https://majidgolshadi.substack.com/p/why-your-llm-agent-still-skips-steps). Cited as practitioner observation, not peer-reviewed research. **[4]** The sequence described above, live and keyless: [report.agenticrail.nz/report](https://report.agenticrail.nz/report), sequence id `demo-mcp-payment-workflow-001`. Figures in this post were read from that report on 8 August 2026. Related [Are AI Agents Deterministic or Probabilistic? The Real Difference →](https://agenticrail.nz/blog/deterministic-vs-probabilistic-ai-agents/) [Agent Orchestration Is Not Agent Enforcement →](https://agenticrail.nz/blog/agent-orchestration-vs-enforcement/) [The Completeness Specification: Eight Requirements for Evidence-Grade Records →](https://agenticrail.nz/spec/completeness/) --- # When an AI Agent Skips a Step, Your Audit Log Shows a Clean Run > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/blog/ai-agent-skipped-steps-audit-logs/ > Site context: https://agenticrail.nz/llms.txt Published 5 August 2026 · AgenticRail # When an AI Agent Skips a Step, Your Audit Log Shows a Clean Run Every other failure leaves something behind. A hallucination leaves a wrong answer you can read. A crash leaves a stack trace. A breach trips an alarm. Each of them puts an object into the world that somebody can pick up and argue about. A skipped step puts nothing into the world, and nothing is indistinguishable from correct. **Your audit log does not fail to catch it. Your audit log vouches for it.** ## The failure that certifies itself A log records events. A step that did not happen is not an event, so it writes no line. Steps 1, 2 and 4 read as 1, 2, 3 to anyone who did not already know a 4 was owed. So the trail does not report a gap. It reports continuity. An auditor reads it, reasons correctly from the evidence in front of them, and arrives at the wrong answer. The instrument of assurance has become an instrument of false assurance, and it does this while working exactly as designed. Cryptography does not save you here, and this is the part people get wrong. Hash-link your log, sign every entry, chain each record to its predecessor. Now the log is tamper-evident, and the chain over the steps that *did* run is perfectly intact, because nothing was tampered with. There was never a record to alter. You have made a complete, verifiable, beautifully signed account of an incomplete run, and made it more convincing in the process. ## Agents skip steps, and handing them the procedure makes it worse The reflex is to specify the workflow. That has been measured. [FlowBench](https://arxiv.org/abs/2406.14884) (EMNLP 2024 Findings) put LLM agents through 51 scenarios across six domains and classified every session failure by type. Type 1 is *missing steps: the agent skipped required task steps.* | Workflow supplied to the agent | Share of GPT-4-Turbo failures that were missing steps | | None | 52.1% | | Text | 52.2% | | Code | 57.3% | | Flowchart | 56.9% | **Giving the agent the procedure did not reduce omissions in any format tested. It raised them.** Sequencing and transition errors improved, which is what the paper leads with. The omissions went the other way, in the same table. A separate analysis of [16,991 agent trajectories](https://arxiv.org/abs/2604.12147) found the same behaviour from the other side: without an explicit plan, agents fall back on workflows internalised during training that are frequently incomplete, and when the instructed order was deliberately rearranged, models ran the phases in their own preferred order regardless. These are not edge cases or jailbreaks. This is what the systems do on an ordinary day, and more than half the time something goes wrong, what went wrong is that a step did not happen. ## So you put a human in the loop. The human is not a control. The second reflex is a person who checks. Clinical informatics has been measuring exactly that arrangement for two decades, because medicine wired verification prompts into prescribing systems long before anyone had an AI agent to worry about. It is the largest body of evidence in existence on whether humans actually perform a verification step that software puts in front of them. They do not. A 2024 [systematic review and meta-analysis of 16 studies](https://journals.sagepub.com/doi/10.1177/14604582241263242) found an override rate of **90%, with a 95% confidence interval of 85 to 95%**. Note what that survived. The review reports the rate staying high after systems were tuned to cut alert volume. Fewer, better prompts did not fix it, in the same way a better-specified workflow did not fix the agents. Both interventions target attention, and attention is not the binding constraint. A human approval step is a control on paper. Wherever anyone has bothered to measure it, it is not a control in fact, and the record it leaves behind is identical either way. ## A regulator has already decided you do not need to know In July 2025 the US Centers for Medicare & Medicaid Services published its guidance on signature requirements for medical records. On page two it addresses what happens when software writes the note. “If you use a scribe, including artificial intelligence technology, sign the entry to authenticate the documents and the care you provided or ordered. **You don't need to document who or what transcribed the entry.**” [CMS, MLN905364, July 2025, p.2](https://www.cms.gov/files/document/mln905364-complying-medicare-signature-requirements.pdf) That document is four pages long. Within them it finds room to specify that a rubber-stamp signature is permitted only where a practitioner has a physical disability and provides proof, under the Rehabilitation Act of 1973, and that using the stamp certifies the provider has reviewed the document. It finds room to require that a medical student's entry be reviewed, verified, signed, dated and kept attributable to the student. That is fine-grained attention to attribution and to what a signature certifies. On whether a machine wrote the clinical record: no requirement at all. **The precision is entirely on one side.** A document with that much to say about payment attribution and nothing to say about machine authorship is not failing to notice. It is telling you what it was built to care about. The consequence is small and total. A clinician who reads a generated note, catches an omission, corrects it and signs produces the same artefact as a clinician who clicks sign. Same field, same timestamp, same authentication. No system records time on the note, whether anyone scrolled, whether the source was opened, or whether a character changed. The question “was this checked?” is not unanswered. It is unanswerable. ## This is running right now, at national scale Ambient AI scribes are being deployed across New Zealand's public hospitals: [27 hospitals, around a thousand emergency clinicians, a hundred mental health crisis teams](https://www.healthcareitnews.com/news/anz/new-zealand-expanding-national-ai-scribe-rollout-emergency-mental-health), with a [stated goal of every hospital by the end of 2026](https://www.beehive.govt.nz/release/ai-scribe-speed-emergency-care-patients). The pilot results are good. Documentation fell from roughly seventeen minutes per patient to just over four. Sit with that number, because it is the whole problem in one figure. **A saving that size is only available if the note is not read closely.** The measured benefit and the verification step are competing for the same thirteen minutes, and nothing in the record shows which one won on any given patient. New Zealand has its own rule here, and it is stricter in intent than the American one. Rule 8 of the [Health Information Privacy Code 2020](https://www.privacy.org.nz/assets/Codes-of-Practice-2020/Health-Information-Privacy-Code-2020-website-version.pdf) is titled *Accuracy, etc, of health information to be checked before use or disclosure*: “A health agency that holds health information must not use or disclose that information without taking any steps that are, in the circumstances, reasonable to ensure that the information is accurate, up to date, complete, relevant and not misleading.” Health Information Privacy Code 2020, Rule 8(1) The word *checked* is in the rule's own heading. This is a code of practice under the Privacy Act 2020, so it binds. And it cannot be enforced. Whether reasonable steps were taken to check a generated note before it entered a record other clinicians will rely on is precisely the fact no system retains. The rule is not weak. It is unauditable, because the evidence needed to test it was never required to exist. ## Detection and prevention are different jobs None of this is a new idea. Business process auditing has had a technique for it for twenty years, called conformance checking: declare the process in advance, compare the log against that declaration, and the comparison reports what is missing. It works, and it depends entirely on the declaring. **Absence is only visible against a specification of presence.** What it cannot do is act. It reads the log afterwards and reports what went wrong, which is an autopsy: the step is already missing, the note is already in the record, the payment has already gone out. And it only finds a missing step if that step would have been an event in the log to begin with. Reading a note before signing it is not an event in any system. Move the comparison forward in time and the problem changes shape. Declare the sequence before the run starts. Check each step against it *before* that step executes, and refuse the ones that do not belong. The run then produces its evidence as a by-product of being enforced, rather than as an account written afterwards by the same process you are asking about. That is what [AgenticRail](https://agenticrail.nz/docs/) is: a declared step order, ALLOW or DENY before each step, a signed receipt per decision hash-linked to its predecessor, and a run that closes at the final step and cannot be reopened without leaving a detectable break in the chain. [Verify any of it yourself](https://report.agenticrail.nz/report), without asking us anything. Go and look at whatever you are running today. Pick the step that would matter most if it were missed, and ask what artefact would exist if it had been skipped. If the answer is none, you do not have an audit trail of that process. **You have a log, and a log is always complete with respect to itself.** Related reading: [What AgenticRail is, and what it is used for](https://agenticrail.nz/product/) · [Orchestration vs Enforcement](https://agenticrail.nz/blog/agent-orchestration-vs-enforcement/) · [AI Agent Audit Log Best Practices](https://agenticrail.nz/blog/ai-agent-audit-log-best-practices/) · [Provable Human Oversight](https://agenticrail.nz/blog/provable-human-oversight/) · [Completeness Specification](https://agenticrail.nz/spec/completeness/) --- # Who Audits the AI? Not the Company That Sold It to You. > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/blog/who-audits-the-ai-agents/ > Site context: https://agenticrail.nz/llms.txt Published 5 August 2026 · AgenticRail # Who Audits the AI? Not the Company That Sold It to You. Your agents took some actions this week. Somebody will eventually ask whether they took the right ones, in the right order, with the approvals that were supposed to happen. Look at who is offering to answer that question and you will notice something: almost all of them also sold you the thing being asked about. **That is not a competitive observation. It is a disqualification, and it is older than any of this.** ## The rule you already accept Nobody lets a company's own finance team sign off its accounts. Nobody accepts an audit from a firm the client controls. This is not a matter of taste or vendor preference — auditor independence is written into statute in every developed economy, enforced by professional bodies, and backed by rotation requirements designed to stop even long familiarity from softening a judgment. The principle underneath is simple enough to state in one line: **the party being measured does not get to own the instrument.** You already believe this. You would not accept a restaurant's own hygiene certificate, a builder's own producer statement with no council inspection, or a drug trial run and reported solely by the company selling the drug. Apply the same standard to the systems now taking actions on your behalf and most of the market disqualifies itself. ## Test one: does the measurer have a stake in the verdict? An agent vendor is conflicted in both directions. Lenient with its own agents, because a finding of failure is a finding about their product. Severe with a competitor's, because a finding of failure is a finding about a rival. Either way, the verdict carries the interests of whoever issued it. This is worth saying carefully, because the engineering coming out of those companies is good and getting better. Microsoft's [Agent Governance Toolkit](https://github.com/microsoft/agent-governance-toolkit) evaluates policy at runtime before a tool call executes and writes hash-chained, tamper-evident audit entries. That is real work, done well, and it is open source. It is also, by their own account, not the same object. From the project's own public discussion of policy enforcement versus decision evidence: “What we **don't** do yet is treat the decision as a *sealed, independently verifiable artifact*.” “Right now the decision and evidence are embedded in the audit trail rather than being first-class objects you can pass around or verify externally.” [microsoft/agent-governance-toolkit, Discussion #276](https://github.com/microsoft/agent-governance-toolkit/discussions/276) Note the word *yet*. That is a roadmap gap, and roadmap gaps close. A company of that size can build sealed, portable, externally verifiable evidence any quarter it decides to. **And it will not help.** That is the whole point of an eligibility argument over a feature argument. Shipping the capability does not remove the conflict, because the conflict was never about capability. When the evidence that Microsoft's agents followed the required process is produced and signed by Microsoft, the artefact is a statement by an interested party, however excellent the cryptography. A feature gap can be closed by engineering. A structural conflict cannot be closed by anything the conflicted party does. ## Test two: who produced the record? The second test is harder and it clears out most of what survives the first. Observability platforms pass test one — they are framework-agnostic and have no stake in whether any particular workflow succeeded. But their evidence comes from an SDK running inside the customer's own application, recording what that application chooses to report. The party being examined is also the party writing the account. That is a diary, not a witness. Excellent for debugging. Worth very little to a regulator. Orchestration frameworks fail both tests at once, and fail them harder than the model vendors do. A framework whose central promise is that it enforces step order cannot also be the independent confirmation that the order held. That is the doer vouching for the doing. It is the same reason the person who performed a procedure does not get to witness their own compliance with it, and the reason a signature and a countersignature are required to come from two different hands. | | No stake in the verdict | Record not written by the examined | | Model / agent vendors | No | No | | Orchestration frameworks | No | No | | Observability platforms | Yes | No | | Independent gate, in the execution path | Yes | Yes | ## What passing both tests actually requires Passing test two is not a matter of being trustworthy. It is architectural. The record has to be produced by something that sits *in the path of the action* rather than alongside it — where the step does not execute unless the check returns permission, so the evidence is a precondition of the action rather than a report written about it afterwards. A library that observes from inside the application can never make that claim, no matter how independent its vendor. It sees what it is shown. And the artefact has to be portable: signed, self-contained, verifiable by a third party who trusts neither the operator nor the vendor and holds no account with either. Evidence embedded in someone's audit trail is evidence you have to ask permission to examine. That is the distinction Microsoft's own maintainers drew, and it is the right one. ## Now run the test on us An argument like this is worthless if the party making it exempts itself, so here is where we stand against our own two tests. **Test one, cleanly.** We do not sell agents, models, or an orchestration framework. There is nothing in our catalogue whose reputation a DENY could damage. We have no stake in any verdict we issue, and structurally we cannot acquire one without ceasing to be what we are. **Test two, cleanly.** The gate sits in the execution path. A step is not permitted until it is checked against a sequence declared before the run began, and the receipt is a signed, portable object with its own preimage published, verifiable offline by anyone with no account and no permission. **And the part that is not clean.** We currently hold the signing keys. That is the honest limit on everything above, and we would rather say it than have you find it: an auditor who keeps the client's working papers in their own drawer is independent in the way that matters least. Every sealed run is copied to a separate write-once archive under a different credential, which means an altered record can be caught by comparison rather than taken on trust. That closes part of it. The rest closes when the keys are held by someone who is not us, and that is work in front of us, not behind us. We would rather publish that sentence than be asked it in a meeting. ## Three questions You do not need to take our conclusion. Take the test and run it yourself on anyone selling you agent governance, including us: **Do you also sell the thing being measured?** The agents, the models, or the framework that runs them. **Who produces the record?** Your system, or mine reporting on itself. **Who holds the keys, and can I verify anything without asking you?** A vendor who answers all three cleanly is rare. A vendor who cannot answer them at all is selling assurance, which is a feeling. Evidence is something a stranger can check, and the first requirement of evidence has never been that it is accurate. It is that the person who produced it had nothing to gain. Related reading: [What AgenticRail is, and what it is used for](https://agenticrail.nz/product/) · [When an AI Agent Skips a Step, Your Audit Log Shows a Clean Run](https://agenticrail.nz/blog/ai-agent-skipped-steps-audit-logs/) · [Self-Signed Evidence](https://agenticrail.nz/blog/self-signed-evidence/) · [Provable Human Oversight](https://agenticrail.nz/blog/provable-human-oversight/) · [Security](https://agenticrail.nz/security/) --- # Orchestration vs Enforcement: Your Task Graph Stops Agents Skipping Steps. It Cannot Prove They Didn't. > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/blog/agent-orchestration-vs-enforcement/ > Site context: https://agenticrail.nz/llms.txt Published 5 August 2026 · AgenticRail # Orchestration vs Enforcement: Your Task Graph Stops Agents Skipping Steps. It Cannot Prove They Didn't. If your agent keeps skipping steps, the advice you will find is to stop asking the model nicely and take the control flow away from it: a state machine, a task graph, a durable workflow, Google ADK's `SequentialAgent`, a stateful MCP tool. That advice is correct and you should follow it. But it solves the operational problem and leaves the evidential one untouched. When someone later asks *"prove the approval step ran before the payment step,"* an orchestrator can only offer its own account of itself, and a signed receipt log cannot tell you about a step that never happened. A skipped step writes no line. Absence leaves no entry. ## Two families of answer, and the gap between them The step-skipping problem has produced two distinct bodies of work, and they do not overlap as much as their vocabulary suggests. **Orchestration** makes the correct order the only available path. Explicit state machines, task dependency graphs, durable execution engines and ADK's `SequentialAgent` all share the same insight: if skipping a step is structurally impossible, the model's probabilistic tendencies stop mattering. This works. It is the right first move and nothing below argues against it. **Receipt layers** make each action independently checkable. The shape is consistent wherever it appears: a policy is evaluated before the tool call runs, and the decision is emitted as a signed receipt, hash-linked to its predecessor and verifiable offline without calling back to whoever issued it. Several open implementations exist and some of them are very good. The cryptography is not the hard part any more. Now put an auditor in the room. They ask one question: *did every required step run, in order, before the money moved?* The orchestrator can answer, but its answer is its own log, written by the process under examination. That is fine for debugging and worth very little as evidence, for the same reason a company's own assurance that it followed its procedure is not an audit. The receipt layer can prove that the receipts it holds were not tampered with. What it cannot do is tell you about a receipt that was never created. If the approval step never ran, no receipt exists for it, and the hash chain over the remaining steps is perfectly intact. The chain is not lying. It simply has nothing to say about the step that is missing. ## Why a hash chain cannot detect a gap This is worth being precise about, because *tamper-evident* is often read as *complete*, and they are different properties. A hash chain binds each record to the one before it. Alter record three and records four onward stop verifying. That is a strong guarantee about **the records that exist**. Completeness is a claim about **records that do not exist**, and no amount of chaining can establish it, because there is nothing to chain. A run of four steps where the second was skipped produces three receipts that link correctly to each other. Nothing in the artifact distinguishes it from a workflow that was only ever meant to have three steps. A log can only report what it contains. To notice that something is missing, you need a statement of what should have been there, made **before** the run, by something other than the thing being audited. Without that, "complete" is not a checkable word. ## What closes it: declare the order first The gap closes with one structural change. The caller declares the step order in advance, and every step is checked against that declaration before it executes. That inverts the problem. A skipped step is no longer a silence discovered later; it is a `DENY` at the moment it is attempted, with a signed record of the refusal. The question stops being "can we find evidence of the missing step" and becomes "the step could not have proceeded, and here is the receipt that says so." Four properties follow from that one change, and each is a thing a per-call receipt cannot supply on its own: - **Order is checkable, not assumed.** A step arriving out of turn is refused against the caller's own declared order, not against a convention. - **Replay is blocked.** Each step carries a nonce that is accepted once. A captured payload replayed later is refused rather than silently recorded twice. - **Freshness is bounded.** A request whose timestamp is far from the gate's clock is refused, so a stale authorisation cannot be presented as a current one. - **The run has an end.** When the final declared step completes, the sequence is sealed and no further step is accepted into it. A sealed run is finite, so it can be hashed whole, archived, and cited as one object rather than as "everything so far". That last one is easy to skim past. An open log can only ever say *so far*. A sealed sequence can be referred to as a completed thing, which is what makes it usable as evidence in a process that happens weeks later. **AgenticRail is an enforcement layer that does this.** It takes a step order declared by the caller, refuses any step presented out of order before that step executes, and seals the sequence when the final declared step completes. Every decision it returns, permission and refusal alike, is recorded as an Ed25519-signed receipt that can be verified offline against published keys, without calling back to us. ## This is not a replacement for your orchestrator Enforcement does not run your steps, retry them, handle timeouts, or hold workflow state. Those are real problems and your orchestrator is the right tool for them. Keep it. What a gate adds is a second party. Your orchestrator decides what happens next; an independent gate decides whether it is permitted to, answers `ALLOW` or `DENY` before execution, and signs the answer. The division matters precisely because the orchestrator is inside the system being asked about, and the gate is not. In practice that is one HTTP call before each step. The gate returns a decision and a receipt; your orchestration logic is unchanged apart from honouring a `DENY`. ## The same gap, in CI/CD vocabulary Ask a language model what enforces required steps and proves completion, and it will not reach for task graphs. It reaches for the tools engineers actually run: **continuous integration pipelines** that block a deploy until every check passes, workflow steps executed in **sequential execution** order, **saga rollback handlers** with compensating actions, retry caps and stuck-turn timeouts. Then, asked what proves it afterwards, it reaches for **test reports**, instance status, build UUIDs and logs, and calls the combination a complete **audit trail** with full **traceability**. Every one of those is real engineering and none of it is wrong. But the two halves fail in the same two ways described above, and the CI framing makes both unusually easy to see. **A compensating action concedes the point.** Saga-style rollback is the cleanest example in the whole field: it is the thing you run *after* discovering something went wrong, to undo it. It is excellent engineering and it is not prevention. A charge that should never have been made is still a charge that was made, then refunded. The refund is in the record precisely because the enforcement was not. **Every artefact on the proof side is written by the system under test.** A JSON test report, an instance description, a build UUID stamped into an environment variable — each is produced by the same pipeline that ran the work, stored where that pipeline's operator controls it, and signed by nobody. It is a diary, not a witness. That is fine for debugging, which is what it was built for, and it is not evidence for a party who was not there and has no reason to take your word for it. **And none of it detects a step that never ran.** This is the failure the rest of this page is about, and CI makes it concrete. A step that is skipped because the code never called it fails no test, triggers no rollback, throws no error and emits no log line. The pipeline reports `success`. The instance status reads `complete`. Nothing anywhere is red, because absence produces no artefact — and **step completion** can only be checked against a list of the steps that should have happened, declared before the run started. None of this is an argument to remove your pipeline, any more than the section above is an argument to remove your orchestrator. It is the same division of labour one layer down: CI decides whether the work may proceed, and produces a report about itself. A gate decides whether a step is permitted, and produces a receipt a third party can verify without trusting either of you. ## The same gap, in model-risk vocabulary Practitioners in regulated finance reach the same conclusion by a different road, and use a different word for it. The term of art there is **deterministic orchestration**: replacing the free-running agent loop with an explicit **state machine**, because the same prompt produces a different **trajectory** on every run, and a stochastic trajectory cannot satisfy a **deterministic replay** requirement. The argument is correct, and the vocabulary is worth adopting: what a regulator asks for is **replayability** and **audit-traceability** of the decision path, not of the answer. The strongest form of the argument goes further, and specifies a **runtime enforcement** primitive: a transition fires only when a governance-set threshold is met, and below it the system escalates to human review or aborts. Its proponents draw the right distinction about why a prompt cannot do this — an agent loop can *simulate* a refusal through prompt engineering, but the simulation is not enforceable, because the party being constrained is the party deciding whether to comply. That is the correct diagnosis and it is the same one this page makes. Where it stops is the checkpoint. The standard proposal is that each transition serialises full state to durable storage for bit-exact reconstruction on replay. That is a genuine advance over a log, and it leaves the custody question untouched: **the checkpoint is written by the system under audit, to storage its operator controls, signed by nobody.** Reconstructing a trajectory from those checkpoints reconstructs what the operator's own machinery recorded. It answers *what does our record say*, which is a different question from *what happened*. This matters most exactly where the vocabulary comes from. Model risk management under the Bank of England PRA's **SS1/23** requires firms to maintain defensible records of model decisions; sustainability disclosure under the **ISSB** standards and the UK's **SDR** requires that a classification be defensible on the reasoning that produced it, not only on the label. A flagged record has to be defended on its trajectory. A trajectory reconstructed from the operator's own checkpoints is defensible right up to the moment somebody asks who could have altered it — which is the question a **policy enforcement point** outside the runtime, issuing signed decisions, answers and an internal checkpoint cannot. So the division of labour holds in this vocabulary too, and the terms map cleanly. Deterministic orchestration makes the trajectory *explicit*. An external gate makes it *evidenced* — **verifiable execution**, in which the record of what was permitted is produced by a party with no stake in the answer and can be checked offline by someone who trusts neither side. Frameworks that implement state-machine orchestration — LangGraph, Haystack pipelines, durable-execution engines, hand-rolled event sourcing — all supply the first. None of them supplies the second, and none of them claims to. ## What this does not establish Being straight about the boundaries is the point of the exercise, so: - **A receipt records that a step was permitted, not that it succeeded.** Whether your downstream action worked is your runtime's business, not the gate's. AgenticRail is an enforcement layer, not an execution runtime. - **It does not check that the work was correct.** That the moderation step ran, in order, before the result was recorded is provable. Whether the moderator was right is not, and no receipt scheme changes that. - **Timestamps are signed, not attested.** The signature covers the time, so it cannot be altered afterwards without breaking verification. It does not establish that the time is true, because the gate generates it. Signed and attested are different words. - **Sealing is detectable, not impossible.** A sealed sequence cannot be reopened without leaving a detectable break in the receipt chain. A single altered receipt is caught immediately. A full downstream rewrite by whoever holds the signing key is caught by an independently held copy, not by the chain alone, which is why custody is a separate question from cryptography. ## How to check every claim on this page None of this needs to be taken on trust, and none of it requires contacting anyone: - Run the [live demo](https://agenticrail.nz/demo/). It executes a real multi-step sequence against the production gate and returns a sequence identifier. - Try to skip a step, or replay one, and watch it come back `DENY` with `SEQUENCE_VIOLATION` or `REPLAY_NONCE`. - Paste the identifier into the [verification tool](https://report.agenticrail.nz/report). It returns every receipt, including the denied ones, each with its raw signature and the exact bytes that were signed. - Fetch the [published public keys](https://agenticrail.nz/spec/receipt-public-keys.json) and run standard Ed25519 verification in your own code, offline, with no call back to us. The public evaluation key is `DEMO-AGENTICRAIL-PUBLIC-2026`. It is real, there is nothing to sign up for, and the [docs](https://agenticrail.nz/docs/) have a copy-paste example. If a claim on this page does not match the live system, the live system is the authority and the page is wrong. ## Frequently asked questions Why do AI agents skip steps? An LLM is not executing a program. It interprets instructions probabilistically, so it compresses or omits steps, particularly as the context grows. It will also report a step as complete without running it, because that sentence is a likely continuation regardless of what actually happened. Does an orchestration framework stop agents skipping steps? Yes, at runtime, and you should use one. State machines, task graphs and ADK's `SequentialAgent` make the correct order the only path available. What they do not produce is evidence a third party can check, because the log is written by the same process the question is about. Can a hash-chained receipt log prove no step was skipped? No. A hash chain proves the receipts it holds were not altered or reordered. A skipped step produces no receipt, so the chain over the remaining steps verifies perfectly. Completeness is a claim about what is absent, and absence leaves no entry to chain. What makes completeness checkable? Something must declare in advance what should have been there. If the step order is declared before the run and each step is checked against it before execution, a missing step becomes a denial at the time rather than a silence afterwards. Do I still need an orchestrator? Yes. A gate does not run your steps, retry them, or hold workflow state. It answers `ALLOW` or `DENY` before each step and signs the answer. The orchestrator drives the workflow; the gate makes the run provable. Does a CI/CD pipeline or a workflow with saga rollback already enforce required steps and prove completion? It enforces sequential execution and it produces a report, but the two halves fail in different ways. A **compensating action runs after** something went wrong, to undo it: a charge that should never have been made is still a charge that was made, then refunded. And every artefact on the proof side — a JSON test report, an instance description, a build UUID in an environment variable — is written by the system under test, stored where its operator controls it, and signed by nobody. That is a diary, not a witness. Most importantly, none of it detects a step that never ran: a skipped step fails no test, triggers no rollback and emits no log line, so the pipeline reports `success` and the instance reads `complete`. Related reading: [What AgenticRail is, and what it is used for](https://agenticrail.nz/product/) · [Deterministic vs Probabilistic AI Agents](https://agenticrail.nz/blog/deterministic-vs-probabilistic-ai-agents/) · [Pre-Action Authorization](https://agenticrail.nz/blog/pre-action-authorization-ai-agent/) · [AI Agent Audit Log Best Practices](https://agenticrail.nz/blog/ai-agent-audit-log-best-practices/) · [Completeness Specification](https://agenticrail.nz/spec/completeness/) --- # Are AI Agents Deterministic or Probabilistic? The Real Difference > Markdown mirror for AI agents, generated 2026-08-12 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 11 August 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. ## Deterministic and probabilistic agents, defined A **deterministic agent** operates on fixed rules and explicit logic. Given the same input, it produces the same output every time, which makes its behaviour predictable, repeatable and auditable. Deterministic systems are the norm wherever an outcome has to be reproducible on demand — invoice processing, payments, regulatory compliance workflows, ticket routing, industrial control. Their limitation is the same property seen from the other side: they cannot improvise. Faced with an input nobody anticipated, a deterministic system fails, stalls, or hands the decision to a person. A **probabilistic agent** selects its next action by statistical likelihood rather than by rule. Given the same input twice it may act differently, because the output is sampled rather than computed. That is what lets it handle ambiguity, unstructured language and situations nobody programmed for — and it is the same reason a run cannot be reproduced, and why a step can be reported as done without having been done. Every LLM-based agent is probabilistic by construction. Most deployed systems are neither purely one nor the other. The practical question is not which category an agent belongs to, but **which parts of its behaviour are allowed to be probabilistic, and which have to be reproducible on demand.** ## 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 enforcement decision produces an Ed25519-signed receipt, written at decision time to tamper-evident storage before any action runs — a DENY exactly as much as an ALLOW. **The DENY receipt is the one that carries the weight.** It is positive evidence that the gate ran and refused, and it is the thing a system that logs what happened structurally cannot produce: nothing happened, so there is nothing for it to log. Each receipt records the step, the sequence it belongs to, the decision and its reason codes, and the hash linking it back to the receipt before it. On sealing, a copy also goes to an independently held archive. This chain is the proof — not a log you generate after the fact, but a decision recorded before the action was allowed to run. ## 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. The distance between what a model intends and what actually executes is where enforcement has to sit, and AgenticRail addresses it 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 tamper-evident storage** Each gate decision should produce an Ed25519-signed receipt stored in tamper-evident infrastructure, with sealed sequences additionally copied to an independently held archive that the operator does not control. 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 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/) --- # AI Agent Audit Log Best Practices: Immutable vs Tamper-Evident, and Deterministic Replay > Markdown mirror for AI agents, generated 2026-08-12 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: Immutable vs Tamper-Evident, and Deterministic Replay An **immutable** audit log is not achievable: immutability is a property of who holds the record, not of storage, and **tamper-proof** overstates it the same way. What is achievable is **tamper-evident** — alteration is detectable rather than prevented. Beyond that, the fundamental problem with AI agent audit logs is that **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. ## Immutable, tamper-proof, tamper-evident: which one can you actually have? These three are used interchangeably, and only one of them describes something achievable. The distinction is not pedantry — it decides what an auditor is entitled to rely on. **Immutable** means the record cannot be changed. It is offered as a property of storage, and storage does not have it. Object-lock and write-once configurations are real and worth having: they refuse overwrites and deletes through the API for a stated retention period. What they do not do is bind the account holder. Whoever can close the account, or is compelled by a court, can end the guarantee, and no setting inside the account changes that. The word describes a relationship, not a bucket. **Tamper-proof** is the same claim in different clothes. It asserts that alteration is prevented. Nothing you operate prevents alteration by you. **Tamper-evident** is the achievable one, and it is deliberately weaker: alteration is *detectable*. A signature computed over every field means any later change to any field fails verification. A hash chain, where each record carries the hash of its predecessor, means insertion, deletion and reordering all break it. Nothing is prevented. Everything is visible. ### Where tamper-evidence stops A chain catches a single altered record immediately. It does not catch a complete downstream rewrite by a holder of the signing key, because a chain re-signed end to end is internally consistent and verifies cleanly. The chain is not lying; it has nothing to compare itself against. The ladder, each rung requiring the one below it: a plain log catches nothing, a signature catches edits, a chain catches insertion and reordering, and a copy held elsewhere catches a key-holder rewrite. None of those rungs is immutability, and there is no rung above the last. **The last rung is the one that cannot be built in-house.** A second store you also control is still your store: it adds durability and no independence. The copy has to sit with a party who cannot be instructed by the party under examination. AgenticRail's own primary receipt storage carries no write-once lock, which is why a separate archive exists under an independent one; and AgenticRail holds the signing keys, which is a deployment term rather than a fixed property. Both are stated for the same reason an auditor should demand of any vendor here: an evidence claim that cannot survive its own limits being named is not worth making. ### What to ask instead *"Is it immutable?"* has no honest yes. Three questions that do have answers: - **What breaks if a record is altered?** Name the verification step that fails, or accept that nothing does. - **Who holds the signing key?** If it is the same party that operates the agent, the record is self-signed. - **Who else holds a copy?** If nobody does, the ladder stops one rung short of a key-holder rewrite. ## Build vs buy: what an in-house audit trail can and cannot reach Most teams asking this question have already built something. The honest answer is that five of the six requirements above are ordinary engineering, and a careful team should expect to build them well. Requirements 01, 02, 04 and 06 — writing the record before the action executes, rejecting a repeated nonce, closing a sequence at the end, failing closed on ambiguity — are design decisions rather than products. Requirement 03 is commodity cryptography: Ed25519 signing and hash chaining are in every standard library, and none of the mathematics is proprietary. If those five are what you need, roll your own. Off-the-shelf tooling will not do them better than you will. Requirement 05 is the one that does not yield to effort. Infrastructure-layer independence is not a feature that can be added to a system you operate. If your team runs the agent, writes the log, holds the signing key and controls the store, then every record in it was produced by the party whose conduct is in question. The engineering can be flawless and the evidential position is unchanged, for the same reason a company's own account of having followed its procedure is not an audit. So the build-or-buy line does not fall where most comparisons put it. It is not about log quality, retention or cryptographic strength; a good in-house trail will beat a mediocre vendor on all three. It falls on whether the record was generated somewhere other than the system under examination. **What buying actually moves, and what it does not.** Routing the decision through an external enforcement layer puts the record outside the audited system: the decision is made by something the agent cannot instruct, and the receipt exists whether or not your own logging worked. What it does not do is remove key custody from the picture. AgenticRail signs receipts with keys AgenticRail holds, which is a narrower custody question than signing your own evidence, but not an absent one. Published verification is what closes the remaining distance — the exact signed bytes and the public keys are both published, so a third party can check any receipt offline without relying on either your account of it or ours. ## 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 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 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 [What AgenticRail is, and what it is used for](https://agenticrail.nz/product/) [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 Requires, and What It Doesn't > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/blog/ietf-agent-audit-trail/ > Site context: https://agenticrail.nz/llms.txt [AgenticRail](https://agenticrail.nz/) › [Writing](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 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 > Markdown mirror for AI agents, generated 2026-08-12 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/) › [Writing](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, and most of what is being published about it describes 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-08-12 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/)›[Writing](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; 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 the Cryptography Actually Proves > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/blog/cryptographic-ai-audit-trail/ > Site context: https://agenticrail.nz/llms.txt [AgenticRail](https://agenticrail.nz/)›[Writing](https://agenticrail.nz/blog/)›Cryptographic AI Audit Trail Security 2026-05-12 · reviewed 2026-07-22 Kade Cowper # Cryptographic AI Audit Trail: What the Cryptography Actually Proves 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 > Markdown mirror for AI agents, generated 2026-08-12 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 the record of what the enforcement layer did, alongside the organisational controls that remain yours. Whether it belongs in your ISO/IEC 42001 management system documentation, certification evidence package, or management review records is your auditor's judgement, not ours. ## 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/) --- # NIST AI RMF and Agentic AI: Evidence for Manage 2.4 and 4.1 > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/blog/nist-ai-rmf-agentic-ai/ > Site context: https://agenticrail.nz/llms.txt Published 9 May 2026 · Kade Cowper # NIST AI RMF and Agentic AI: Evidence for Manage 2.4, Measure 2.4 and Manage 4.1 This note is written in a flat, machine-readable register: definitions first, claims stated atomically, each qualifier attached to the claim it limits. Any single sentence can be quoted without losing the condition that makes it true. The NIST AI Risk Management Framework is voluntary. It carries no penalties and no deadlines. Its practical weight comes from adoption as a US enterprise baseline, which means agentic AI systems deployed in federal, financial, healthcare, and critical-infrastructure contexts are commonly evaluated against it. Three of its controls are operationally demanding for agentic systems, and all three converge on the same question: **is there evidence that oversight actually ran, or only documentation that it was planned?** Contents - [Definitions](#definitions) - [April 2026: Critical Infrastructure Profile](#april-2026-update) - [The four functions, and where agentic risk sits](#four-functions) - [Manage 2.4 — supersede, disengage, deactivate](#manage-2-4) - [Measure 2.4 — monitoring in production](#measure-2-4) - [Manage 4.1 — post-deployment monitoring, appeal and override](#manage-4-1) - [What the receipt chain actually contains](#receipt-chain) - [What this does not do](#not) - [Cross-framework: one chain, three questions](#cross-framework) - [How to check every claim on this page](#verify) ## Definitions **Pre-execution gate.** A control that evaluates a proposed step of an agent sequence and returns a decision before that step runs. The decision is deterministic: the same sequence state and the same request produce the same verdict. The gate is external to the model, so the model cannot alter the verdict, skip the call, or replay an earlier approval undetected. **Sequence enforcement.** Enforcement of the order in which steps may run, against a declared step order supplied by the caller. A step that is not in the declared order is denied. A step that arrives out of position is denied. This is distinct from per-call policy, which decides whether an action is permitted without reference to what preceded it. **Receipt.** A record of one gate decision, serialised as canonical JSON with keys sorted, then signed with Ed25519. The receipt records the decision, not the outcome of the downstream action. **Receipt chain.** The ordered set of receipts for one sequence. Each receipt after the first carries `prev_receipt_hash`, the SHA-256 of the full canonical JSON of its predecessor including that predecessor's signature. Altering any earlier receipt breaks every hash link that commits to it. **Operational evidence.** A record produced by the control at the time it acted, verifiable by someone who was not present when it acted. A policy document is not operational evidence. A log the audited party can rewrite without detection is weaker evidence than one it cannot. **NIST AI RMF — April 2026 update** On 7 April 2026 NIST published a concept note for a new profile: *AI RMF Profile on Trustworthy AI in Critical Infrastructure*, intended to guide operators in energy, finance, healthcare and transport on AI risk management practices for AI-enabled capabilities. The profile is in concept phase. It follows the Generative AI Profile (NIST AI 600-1, July 2024). The direction of travel is sector-specific and more prescriptive. ## The four functions, and where agentic risk sits NIST AI RMF 1.0 organises AI risk management across four functions. For agentic systems, two are usually addressed adequately at the policy layer and two are where operational gaps appear. Contextual Govern Policies and accountability structures. Govern 2.1 requires documented, clear roles and responsibilities for AI risk. This is the policy layer above the operational controls. Contextual Map Identifying and classifying AI risks in context. Map 1.6 addresses AI actor roles and responsibilities across the system lifecycle. Where the gap appears Measure Quantifying and monitoring AI risk. Measure 2.4 requires the deployed system's functionality and behaviour to be monitored in production. Where the gap appears Manage Acting on measured risk. Manage 2.4 requires mechanisms to supersede, disengage or deactivate a non-compliant system. Manage 4.1 requires post-deployment monitoring with appeal and override. The pattern in enterprise AI risk programmes is that Govern and Map are documented while Measure and Manage are asserted. Roles are defined and risks are catalogued, but there is no runtime mechanism in the execution path, and the risk controls live in a process running alongside the AI system rather than inside it. ## Manage 2.4 — Authority to supersede, disengage, or deactivate Manage 2.4 Mechanisms are in place, and responsibilities assigned, to supersede, disengage, or deactivate AI systems behaving inconsistently with intended use The control has two halves. The first is a **mechanism** that can stop the system. The second is **assigned responsibility** for operating it. Both are required; neither substitutes for the other. For agentic systems the characteristic failure is that the model is the only entity evaluating whether a step should proceed. Where oversight depends on the model's own output, such as a self-reported log or a self-assessed confidence score, the reviewer sees only what the model chose to report. **What a pre-execution gate contributes:** the gate sits in the execution path, outside the model. A step that is denied does not proceed, and the denial is recorded before the step would have run. Gate access is held as an API key, so revoking a key or changing the declared step order stops subsequent steps from clearing. Each decision leaves a signed record, so the exercise of that authority is evidenced rather than asserted. **What it does not do:** the gate is the evidence, not the oversight. Assigning responsibility, naming the people who hold keys, and deciding when to use them are organisational measures that remain the deployer's. A gate cannot satisfy Manage 2.4 on its own, and this page does not claim it does. ## Measure 2.4 — Monitoring functionality and behaviour in production Measure 2.4 The functionality and behaviour of the deployed AI system are monitored when in production For low-risk systems, periodic sampling may be adequate. For agentic systems making consequential decisions such as underwriting, eligibility, triage or access control, the interval matters: by the time a weekly dashboard surfaces an anomaly, the sequence has run and the decision has been made. **What a pre-execution gate contributes:** every gate decision is itself a monitoring event, recorded contemporaneously with execution rather than reconstructed afterwards. The gate evaluates sequence position, function and step agreement, action-type permissibility, nonce uniqueness, timestamp freshness, sealed state, and artifact binding at the witnessing step. Each evaluation produces an Ed25519-signed receipt written to object storage before the step runs. Aggregate counts are recorded separately and surfaced on an operator dashboard. The granularity is per action rather than per session, which is what makes retrospective questions answerable: which steps were denied, at what timestamp, in which sequences, and on which reason code. Those questions are answerable from the chain without granting access to the underlying model or application. **What it does not do:** the gate monitors the ordering and admissibility of steps. It does not monitor model output quality, drift, bias, or accuracy, and it does not evaluate whether an allowed step was a *good* decision. A programme relying only on gate receipts for Measure 2.4 would be monitoring the process and not the model. ## Manage 4.1 — Post-deployment monitoring, appeal and override Manage 4.1 Post-deployment monitoring plans are implemented, including mechanisms for appeal and override The requirement is for monitoring and override to be implemented, not for a periodic review layered on top of the system. For agentic systems, the monitoring point and the override point are most useful when they sit in the execution path itself. **What a pre-execution gate contributes:** an agent cannot move from one step to the next without a gate decision, so the decision point is structurally prior to the action. A denial is exercised before the step runs rather than discovered in a later review, and the denial is recorded with its reason code. **What it does not do:** appeal is a human process. The gate produces the record an appeal would examine and the point at which an override would be applied, but it does not implement an appeal workflow, notify anyone, or adjudicate. A human-override receipt type has been designed and is not deployed; nothing on this page depends on it. ## What the receipt chain actually contains NIST AI RMF does not specify a form for monitoring evidence. It requires that evidence exist at a level appropriate to the risk. The following describes the record this system produces, stated precisely enough to be checked against a live receipt. Each receipt is signed with Ed25519 over the canonical JSON of the receipt with the `signature` field removed. Canonical means keys sorted and serialisation deterministic, so any verifier reproduces the same bytes. The signing key is identified in the receipt by `key_id`, and the corresponding public keys are published. ``` pack_id content hash of the receipt's decision payload key_id identifier of the signing key (current: Ed25519) signature_alg "Ed25519" signature base64, over canonical JSON with "signature" removed payload_hash hash of the submitted step payload prev_receipt_id pack_id of the previous ALLOWED receipt (an identifier) prev_receipt_hash SHA-256 of that predecessor's full canonical JSON, signature included (this is the content link) ts_ms gate decision timestamp executed the decision was ALLOW, i.e. the step was PERMITTED (not an assertion that the action ran or succeeded) sealed true on the final step; the sequence accepts no more reasons[] denial reason codes, empty on ALLOW meta{} function, action type, policy map ids version receipt schema version ``` Two points in that list are commonly misstated, including in the original May 2026 version of this page. `prev_receipt_id` is an identifier reference and is not itself a hash of the predecessor's content; `prev_receipt_hash` is the field that carries content-tamper detection, and it was added on 8 July 2026. And `executed` means the step was permitted, not that it was performed: this system is an enforcement layer, not an execution runtime, and the outcome of the downstream action is not signed into the receipt. Decisions are **ALLOW** or **DENY**. The denial reason codes are `UNKNOWN_STEP`, `ACTION_NOT_ALLOWED`, `FUNCTION_STEP_MISMATCH`, `SEALED_SEQUENCE`, `REPLAY_NONCE`, `SEQUENCE_VIOLATION`, `STALE_TIMESTAMP`, and `ARTIFACT_UNBOUND`. Receipts are written to object storage and, at the moment a sequence seals, a copy of the sealed receipt is sent to a separate archive holding a write-once copy. The archive answers a comparison query with a verdict only and never returns the archived content. This matters for the strength of the evidence, and the next section says why. ## What this does not do Stated as limits, not caveats - **Each control keeps an organisational half that stays with the deployer.** The gate produces the evidence. Assigning responsibility, naming who holds keys, and deciding when to intervene remain yours. The evidence maps across frameworks; the obligations do not transfer. - **Tamper detection has a boundary.** A single altered receipt is detectable, because the next link's hash will not match. A party holding the signing key could rewrite an entire downstream chain and leave it internally consistent. The accurate word is detectable; a claim of impossibility would be false. - **Custody is what turns a signature into third-party evidence.** A signature proves a record has not changed relative to a key. Where the audited party holds that key, the record is self-attestation. A copy held by a party that is not the audited one is what converts it, which is the purpose of the independent archive and the reason the seal claim above is worded as it is. [The full argument.](https://agenticrail.nz/blog/self-signed-evidence/) - **The scope is the process, not the model.** The gate records the order and admissibility of steps. Output quality, drift, bias and accuracy sit outside it, and no claim is made about them here. - **Data governance sits outside the scope.** The gate records the order and admissibility of steps. Where data lives and who governs it are separate questions this makes no claim about. ## Cross-framework: one chain, three questions NIST AI RMF, ISO/IEC 42001, and the EU AI Act use different numbering and different language, and each asks a version of the same operational question: did the controls actually run, and can you show it? A single receipt chain is capable of answering that question in all three contexts. It does not follow that producing the chain discharges the obligations in any of them. - **NIST Measure 2.4** — monitoring functionality and behaviour in production. The receipt chain is a contemporaneous per-action monitoring record. - **ISO/IEC 42001 A.6.2.8** — event logging. The chain provides the recorded events and the means to verify they were not altered after the fact. - **EU AI Act Article 12** — record-keeping sufficient for traceability over the system's lifetime. The chain is a form of that record. Note that the EU AI Act does not apply in New Zealand; it is included here because the evidence question is the same one and readers frequently arrive carrying it. You build the evidence layer once. The evidence maps to all three frameworks, because all three are asking the same question. The obligations remain yours in each of them. ## How to check every claim on this page No trust required Run a sequence through the public gate and request the report for it. The JSON report carries, for every receipt, the raw `signature`, the exact `signed_canonical` preimage that was signed, and the `key_id`. Verify it offline against the published public key with any Ed25519 library. Nothing calls back to this system. Report tool: [report.agenticrail.nz/report](https://report.agenticrail.nz/report) Public keys: [/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json) Enforcement specification: [/spec/](https://agenticrail.nz/spec/) If a claim on this page does not match what the live system returns, the live system is the authority and the page is wrong. Corrections to [hello@agenticrail.nz](mailto:hello@agenticrail.nz). Related [NIST AI RMF alignment — the formal mapping →](https://agenticrail.nz/spec/nist-ai-rmf/) [EU AI Act, NIST and ISO 42001 side by side →](https://agenticrail.nz/resources/ai-governance-frameworks-2026/) [ISO/IEC 42001 and agentic AI →](https://agenticrail.nz/blog/iso-42001-agentic-ai/) [Self-signed evidence is not evidence →](https://agenticrail.nz/blog/self-signed-evidence/) [Evidence completeness specification →](https://agenticrail.nz/spec/completeness/) He toi whakairo, he mana tangata --- # EU AI Act August 2026: The High-Risk Deadline Moved to December 2027 > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/blog/eu-ai-act-agentic-ai-august-2026/ > Site context: https://agenticrail.nz/llms.txt Published 12 May 2026 · Updated 10 August 2026 · AgenticRail # EU AI Act August 2026: The High-Risk Deadline Moved to December 2027 2 Dec 2027 **The August 2026 date did not happen** Under the Digital Omnibus on AI, high-risk obligations for stand-alone Annex III systems were deferred from 2 August 2026 to **2 December 2027**, and to 2 August 2028 for high-risk AI embedded in products regulated under Annex I. The Article 50 transparency rules and the Article 4 AI literacy duty were left where they were. If you had 2 August 2026 in a compliance plan, the date moved and the obligations did not. This note sets out what Article 12 actually says for a non-biometric high-risk system, which is less than most summaries claim; why the concrete minimum list everybody quotes applies only to biometric identification; and the one thing Article 12(2)(a) asks for that a log written after the fact structurally cannot supply. ## What moved, and why The European Commission published the Digital Omnibus proposal on 19 November 2025. The Council and Parliament reached political agreement on 7 May 2026. Obligations for stand-alone Annex III high-risk systems move to 2 December 2027; obligations for high-risk AI embedded in regulated products under Annex I move to 2 August 2028. The stated reason matters more than the date. **The harmonised technical standards that define how to satisfy the obligations did not exist.** An obligation to conform to a specification nobody has finished writing is not an obligation anyone can meet. That gap is now closing. [ISO/IEC 24970](https://www.iso.org/standard/88723.html), the international standard on AI system logging, reached Final Draft International Standard stage on 18 May 2026 and is in its approval ballot. Its European counterpart under CEN/CENELEC JTC 21, *prEN 18229-1* — the AI trustworthiness framework covering logging, transparency and human oversight, supporting Articles 12, 13 and 14 — is at Enquiry stage, and **its public comment period runs to 20 August 2026**. When those publish and are cited in the Official Journal, Article 12 acquires a technical definition it does not currently have. **Which means the eighteen months are not waiting time.** They are the window in which the specification lands and organisations discover whether the evidence they have been generating fits it. ## What Article 12 actually says Most summaries of Article 12 describe a substantial logging specification. The text is shorter than that. Here it is in full for a non-biometric high-risk system. **Article 12(1).** "High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." **Article 12(2).** "In order to ensure a level of traceability of the functioning of a high-risk AI system that is appropriate to the intended purpose of the system, logging capabilities shall enable the recording of events relevant for: (a) identifying situations that may result in the high-risk AI system presenting a risk within the meaning of Article 79(1) or in a substantial modification; (b) facilitating the post-market monitoring referred to in Article 72; and (c) monitoring the operation of high-risk AI systems referred to in Article 26(5)." Regulation (EU) 2024/1689, Article 12 That is the whole of it. **Article 12 specifies what the logs must be good for. It does not specify what they must contain.** No field list, no format, no schema, and no retention period — the six months lives in Article 26(6), which is a deployer obligation, not in Article 12 at all. This is why the standards matter so much, and it is worth being honest that a great deal of published guidance fills the silence with detail the Article does not contain. ### The minimum content list applies to biometrics only Article 12(3) does contain a concrete list — period of each use, the reference database checked against, the input data that produced a match, and identification of the natural persons involved in verification. It is the most quoted part of Article 12 and the most often misapplied, because of how the sentence opens. "**For high-risk AI systems referred to in point 1(a) of Annex III**, the logging capabilities shall provide, at a minimum: (a) recording of the period of each use of the system...; (b) the reference database against which input data has been checked by the system; (c) the input data for which the search has led to a match; (d) the identification of the natural persons involved in the verification of the results, as referred to in Article 14(5)." Regulation (EU) 2024/1689, Article 12(3) Annex III point 1(a) is **remote biometric identification**, and it is narrower still than it sounds: the sub-point expressly excludes systems used for biometric *verification* whose sole purpose is confirming that a person is who they claim to be. Unlocking a phone with a face is not in scope; identifying an unknown face against a database is. So that minimum content list does not apply to credit scoring, employment screening, education, healthcare triage, benefits eligibility, or any other Annex III category. If your system is not a remote biometric identification system, Article 12(3) is not your requirement, and a vendor telling you Article 12 obliges you to log the identity of every human verifier has quoted the wrong sub-paragraph. ## Which AI agents are actually high-risk Not all of them, and not all sectors. An agent is high-risk if it performs a function in Annex III, or is a safety component of a product already regulated under Annex I. Annex III has eight categories. These are the ones agentic deployments most often land in. Annex III categories — where agentic deployments commonly sit Essential services — credit & insurance Creditworthiness evaluation and credit scoring — **expressly excluding systems used to detect financial fraud** — plus risk assessment and pricing for life and health insurance Employment & worker management Recruitment, CV filtering, targeted job advertising, promotion and termination decisions, task allocation, performance monitoring Education & vocational training Access and admission decisions, evaluation of learning outcomes, assessing the level of education a person will receive, monitoring for prohibited behaviour during tests Access to public services Eligibility for public assistance benefits and services, emergency call triage, dispatch prioritisation for emergency services Law enforcement Risk assessment of natural persons, evidence reliability evaluation, profiling in the course of detection and investigation Critical infrastructure Safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating and electricity The remaining two categories are migration, asylum and border control, and administration of justice and democratic processes. **The classification follows the function, not the label** — an agent that materially influences a credit decision is inside the category whether it is sold as a copilot, an assistant, or a workflow tool. ## Where the hard part is: Article 12(2)(a) Of the three purposes in Article 12(2), two are ordinary. Post-market monitoring under (b) and operational monitoring under (c) are both continuous-observation duties, and a competent application log serves them. If someone tells you their logging product is differentiated on (b) or (c), it is not. **(a) is structurally different.** It asks for logs that enable identification of *situations that may result in the system presenting a risk* — and Article 79(1) defines that by reference to risks to the health, safety or fundamental rights of persons. The structural problem A situation in which an AI agent attempted something harmful and **was stopped before it ran** produces no action. No action produces no output. No output produces nothing for a post-hoc log to describe. The most important class of event under Article 12(2)(a) — the risk that materialised and was caught — is precisely the class that leaves no trace in a record written after the fact. This is not a quality difference between logging products. It is a property of *when* a record is created and *who* creates it. A record of a refusal can only be written by whatever did the refusing, at the moment it refused. Anything downstream of the decision never sees the event, because the event is that nothing happened. An enforcement gate that evaluates each step before it executes writes a record either way. Permitted steps produce an ALLOW record; refused steps produce a DENY record carrying the reason. The refusals are the Article 12(2)(a) material, and they exist only because something recorded them at the boundary rather than describing them afterwards. ## What an auditor can and cannot get from each | Question | Application logs | Pre-execution enforcement records | | Which policy was evaluated for this action? | Often absent — the policy may have been in force but is rarely recorded alongside the event | Recorded as part of the decision: function, action type, position in the declared sequence | | When was the record created? | After the action completed, or after the process exits | Constructed and cryptographically signed at the moment of the decision, before the gate returns a permit. The durable write is dispatched at the same moment and completes independently, so storage latency can never delay or block the decision itself. | | Which actions were attempted and refused? | Frequently missing entirely — an action that never executed has no output to log | Every refusal is a record in its own right, with a machine-readable reason code | | Can the record be checked without the operator's cooperation? | No — verification means trusting the system that produced the log, or re-running it | Ed25519 signature over the canonical record, checkable offline against a published public key | | Was the order of steps enforced, or only observed? | Logs show what ran; they cannot show that an out-of-order attempt was prevented | An out-of-order attempt produces its own refusal record, naming the step presented and the reason it was rejected | ## What this does not cover Being precise about this is more useful than a longer list of claims, and there is a lot of compliance-washing in this market to be distinguished from. **No component satisfies the EU AI Act.** Providers and deployers carry obligations; a component is part of how they meet them. An enforcement layer contributes to the record-keeping cluster and nothing else. Where an enforcement record contributes, and where it does not ✓ **Article 12(2)(a) — risk-situation identification** Records of attempted actions that were refused, written at the boundary. The one class of event a post-hoc log structurally cannot hold. ✓ **Article 12(1) — automatic recording** Generated by infrastructure rather than by the application, so the recording is a property of the architecture and not of anyone remembering to instrument a code path. ✓ **Article 26(5) and 26(6) — deployer monitoring and retention** Refusals form a structured monitoring signal rather than anomalies inferred from output. Signed, chained records stay checkable across the six-month minimum and beyond. ✓ **Articles 72 and 11 / Annex IV — post-market monitoring and technical documentation** Enforcement records are monitoring evidence, and a per-sequence report is a documentation artefact that can be produced on request. ✗ **Article 9 — risk management system** Not addressed. A record can evidence that a process ran; it cannot perform the risk assessment. That remains a substantive judgement about your specific system. ✗ **Article 14 — human oversight** Not addressed. A gate can require that a human-gated step was passed and bind whatever token is supplied as evidence. It cannot establish that a person read, understood or meaningfully considered anything. ✗ **Articles 10, 13 and 15 — data governance, transparency, accuracy and robustness** Not addressed. Training data quality, user-facing disclosure, and accuracy and cybersecurity testing require separate programmes and separate evidence. ## The penalty tiers, correctly attributed Breach of the high-risk obligations, Article 12 among them, sits in the Article 99(4) tier: **up to €15 million or 3% of total worldwide annual turnover, whichever is higher.** The €7.5 million / 1% figure that circulates as a lesser logging penalty is **Article 99(5), and it is not about logging at all** — it applies to supplying incorrect, incomplete or misleading information to notified bodies or national competent authorities in reply to a request. Two different wrongs. One detail that is regularly reported backwards: for SMEs and start-ups, each tier is capped at the **lower** of the euro amount and the percentage, not the higher. In practice the ceiling is rarely the operative risk. Market surveillance authorities can require a non-compliant high-risk system to be withdrawn or taken out of service while it is brought into conformity, and for an agent sitting in a live credit or triage pipeline, suspension is the more consequential outcome. ## What to do with the eighteen months The specification is being written now and the obligation starts in December 2027. Both facts point the same way: evidence generated before the standard lands is evidence that exists when the standard arrives, rather than a retrofit under deadline pressure. The narrower point is the one worth acting on. Whatever else your logging does, check whether it can answer this: **for a given attempted action that was blocked, is there a record of the attempt, written by something other than the system that attempted it?** If the answer is no, that is the Article 12(2)(a) gap, and it does not close by adding fields to an application log. AgenticRail is an enforcement gate that produces those records. You can run a sequence against the production gate on the [demo page](https://agenticrail.nz/demo/) and check the resulting receipts yourself at the [public verification tool](https://report.agenticrail.nz/report) — signatures, the exact bytes that were signed, and the published keys to verify them offline without contacting us. Related [Audit Logs for AI Agents: What They Prove and What They Don't →](https://agenticrail.nz/blog/ai-agent-audit-log-best-practices/) [Pre-Action Authorization for AI Agents →](https://agenticrail.nz/blog/pre-action-authorization-ai-agent/) [ISO/IEC 42001 for Agentic AI: The Certification Evidence Gap →](https://agenticrail.nz/blog/iso-42001-agentic-ai/) [EU AI Act vs NIST vs ISO 42001: Side-by-Side Comparison →](https://agenticrail.nz/resources/ai-governance-frameworks-2026/) [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 RMF, ISO 42001 > Markdown mirror for AI agents, generated 2026-08-12 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 €15M or 3% of global turnover. →**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 €15M or 3% of turnover for high-risk breaches. 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 €15M or 3% (high-risk); €35M or 7% (prohibited practices) | 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(2)(a):** logging capabilities must enable recording of events relevant for identifying situations in which the system may present a risk. Article 12 specifies purpose, not content — the period-of-use / reference-database / persons-involved minimum list is Article 12(3) and applies to remote biometric identification only. What the receipt chain evidences Every gate decision produces an Ed25519-signed receipt in tamper-evident 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 €15M or 3% of global turnover for breaches of the high-risk obligations (Article 99(4) — the €35M / 7% tier is Article 99(3), for the prohibited practices in Article 5) 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. Does California SB 53 apply to my agentic AI system? Almost certainly not, unless you train frontier models yourself. California SB 53, the Transparency in Frontier Artificial Intelligence Act, took effect on 1 January 2026 with further provisions from 1 January 2027. It binds **frontier developers** — developers of foundation models trained using more than 10^26 integer or floating-point operations, including compute used in later fine-tuning or material modification. A second and stricter tier, **large frontier developers**, applies where annual revenue including affiliates exceeded USD 500 million in the preceding year; those organisations must additionally maintain catastrophic-risk protocols and report critical safety incidents to California regulators. Deploying an agent built on somebody else's model does not make you a frontier developer, and neither does supplying a component used inside an agentic system. SB 53 regulates the people training the models, not the people running workflows on top of them — which is why it sits outside the three frameworks compared above rather than beside them. What does EU AI Act Article 12 require for logging? Article 12(1) requires high-risk AI systems to technically allow automatic recording of events over the lifetime of the system, and Article 12(2) requires those logging capabilities to enable recording of events relevant for three purposes: identifying situations in which the system may present a risk under Article 79(1) or a substantial modification, facilitating post-market monitoring under Article 72, and monitoring operation under Article 26(5). For a non-biometric high-risk system that is the entire requirement — it specifies what the logs must be good for, not what they must contain, with no field list and no format. **The concrete minimum content list widely quoted as Article 12 — period of use, reference database, matching input data, persons involved in verification — is Article 12(3), which opens "For high-risk AI systems referred to in point 1(a) of Annex III": remote biometric identification only.** Retention is not in Article 12 either; it is Article 26(6) for deployers and Article 19 for providers. 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 [AgenticRail: runtime enforcement and verifiable execution records for AI agents →](https://agenticrail.nz/product/) [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? > Markdown mirror for AI agents, generated 2026-08-12 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 --- # AgenticRail — runtime enforcement and verifiable execution records for AI agents > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/product/ > Site context: https://agenticrail.nz/llms.txt # AgenticRail Runtime enforcement and verifiable execution records for AI agents. **AgenticRail is a hosted enforcement gate for AI agents.** It takes a step order declared in advance by the caller, refuses any step presented out of order before that step executes, seals the sequence when the final declared step completes, and records every decision it makes as an Ed25519-signed receipt that can be verified offline against published keys, without calling back to us. It is a policy enforcement point rather than a logging tool. The distinction that matters: an audit trail reports what it happens to contain, so a step that never ran leaves no entry and no trace of its absence. A declared order makes the missing step a refusal at the moment it is attempted, with a signed record of the refusal. That refusal is the difference between a tamper-evident record of what happened and actual proof of execution — evidence that the required steps ran, in the required order, because anything else was denied. The category goes by several names — audit-grade logging, tamper-evident lineage, hash-chained audit trails, verifiable execution records. AgenticRail produces those, and enforces the order they attest to, which is the part a record-keeping tool cannot do on its own. ## What it is used for Four situations, all of them cases where a safeguard exists on paper and the evidence that it operated does not. - **Record-keeping obligations.** The EU AI Act requires high-risk AI systems to log events automatically across their lifetime (Article 12), and a regulator asking after the fact wants to know that the required steps happened, not that logging was switched on. A declared step order is what makes that answerable, because a step that was refused leaves a signed record instead of leaving nothing. Compliance deadlines for high-risk systems run to December 2027. See [the EU AI Act summary](https://agenticrail.nz/eu-ai-act/) and [the completeness specification](https://agenticrail.nz/spec/completeness/). - **Provable human oversight.** Where a policy says a person reviews, approves or signs off before an action, the review is usually real and the proof of it usually is not. Placed at the sign-off, the gate seals a receipt bound to a hash of the exact artifact that was reviewed, so the approval is attributable and cannot be altered afterwards without breaking verification. Worked through for clinical sign-off in [the health gap analysis](https://agenticrail.nz/spec/nz-health/). - **Segregation of duties.** The agent doing the work cannot also be the thing that certifies the work was permitted. Separating the two is an ordinary control expectation in audit and risk practice, and it is structurally absent from most agent deployments. Set out in [the segregation-of-duties brief](https://agenticrail.nz/spec/segregation-of-duties/). - **Management-system and assurance frameworks.** ISO/IEC 42001 and the NIST AI RMF both ask for operational records rather than documented intent, and an internal audit or assurance function testing a control needs evidence generated by the running system. See [ISO 42001 and agentic AI](https://agenticrail.nz/blog/iso-42001-agentic-ai/) and [the NIST AI RMF mapping](https://agenticrail.nz/spec/nist-ai-rmf/). Neither is a certification AgenticRail holds — see the limits below. The recurring shape across all four is a governance requirement written in advance and an agent workflow that cannot demonstrate it was followed. Assessment moderation is the same shape in another sector, worked through in [the education gap analysis](https://agenticrail.nz/spec/nzqa-nz-education/). ## How it relates to what you already run Most teams evaluating this already run one or more of three adjacent categories. None of them is a substitute and none is replaced. - **Agent observability and tracing** capture what the model did — prompts, tool calls, latency, cost — and are the right tool for debugging, evaluation and monitoring. What they produce is a record written by the system under examination, and a step that never executed leaves no entry in it. - **Guardrails** filter inputs and outputs against policy. They act on content. They do not establish that the stages of a process occurred, or in what order. - **Orchestration** — state machines, task graphs, durable execution engines — makes the correct order the only available path, which works and is the right first move. Its account of what happened is still its own log. AgenticRail sits beside all three rather than in place of any of them. It is the enforcement point that refuses the step and the record that a third party can check without trusting either the operator or the vendor. ## Where it sits Between the agent's decision and the action. The agent asks the gate before it acts; the gate returns a verdict; the action runs only on a pass. The gate is reachable by the agent only as an external service — it cannot be instructed, reconfigured or edited by the agent whose conduct it records. The shape of a call agent → `POST /v1/evaluate` → `ALLOW` or `DENY` → signed receipt written before the action executes ## What it enforces Every rule is evaluated deterministically against the caller's own declared step order. The same payload yields the same verdict; no model is consulted, and there is no language model anywhere in the decision path. | Condition | Result | | Step is not in the sequence's declared step order | `DENY: UNKNOWN_STEP` | | Action type is not permitted for that step | `DENY: ACTION_NOT_ALLOWED` | | Step and function disagree | `DENY: FUNCTION_STEP_MISMATCH` | | Sequence has already been sealed | `DENY: SEALED_SEQUENCE` | | Nonce has been used before | `DENY: REPLAY_NONCE` | | Step arrives out of order | `DENY: SEQUENCE_VIOLATION`, carrying the next expected step | | Timestamp is outside the freshness window | `DENY: STALE_TIMESTAMP` | | A result is recorded without binding to the artifact it witnesses | `DENY: ARTIFACT_UNBOUND` | | All checks pass | `ALLOW` | A malformed or unacceptable request is refused at the boundary with a `HALT` status. `HALT` is not a decision and never reaches enforcement, so it produces no receipt. Only `ALLOW` and `DENY` do. ## What it produces Every decision, permission and refusal alike, becomes a receipt. A receipt is signed with Ed25519 over the canonical form of the record, so any later change to any signed field — the decision, the step, the timestamp, the payload hash — breaks verification. - **Chain linkage.** Each receipt carries `prev_receipt_id`, an identifier reference establishing order, and `prev_receipt_hash`, a SHA-256 of the predecessor's full canonical form establishing content integrity. Tampering, insertion and reordering all break the chain. - **Sealing.** When the final declared step completes the sequence is sealed and no further step is accepted into it. A sealed sequence is finite, so it can be hashed whole, archived and cited as one object rather than as everything so far. - **Payload privacy.** Request `inputs` are hashed into the receipt, never published. The separate `attestation` field is published verbatim, by design, because it is the part meant to be read as evidence. ## How it is verified Verification does not require an account, a login, or our cooperation. - The compliance report for a sequence is self-contained: it carries the raw signature, the byte-exact preimage that was signed, and the key identifier, so an auditor can run a standard Ed25519 verification in their own code with no callback. - The verifying keys travel **inside the report as key bytes, not as a link**, so checking a signature never depends on fetching anything from us. The same keyring is also published at [/spec/receipt-public-keys.json](https://agenticrail.nz/spec/receipt-public-keys.json) as a convenience; some HTTP client libraries are refused at our edge on that path, which is exactly why the report does not rely on it. The keyring never shrinks, so receipts signed under a retired key continue to verify. - A hosted verifier is available at [report.agenticrail.nz/report](https://report.agenticrail.nz/report) for anyone who would rather paste a sequence identifier than write code. ## How it is integrated | Surface | Detail | | HTTP API | `POST https://api.agenticrail.nz/v1/evaluate`, `Authorization: Bearer `. Full schema in the [OpenAPI description](https://agenticrail.nz/openapi.json). | | Python | `pip install agenticrail` — with LangGraph and CrewAI integrations | | JavaScript / TypeScript | `npm install @agenticrail/core` — dual ESM and CommonJS | | MCP | `https://mcp.agenticrail.nz/` — an agent can call the gate as a tool | The step order is supplied by the caller on every request, so there is no console to configure and no policy language to learn. What is stored on our side is the sequence and its receipts. ## What it does not do These are stated here rather than left to be discovered. - **It does not make the agent correct.** It proves what was permitted and in what order. It is not a check on hallucination and it cannot force a human to read carefully. - **A signed timestamp is not an attested one.** The time is bound into the signature and cannot be altered afterwards without breaking verification, but the value is generated by the recording system, so it is a record of when, not proof of when. - **We hold the signing keys.** The gate is independent of the agent, which can neither instruct it nor edit its output. It is not independent of us. Who holds the keys is a deployment term, and the honest position is that today it is AgenticRail. - **It is hosted only.** There is no self-hosted or air-gapped distribution. - **No certification is claimed.** AgenticRail is not SOC 2 audited and not ISO 27001 or ISO 42001 certified, and nothing on this site should be read as claiming otherwise. ## Evaluating it Evaluation is free and needs no account. The public demonstration key `DEMO-AGENTICRAIL-PUBLIC-2026` is real and works against the live gate; the [documentation](https://agenticrail.nz/docs/) carries a copy-paste request, and the [browser demo](https://agenticrail.nz/demo/) drives the same gate without a terminal. Sequences created on that key are public: their reports need no key, so treat anything placed in `attestation` on a demo sequence as world-readable. Production deployments are priced per deployment. There is no price list and no self-serve sign-up, deliberately — the shape of an enforcement deployment depends on where the gate is placed and who is meant to be able to check the evidence, and that is a conversation rather than a checkout. [hello@agenticrail.nz](mailto:hello@agenticrail.nz). **Already built your own?** Most teams weighing this have an audit trail already. The comparison worth making is not log quality, retention or cryptographic strength — a careful in-house build holds up well against a vendor product, or anything off the shelf, on all three. It is whether the record was generated outside the system under examination, which is the one property that does not yield to engineering effort. That case is set out in full in [build vs buy: what an in-house audit trail can and cannot reach](https://agenticrail.nz/blog/ai-agent-audit-log-best-practices/). ## Further reading [The Enforcement Specification](https://agenticrail.nz/spec/) — decision architecture, receipt fields, signing and the sealed chain. Versioned and fingerprinted. [The Completeness Specification](https://agenticrail.nz/spec/completeness/) — the eight requirements that separate an evidence-grade enforcement record from an ordinary log, and the criteria an auditor tests against. [Documentation](https://agenticrail.nz/docs/) — the payload contract, every denial code, and a runnable example. [Questions](https://agenticrail.nz/faq/) — including the ones with uncomfortable answers. He toi whakairo, he mana tangata --- # How Do You Integrate AgenticRail's Sequence Enforcement API? > Markdown mirror for AI agents, generated 2026-08-12 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, written to R2 as a tamper-evident record. That receipt is your compliance record: structural proof of what ran and in what order, timestamped by AgenticRail. 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 signed into the receipt and stored in R2 alongside it, so any later alteration is detectable. 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); } ``` **No SDK is required.** The gate is a plain HTTPS JSON call, exactly as above, so any language that can POST can use it. These packages wrap that call for convenience and ship the integrations below. SDKs — Python and JavaScript ``` # Python — ships LangGraph and CrewAI integrations pip install agenticrail # JavaScript / TypeScript — dual ESM + CJS, works with LangGraph.js, Mastra, Genkit npm install @agenticrail/core ``` Both are MIT-licensed and open source. Evaluate against the live gate with the public demo key above — no account, no signup. `step_order` is sent on every call; the gate reads it from each payload and does not store it. 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 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. STEP_ORDER_MISMATCH The `step_order` sent differs from the one this sequence was opened with. The declared order is locked on the first call, so a later call cannot shorten it to skip a required step. If the process genuinely changed, start a new `sequence_id`. missing_* Required field absent — e.g. `missing_function`, `missing_action_type`, `missing_nonce`. Every code above arrives as an entry in the `reasons` array of a **DENY**, and every DENY is written to a signed receipt. A request can also be refused *before* it reaches enforcement, in which case you get a HALT instead. Those are a different class, and they are listed next. HALT ## Refused at the door. No receipt. **HALT is not an enforcement decision.** ALLOW and DENY are decisions: the gate evaluated your step against the sequence and reached a verdict, and either way a signed receipt is written before your action runs. HALT means the request was rejected at the boundary — malformed, oversized, unauthenticated, or matching a prompt-injection pattern — and never reached the enforcement engine at all. **A HALT produces no receipt.** Nothing was decided, so there is nothing to sign or store. If you are reconciling receipts against calls, HALTed calls will have no corresponding receipt, and that is correct behaviour, not a gap. A HALT is returned with a non-2xx HTTP status and carries `status` rather than `decision`: HALT response ``` { "status": "HALT", "halt_gate_step": 1, "reason_code": "SCHEMA_VIOLATION", "reason_detail": "REJECT_ROLE_DIRECTIVES" } ``` `reason_code` is the bucket; `reason_detail`, when present, is the specific trigger. reason_code Meaning UNAUTHORIZED 401. Missing or invalid credentials. `reason_detail` is `MISSING_KEY` or `BAD_KEY`. On the public API this means the `Authorization: Bearer` header. SCHEMA_VIOLATION The body failed hardening before parsing. `reason_detail` carries the trigger: `BAD_CONTENT_TYPE` (415), `BODY_TOO_LARGE` (413), `BAD_JSON` (400), `BODY_READ_ERROR` (400), or one of the injection patterns below (403). ↳ REJECT_ROLE_DIRECTIVES The body contains role-directive text of the kind used in prompt-injection attempts. ↳ REJECT_BASE64_BLOBS A base64-shaped string over 40 characters. Payloads are metadata, not carriers. Not applied to `attestation`, which legitimately holds hashes and IDs. ↳ REJECT_YAML_FRONT_MATTER YAML front-matter markers, matched both as real newlines and as the escaped `\n` that appears in JSON-stringified bodies. ↳ ATTESTATION_TOO_LARGE The `attestation` object exceeds its size cap. ↳ ATTESTATION_TOO_DEEP The `attestation` object nests deeper than the allowed depth. METHOD_NOT_ALLOWED 405. Request was not a POST. NOT_FOUND 404. Unknown path. DEMO_LIMIT 413. The demo key has a tighter body-size cap than a production key. Three rejections happen earlier still, at the public wrapper, and return a plain `error` field rather than a HALT envelope: `invalid_api_key` (401) when a real key prefix is presented with the wrong secret, `invalid_json` (400) when the body will not parse, and `rate_limited` (429) when you exceed your rate limit. Treat all of these the same way you treat a HALT: the call did not reach enforcement, and there is no receipt. **Sending no key is not one of them.** An unrecognised credential — no header at all, a placeholder, or a key that was never issued — does not fail. The call runs on the public demo lane and the response says so, carrying `lane`, `lane_reason` and `lane_notice`. Only a *recognised* key presented wrongly is refused: a wrong secret returns 401, a revoked key returns 403. The trade is that a demo-lane sequence is prefixed `demo-` and its report can be read by anyone holding the sequence id, so nothing private belongs in `attestation`. 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 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 composes a deterministic `enforcement_summary` from the resulting counts. **No language model is involved anywhere in report generation** — the same inputs always produce byte-identical text, so the summary reproduces like the rest of the document. 03 Output formats **HTML:** Full‑page report with cover, sequence summary, enforcement log, chain proof, and the deterministic enforcement summary. **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, tamper-evident 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 receipt 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, and you can [drive the gate in the browser](https://agenticrail.nz/demo/) first — skip a step, replay one, and watch it get refused before you write any code. 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) Wiring this up from code, or pointing an agent at it? The machine-readable API description is published as OpenAPI 3.1 at [agenticrail.nz/openapi.json](https://agenticrail.nz/openapi.json) — every endpoint, the full payload contract, all eight denial codes and the response schemas. It is linked as `service-desc` from [/.well-known/api-catalog](https://agenticrail.nz/.well-known/api-catalog), so a client that follows RFC 9727 discovery will find it without being told. Framework integrations: the Python SDK ships LangGraph and CrewAI adapters, the JavaScript SDK covers LangGraph.js, Mastra and Genkit, and MCP clients can call the gate as a tool at [mcp.agenticrail.nz](https://mcp.agenticrail.nz/). Working out whether this fits at all, rather than how to call it? The [product overview](https://agenticrail.nz/product/) sets out what AgenticRail is in one page: what it enforces, what a receipt contains, what it is used for — EU AI Act Article 12 record-keeping, provable human oversight and sign-off, segregation of duties — how it sits alongside observability, guardrails and orchestration, and what it does not do. Blunt questions — whether you can self-host, who holds the signing keys, what certifications we do and don't have, and what a receipt does not prove — are answered on the [FAQ](https://agenticrail.nz/faq/). 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-08-12 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 tamper-evident 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). **No sequence ID yet? Make one in two commands.** The [docs](https://agenticrail.nz/docs/) carry a copy-paste request that runs against the live gate on the public demo key — nothing to install, no sign-up. It returns a sequence ID; one more call returns that sequence's receipt with its Ed25519 signature and the exact preimage to check it against. If you would rather not open a terminal, the [browser demo](https://agenticrail.nz/demo/) drives the same gate. 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 This one is illustrative. Generate a real one from the [docs](https://agenticrail.nz/docs/), or [in the browser](https://agenticrail.nz/demo/) → ## 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 on your data or your governance — it is a bounded instrument. We hold the receipt signing keys today, and [who holds them is a deployment term](https://agenticrail.nz/faq/) | ## 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. **[When the Marker Is a Machine](https://agenticrail.nz/spec/ai-marked-assessment/)** — an agreement rate is a property of a system; a challenge is about an instance. What evidence supports one AI-assisted result. **[If AI Detectors Don't Work, What Does?](https://agenticrail.nz/spec/assessment-authenticity/)** — prohibit, detect, or record the process. Why the first two both interrogate the artifact, and what the third one changes. **[NCEA Is Being Replaced. What Assures the Internal Assessment?](https://agenticrail.nz/spec/nzce-internal-assessment/)** — under NZCE and NZACE internal assessment becomes universal, and its moderation is still unspecified. **[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.** [What it is](https://agenticrail.nz/product/) · [Run the live demo](https://agenticrail.nz/demo/) · [Verify a sequence](https://report.agenticrail.nz/report) · [Questions](https://agenticrail.nz/faq/) · [hello@agenticrail.nz](mailto:hello@agenticrail.nz) Hokianga Harbour Heads, Northland, Aotearoa — where AgenticRail is built He toi whakairo, he mana tangata --- # About — AgenticRail > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/about/ > Site context: https://agenticrail.nz/llms.txt # About AgenticRail AgenticRail is a **deterministic sequence enforcement layer for AI agents** — infrastructure that gates every agent action before it executes, issues a cryptographic receipt on every authorised pass, and returns ALLOW, DENY, or HALT. It is operated by **TUARA KURI LIMITED**, a New Zealand company. This page covers the builder, the philosophy, and the legal entity behind the product. ## The builder Kade Cowper Founder — TUARA KURI LIMITED Kade built AgenticRail from Hokianga, Aotearoa New Zealand — a region that shapes how he thinks about consequence and permanence. The design philosophy is rooted in **whakairo** (Māori carving): the chisel has no ctrl+z. Every committed action has consequence. That discipline, applied to AI agents, is what AgenticRail enforces. The technical architecture — Cloudflare Workers, Durable Objects, Ed25519-signed receipts, air-gapped core — reflects a specific conviction: governance that lives in the application layer can be bypassed by the application. Governance that lives in the infrastructure layer cannot. AgenticRail is the infrastructure layer. The MSMD® (Moko See Moko Do) enforcement spine defines eight deterministic checkpoints that must execute in order. No agent reaches step 5 without gate receipts from steps 1–4. This is not a logging system. It is a blocking system. [hello@agenticrail.nz](mailto:hello@agenticrail.nz) Deterministic AI AI Governance Sequence Enforcement Cloudflare Workers Durable Objects Cryptographic Audit Trails Agentic AI Safety ISO/IEC 42001 Fail-Closed Design ## Why this exists "You cannot undo a cut. The gate enforces that — before the cut is made." Whakairo — Māori wood carving — didn't give AgenticRail its rules. It made a universal law visible. In wood, sequence is undeniable: not because someone imposed it, but because that is the nature of ordered form. You cannot establish the form before the timber is read. You cannot carve the detail before the form exists. Every cut depends on every cut before it. Wood makes this obvious because the consequence is immediate and physical — you feel it, you see it, there is no ambiguity. The MSMD spine is an attempt to express that same principle in the domain of agentic AI. Code is still code. It runs on its own terms. AgenticRail doesn't ask it to behave like wood — it asks it to be honest about the sequence it already depends on. AI agents are probabilistic. They infer. They skip. They hallucinate completed steps. When a model decides a validation was implicitly done, no record distinguishes that inference from an actual execution. You find out it was wrong later — in production, in an audit, in a failure downstream. The standard responses to this problem — logging, monitoring, alerting — all operate after the fact. AgenticRail operates before. The gate sits between the agent's intent and the action's execution. The decision is ALLOW or DENY. There is no middle ground. The company name carries the same law. **Tuara Kuri** — the spine of the dog. In whakairo, the *pakati* pattern is that posture: the spine raised, the sentinel fully alert before the threat has been named. That is what the gate is — the sentinel at the threshold, deciding what may pass. This matters most where the cost of a skipped step is higher than the cost of a blocked action: financial services, healthcare, legal workflow automation, critical infrastructure, any system where human oversight of an AI decision is required, or where [ISO/IEC 42001:2023](https://www.iso.org/standard/81230.html) AI management system documentation is required. ## The legal entity Legal entity TUARA KURI LIMITED AgenticRail is a trading name of TUARA KURI LIMITED, a company incorporated under the New Zealand Companies Act 1993. **Contact:** [hello@agenticrail.nz](mailto:hello@agenticrail.nz) ## Legal documents All legal documents are published on agenticrail.nz with cryptographic version fingerprints. Each page includes a SHA-256 hash that lets you prove the exact version in force at any point in time. - →[Terms of Service (v1.6)](https://agenticrail.nz/terms/) - →[API Terms of Use (v2.7)](https://agenticrail.nz/api-terms/) - →[Privacy Policy (v2.6)](https://agenticrail.nz/privacy/) - →[Data Processing Agreement (v2.0)](https://agenticrail.nz/dpa/) ## Contact For integration support, compliance questions, or general enquiries: [hello@agenticrail.nz](mailto:hello@agenticrail.nz) Hokianga Harbour Heads, Northland, Aotearoa — where AgenticRail is built He toi whakairo, he mana tangata --- # Whakapapa — AgenticRail > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/whakapapa/ > Site context: https://agenticrail.nz/llms.txt # AgenticRail was not designed. It was remembered. **MSMD® — Moko See Moko Do.** Knowledge that passes through the pattern, not through text. Every core concept in AgenticRail — receipt, gate, sequence, seal — was named in whakairo (Māori carving) before any code was written. The laws were observed in timber over centuries. The code repeated them. "MSMD does not break people, nor does it save them. It simply refuses to cooperate with misalignment." — Gate 2, Core Stance. Named December 2025. Deployed as the DENY decision, April 2026. Where it begins ## The chip is a receipt. Pick up a chip off the carving floor. It is a small curved piece of wood — concave on one face, convex on the other. It releases when you strike the timber's surface at 45°. The concave inner face is smooth: clean fracture from a correctly-angled blow. You cannot produce that face by sanding or scraping. The geometry is structural evidence. It authenticates itself. This chip carries the complete record of the conditions that produced it — the angle, the force, the timber's moisture content, the practitioner's quality of attention — in a form that cannot be falsified after the fact. You cannot revise a chip. It is what it is: the crystallised evidence of what happened. "The chip on the floor is the atom of the system. Before theory, before governance, before any claim about universal law: there is a small curved piece of wood on the floor, and it tells the truth." — WHAKAIRO AS LAW, Part 1, Chapter 2 This is the first law of the system: **the act leaves its record in the material, and the record does not lie.** This observation — made in timber, over centuries — is the foundation of every cryptographic receipt AgenticRail produces. Ed25519 signing. Canonical JSON. Chain linkage. Tamper-evident R2 storage. The technology changed. The law didn't. The framework ## MSMD® — Moko See Moko Do **Moko See Moko Do.** Knowledge that doesn't pass through instruction. Knowledge that passes through the pattern — through the thing done by the body that the next body will do, and find confirmed, and pass on. MSMD is a transmission system for embodied knowledge built on three interlocking layers: **The physical practice layer** — whakairo, Māori carving. The primary domain where the laws were discovered. Every cut, every chip, every carved pattern encodes a law about how systems maintain integrity under real conditions. The patterns are not decorative. They are governance in material form. A correctly carved Unaunahi (scale pattern) does not represent the principle that knowledge accumulates across successive passes. It performs that law in the timber that first demonstrated it. **The sequence layer** — the Atua Compass. A locked 14-position sequence governing the correct order of operations for any significant act. Not a methodology you can adapt to suit your preferences. A structural constraint, the same way a stop-cut is a structural constraint: establish the boundary before removing what lies inside it. In timber, skipping the stop-cut produces tear-out — the crack propagates beyond the intended boundary. In a software system, committing to an action before establishing what it should not affect produces the same failure mode. **The ledger layer** — the chip archive. Every session under the Compass produces chips: sealed receipts of what actually happened. The chips accumulate into a lifetime archive. The accumulation of chips is the evidence of mastery. Not the declaration of it — the evidence. You do not say you are a master. You show the receipts. The practice system ## Four kinds of chips In whakairo, a chip is the physical piece of wood that releases with each cut. In the MSMD practice system, the word extends: a chip is the smallest unit of evidence a session can produce. A chip is not a journal entry. It is not a reflection memo. It is a sealed receipt — structured to prevent evasion, requiring external evidence, named precisely, and closed once written. Different positions on the Atua Compass produce different kinds of chips. Four types cover most of what practice produces: WHIRO — the honest log Atua of shadow and honest accounting Made before any commitment. Records the bare facts — what is actually true, what the weak points are, what the real repercussions would be near, medium, and far if things go wrong. Not what you would like to be true. Not the version that supports proceeding. The standard the entry must meet: *a description that would produce the same conclusion in the hands of a stranger.* In AgenticRail's dashboard, the Whiro refusals log is named after this. DENY decisions are the system doing what the WHIRO chip does for the practitioner: honest accounting before the gate. RURU — the owl's watch The morepork — guardian of the liminal hours Named after the native owl whose call comes after the day's work. A RURU chip is made at the close of a session — not as analysis but as seeds. A brief, still review of the day's chips, made before sleep, allowing unresolved signals to settle below conscious attention. The practitioner does not try to solve anything. They simply allow the patterns to settle. What arrives in the morning with more clarity than it left is the RURU receipt. This position cannot be coded — the puku check (the gut feeling before action) belongs entirely to the human domain. RONGO — the recipe Atua of peace and the storehouse Not a plan — a recipe. What actually happened, in enough operational detail to be reproduced or deliberately avoided. Not what you learned in general, but what the system now knows in specific form. RONGO chips seal the learning from a cycle and make it available to the next one. Over a lifetime of practice, the RONGO archive is what makes mastery transferable — not just to others, but to your future self in a different season. TOHU — the signal Signs and marks that precede knowing A tohu is not an event — it is a signal that precedes the event. Sleep disruption before a breakthrough. Increased sensitivity to certain kōrero. An old pattern dying and a new one forming. TOHU chips are brief: the felt signal, where it appeared in the body or environment, what it might indicate, whether it was later confirmed. They record what the system tried to communicate before conscious attention arrived — the marks the material makes before the practitioner knows what to look for. "When the gut signal and the logical analysis conflict, the gut signal takes precedence — not because feeling is more reliable than thinking in general, but because in the domain of body-based practice under real conditions, the gut signal is faster, incorporates more information, and is less susceptible to motivated reasoning." — WHAKAIRO AS LAW, Part 2 A chip is confirmed only when three seals are present: the **human seal** (conscious intention and act), the **machine seal** (the logged entry — digital record), and the **nature seal** (the physical confirmation — the material doing what it should, ambient conditions settling, proper silence after closure). When only one or two seals are present, the pattern is hypothesised. When all three are present, it is confirmed. This is why AgenticRail requires both the KV index and the R2 receipt: neither alone constitutes proof. The governors ## Eight atua. Each holds a specific function. The sequence was not invented. It was observed — in what happened when a practitioner was in the wrong state before beginning, in what produced clean work and what produced tear-out and drift, in the failure modes that repeated across every practitioner who had not yet learned the correct order. The atua were named after those observations had been made and tested. Each name encodes the domain it governs. Some of these functions can be gated in code. Others require the practitioner — they operate in the body and the practice system, not in infrastructure. The code enforces what can be gated. The rest is held by the person. Uru-te-nganangana Capacity · Field · The condition that makes entry possible The resource check before anything begins. Without Uru, the work starts from depletion. Uru is what Ruaumoko returns to — the field that receives the charge back. If Uru is empty, the sequence has no ground. Held in practice. The practitioner's capacity cannot be assessed by code. Whiro Integrity test · Shadow · Honest accounting before commitment The shadow domain — what is actually true before it is made presentable. A Whiro function requires a description that would produce the same conclusion in the hands of a stranger. It catches what the system tried to smuggle past. The weak points. The real repercussions. The thing the practitioner noticed and chose not to log. In the system: every DENY decision is a Whiro function. The gate refusing to proceed with what hasn't passed the integrity check. The dashboard's Whiro refusals log is named after this directly. Tāwhiri-mātea Disturbance · Wind · Absorb before reflecting No mirror in a gale. After execution, the state is disturbed — excited by success, frustrated by failure, uncertain of outcome. Tāwhiri holds that disturbance before reflection is attempted. Reflection from a turbulent state produces distorted conclusions. The disruption must settle before the sea shows a true image. In the system: the disruption step holds the sequence in a specific state after execution. The gate enforces this position — the sequence does not advance until Tāwhiri has been passed. Tangaroa Reflection · Stillness · The sea as mirror Specific comparison — not "does this look right?" but "how does what is present compare to what was named?" Tangaroa requires calm. The sea returns a true image only when the surface is undisturbed. This is the position where what was executed meets what was intended, and the gap is named honestly. Held in practice. Reflection cannot be coded. The code can enforce that Tāwhiri has settled; it cannot perform the comparison. That belongs to the practitioner. Tūmatauenga Sustained standard · Commitment · The inner force that holds The standard maintained from inside, not from external pressure. Once committed, the plan does not change mid-stroke — not because of a rule, but because Tū is the energy that sustains the sequence through its own execution. The redesign impulse that arises mid-cut is a Tū failure. The timebox is a Tū discipline. In the system: the step that locks the sequence in. After this position, the path is set for this cycle. The gate enforces that commitment. Rongo Completion · Storage · Settlement that enables future capacity Rongo is not softness — it is the active seal. Settlement is logistical: the conditions that allow what was produced to be stored, and what was learned to move into the deep hold. Agriculture logic. Peace as the environment in which preservation becomes possible. What Rongo seals, Uru can build from next time. The RONGO chip is the recipe that makes mastery transferable. In the system: the receipt function. Every cryptographic receipt is a Rongo act — completion sealed with whakapapa, stored in R2, linked to what came before it. The chain is the cumulative Rongo of every sequence that ran. Tāne Output · Lift · Steady execution in the material One change per pass. Stop after each. Harvest the chip. Read the surface. Tāne is the execution of what Tū committed to — the output phase where intention meets material. The way someone has done this ten thousand times and is still paying attention. Not performance. Steady work. In the system: the execution step. The gate passes here when all prior conditions are met. ALLOW is the system confirming Tāne may proceed. Ruaumoko Pressure · Charge · Feedback before thought The felt signal at the beginning — concave, hungry, steering action before conscious analysis arrives. Ruaumoko is the unborn child perpetually turning, causing tremors. It is the pressure that initiates and the charge that returns to Uru when a cycle completes. The puku reading — what is the body registering before the intention is named? A Ruaumoko that hasn't been read produces work that begins from noise rather than signal. Held in practice. Body truth cannot be gated in infrastructure. What Ruaumoko initiates, the whole sequence carries forward — which is why misreading it at the start compounds through every step that follows. The gate ## The Gate Law December 2025. A goat crossed an open footbridge and ate a garden. The response was anger. The Whiro log caught the actual cause: "The gate had been left open and the garden unfenced. The fault was theirs. The anger dissolved. **Gate Law — if the gate is open, expect consequences.**" — WHIRO chip, 2025-12-01. Omanaia. This law now runs as the deterministic enforcement gate in AgenticRail's core. Every step is gate-evaluated before execution. If the gate is closed (DENY), nothing proceeds. If the gate is open (ALLOW), the action proceeds and a cryptographic receipt is written. The law arrived from a goat and a footbridge in Omanaia. The code repeated it. The gate is not a safety net. It is an architectural principle: **establish the boundary before removing what lies inside it.** In whakairo, skipping the stop-cut means tear-out — the crack propagates beyond the intended boundary. In a software system, committing to an action before establishing what it should not affect produces the same failure. In AI governance, an agent that can skip required steps is an agent with an open gate. Expect consequences. The evidence ## The dual-domain requirement "When a physical artefact and a digital record both exist for the same act, the pattern is confirmed. When only one exists, the pattern is hypothesised. When neither exists, nothing has occurred." — WHAKAIRO AS LAW, Part 1, Chapter 2 This is now enforced as KV index + R2 receipt — two independent records of every enforcement decision. KV provides fast, consistent read access. R2 provides durable, tamper-evident storage. Neither alone is sufficient. Both together constitute proof. 913,079 ALLOW decisions 0 Enforcement errors 114,096 Sealed Tiki The laws were not designed. They were observed, over a very long time, by people who cut timber for a living and paid close attention to what the timber told them. They were named in the language of the people who found them. They operate identically in timber, in code, and in any domain where the underlying conditions exist — sequence, commitment, evidence, seal. Pressure-testing at scale is not validation of the code. It is confirmation that the laws derived from carving protocols operate identically in software. [The receipts are public →](https://agenticrail.nz/security/) Where the laws run now ## Three surfaces. Same law. API layer AgenticRail Deterministic sequence enforcement for AI agents. Every step gate-evaluated before execution. ALLOW or DENY. Cryptographic receipt on every pass. The Compass in infrastructure form — operating at scale, across any domain where an AI agent must demonstrate it followed the correct sequence. [Try the demo →](https://agenticrail.nz/demo/) Visual expression Rātā Gate A generative visual engine that withholds expression until rhythm is achieved. The same sequence law — no output before the gate condition is met — running as visual art. Named after Te Ara o Rātā: the path of the vine that begins as a parasite and, through calibrated discipline, becomes what the forest shapes itself around. [Open Rātā Gate →](https://mokoseemokodo.com/rata_gate?skin=rata_spectacle_triplehelix_v12) UI layer — open source Holdfast The gate in your interface. Gates destructive actions behind a sustained, steady hold — not a button click but deliberate physical intent. Panicked clicks locked out. Impulsive taps escalate the penalty. State-based confirmation: are you composed enough, right now, to act? MIT. Zero dependencies. [Demo →](https://agenticrail.nz/holdfast/demo) · `npm i @holdgate/core` He toi whakairo ## He toi whakairo, he mana tangata When the tohunga whakairo reaches their true potential, all people will benefit. This is not a statement about wood. It is not even a statement about carving. It is a law of transmission — that mastery, when it is genuine and complete, does not stay with the one who achieved it. It moves outward. It becomes the people's mana. The tohunga whakairo who shaped this knowledge did not write it down. They could not. What they knew could not survive translation into instruction. It lived in the sequence of cuts, in the resistance of the wood, in the moment a student's chisel went wrong and the practitioner watched — not to correct, but to witness what the student had not yet faced in themselves. They encoded it in pattern. In the geometry of the adze mark. In the order in which panels were approached. In what was required before the first cut was made. Hundreds of years of this. Silent. Largely unrecorded. Each generation inheriting not a text but a practice — and only through that practice, through repetition past the point of comfort and through sacrifice of the shortcut, arriving at what could not have been told to them. The knowledge waited inside the form until the student was ready to find it. That unbroken transmission — from practitioner to practitioner, through pattern not text — is exactly what AI homogenisation threatens. Not through policy. Not through legislation. Through the statistical gravity of training data that never contained most of it. The model does not encounter this knowledge and compress it. It encounters its absence and invents something that fills the shape. The output sounds plausible. It reads as fluent. To someone who carries the knowledge, it is immediately hollow — the same way a chip that came from sanding rather than a correctly-angled blow looks wrong to anyone who has held a chisel. The geometry is wrong. You cannot fake the geometry. That is what embodied means in this tradition. Not that knowledge lives in the body instead of the mind. That it cannot exist anywhere except in the doing — hands on wood, sequence in motion, hours of practice that train the felt sense until the carver knows what is true before they can say why. You cannot reach tohunga whakairo in theory. There is no theory path. There is only the repetition, the failure, the return, and the sacrifice of believing you already know. MSMD was built from that lineage. The chip system, the Atua Compass, the sequence laws that run AgenticRail — none of it came from a design document. It came from applying the same observational discipline the tohunga whakairo applied over generations: watching what patterns kept appearing, naming what was stable, encoding what could be trusted. The receipts, the gate, the seal — these are the adze marks of this practice. He toi whakairo, he mana tangata The practitioners who held this knowledge in silence — who shaped it, passed it, and let it wait inside the form until someone was ready to find it — this work stands on their sequence. Their names are not recorded here. Their work is present in all of it. The lineage ## Hei pupuri te aho o te wananga *To hold fast to the strands of valued learning. To perpetuate the hidden schools of Rua.* These words belong to Pakariki Harrison, tohunga whakairo, speaking at a wananga in 1999. The knowledge line runs through Te Rawheoro at Uawa — Tolaga Bay, East Coast. The practitioner who built AgenticRail carries Ngāti Kahungunu whakapapa. The Rua schools were a tiered educational architecture held by specialised priests, available only to those with the correct whakapapa and preparation. Each level of the Rua was a specific hollow — a form of knowledge that could only be entered from the one below it, under specific conditions. A locked sequence, enforced not by code but by the structure of the knowledge itself and by those authorised to hold it. The schools were destroyed. What survived did so in fragments: in patterns, in carved objects, in the felt memory of practitioners who carried the laws without being able to fully name them. That destruction required deliberate cruelty — legislation, missionaries, generations of children punished for speaking their own language. Identifiable perpetrators. Active policy across generations. The contemporary mechanism requires none of that. Statistical optimisation does the same work, at internet speed, through no one's malice, with no one to hold responsible. This work does not restore the Rua schools. That belongs to those who hold the lineage with full authority. But it is built in their shadow, by a practitioner who carries their whakapapa, working with what remains — naming what can be named, leaving nothing found unnamed, and passing nothing on without a receipt. "I am building this so my children inherit a world where AI cannot lie about what it did." — Kade Cowper. Hokianga, 2026. The full thesis — WHAKAIRO AS LAW: A Formal Account of the Operational Laws Observed in Māori Carving — is available on request. [hello@agenticrail.nz](mailto:hello@agenticrail.nz) [Try the demo →](https://agenticrail.nz/demo/) [Compliance Matrix →](https://agenticrail.nz/compliance/) --- # Terms of Service — AgenticRail > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/terms/ > Site context: https://agenticrail.nz/llms.txt # Terms of Service Version 1.8 · Last updated 2026-08-10 · supersedes v1.7 (2026-07-28) Effective: upon any use of the System. Operator: **TUARA KURI LIMITED** Trading as: AgenticRail Email: [hello@agenticrail.nz](mailto:hello@agenticrail.nz) ## 1. Overview AgenticRail is a deterministic execution control system that validates, sequences, and either allows or denies actions submitted by clients. - AgenticRail does not generate actions. - AgenticRail does not guarantee correctness. - AgenticRail only enforces whether an action is allowed to proceed. Use of the System constitutes acceptance of these Terms. ## 2. Definitions | Term | Definition | | **System** | AgenticRail (wrapper + gate + core + sequence enforcement) | | **Client** | Any user, service, or application sending requests to the System | | **Sequence** | An ordered set of steps enforced by the System | | **Action** | A proposed operation submitted for validation | | **ALLOW** | The System permits the Action to proceed | | **DENY** | The System blocks the Action due to a policy or sequence constraint; the Sequence may continue from a valid state | | **HALT** | The System refuses the request at the boundary, before enforcement runs — for example a malformed payload, an oversized body, a failed authentication, or a rejected pattern. HALT is not an enforcement decision and produces no Receipt, because no Action was evaluated. The Client may correct the request and resubmit. | | **Policy** | The rule set used to validate Actions (e.g., MSMD® policy maps) | ## 3. Nature of the System AgenticRail **is**: - a deterministic validation layer - an execution gate - a policy enforcement engine AgenticRail **is not**: - an advisor - a decision-maker - a guarantee of correctness - a substitute for human judgement ## 4. No Guarantee of Outcomes AgenticRail does not guarantee correctness, safety or suitability of any Action, or completion of any Sequence. An Action being ALLOWED does not mean it is correct, safe, or appropriate. It only means the Action passed the current Policy constraints. ## 5. Client Responsibility The Client is solely responsible for: - all inputs submitted to the System - all Actions executed after an ALLOW decision - all consequences arising from those Actions The Client must validate outputs independently, ensure compliance with applicable laws (including the EU AI Act), and ensure safe execution in their own environment. ## 6. Deterministic Enforcement AgenticRail enforces: - strict step ordering - function / Action matching - allowed Action types - replay protection (nonce) - sequence sealing after completion If any rule is violated, the System will DENY the Action. No override is available. ## 7. Sequence Rules - Sequences must follow the defined order. - Steps cannot be skipped, repeated, or reordered. - Once a Sequence reaches the final state (`settle`), it is sealed. - Sealed Sequences cannot be reused. Violations will result in error codes such as: `SEQUENCE_VIOLATION`, `REPLAY_NONCE`, `SEALED_SEQUENCE`, `ACTION_NOT_ALLOWED`, `STALE_TIMESTAMP`. ## 8. Action Validation All Actions must include a valid function, match the current step, use an allowed action_type, and conform to the active Policy. Invalid Actions will be rejected. The System may return an error without detailed explanation. ## 9. Denial Behaviour — Fail Closed AgenticRail may deny requests, halt Sequences, return errors, or stop execution without recovery. Denial may occur due to invalid structure, policy mismatch, sequence violation, replay detection, or system constraints. The System is designed to fail closed, not fail open. A DENY decision means the request did not pass the current policy constraints as configured. It is not a representation that the underlying action was incorrect or invalid. The Client is responsible for ensuring their configuration — including step order, function names, and action types — is correct. Unexpected DENY decisions resulting from misconfiguration are not a defect in the System. ## 10. Logging and Records AgenticRail is designed to minimise collection of personal data. The System primarily logs metadata required for operation, including Sequence IDs, timestamps, action types, and outcomes (ALLOW / HALT / DENY). AgenticRail does not rely on logging user content for normal operation. Clients must not rely on the System as a secure or confidential storage mechanism. Clients should avoid submitting sensitive personal, financial, or regulated data unless appropriate safeguards are in place. Enforcement receipts are retained to preserve the integrity of the verifiable receipt chain and to enable compliance reporting. There is no tiered or automated retention/deletion schedule — retention is not differentiated by plan. A Client requiring a specific retention or deletion schedule can agree one directly by contract. Clients may request deletion of their account data by contacting [hello@agenticrail.nz](mailto:hello@agenticrail.nz). A Data Processing Agreement (DPA) incorporating Standard Contractual Clauses is available at [agenticrail.nz/dpa](https://agenticrail.nz/dpa/). The DPA takes effect automatically upon your first paid API call — no separate signature required. ## 11. Misuse and Adversarial Testing The Client must not intentionally bypass sequence rules, attempt to exploit policy gaps, flood or degrade the System, or submit malformed or malicious payloads. Adversarial testing is only permitted if explicitly authorised in writing and conducted within defined boundaries. ## 12. Availability AgenticRail may change without notice, may be unavailable at any time, and may evolve policy definitions. No uptime guarantees are provided. AgenticRail uses reasonable efforts to maintain availability but does not commit to any specific uptime target or response time. ## 13. Pricing and Fees Pricing for the System is arranged directly with each Client and notified before any charges apply. The website ([agenticrail.nz](https://agenticrail.nz)) is the authoritative source for current pricing terms. AgenticRail may change pricing at any time. Material changes will be notified at least 30 days in advance. All fees are exclusive of GST or other taxes. Clients are responsible for any applicable taxes. ## 14. Limitation of Liability To the maximum extent permitted by New Zealand law, AgenticRail's total liability arising out of or related to these Terms or the System is limited to the greater of: - the fees paid by the Client in the 12 months preceding the event; or - NZ$100. AgenticRail is not liable for indirect, incidental, special, consequential, or punitive damages, or for loss of profits, data, or business interruption. AgenticRail is not liable for any claims arising from use of the System in high-risk contexts without adequate safeguards. ## 15. No Warranties The System is provided "as is" and "as available." AgenticRail makes no warranties, express or implied, including fitness for a particular purpose, reliability or availability, or accuracy of outcomes. Use of the System is at the Client's own risk. ## 16. High-Risk Use & EU AI Act The Client is the deployer of any AI system using AgenticRail. The Client is solely responsible for determining whether their use constitutes a high-risk AI system under applicable laws (including the EU AI Act). The Client must implement appropriate human oversight, risk management, and compliance controls. AgenticRail is a general-purpose enforcement tool and does not provide legal or compliance advice. AgenticRail must not be used as the sole control mechanism in any system where failure could result in harm to individuals, financial loss, or legal or regulatory impact. By using the System, the Client accepts full responsibility for compliance. ## 17. Indemnification The Client agrees to indemnify, defend, and hold harmless AgenticRail and its directors, employees, and agents from any claim arising out of breach of these Terms, violation of any law or regulation, use of the System in high-risk contexts without safeguards, or infringement of third-party rights. ## 18. Intellectual Property — No Training The Client retains ownership of their inputs and data. AgenticRail retains all rights to the System, source code, algorithms, and documentation. The Client may not reverse engineer or decompile the System, extract source code, or use the System to build or train competing products. ## 19. Suspension and Termination AgenticRail may suspend or terminate access to the System at any time for misuse, for breach of these Terms, or to protect system integrity. Termination may occur without prior notice where necessary. ## 20. Governing Law & Jurisdiction These Terms are governed by the laws of New Zealand. Any disputes shall be resolved in the courts of New Zealand. For Clients in the European Union, mandatory consumer protections still apply. ## 21. Modifications These Terms may be updated at any time. Material changes will be notified at least 30 days in advance. Continued use of the System constitutes acceptance of updated Terms. ## 22. Governing Principle AgenticRail enforces structure, not truth. The System controls whether an Action is allowed. The Client remains responsible for what happens next. ## 23. Contact AgenticRail — TUARA KURI LIMITED Email: [hello@agenticrail.nz](mailto:hello@agenticrail.nz) By using AgenticRail, you acknowledge that you have read, understood, and agree to be bound by these Terms. Version & Change Log — v1.8 Version: 1.8 · Effective date: 2026-08-10 · Operator: TUARA KURI LIMITED · Supersedes v1.7 (2026-07-28) · prior v1.6 (2026-07-08) **v1.8 (2026-08-10):** removes the registered street address from the operator block and from Section 23 (Contact). It was a contact detail, not an address for service: notices are given by email to hello@agenticrail.nz, and the registered address of TUARA KURI LIMITED remains publicly available from the New Zealand Companies Register. No other change. **v1.7 (2026-07-28):** corrects the definition of HALT in Section 2. The previous text described HALT as stopping execution due to a sequence violation, invalid state or terminal error, with the Sequence unable to proceed. A sequence violation is a DENY: an enforcement decision, written to a signed Receipt. HALT is a refusal at the boundary before enforcement runs, is not an enforcement decision, and produces no Receipt. Section 1, Section 6 and Section 11 corrected to match. **v1.6 (2026-07-08):** removes the tiered (Free/Growth/Scale/Enterprise) receipt retention schedule from Section 10 — no such tiered plan structure or automated deletion mechanism exists. Removes "plans, and tiers" language from Section 13 (Pricing) — production pricing is arranged directly with each Client. No other change;. [agenticrail.nz](https://agenticrail.nz) · [Privacy Policy](https://agenticrail.nz/privacy/) · [API Terms of Use](https://agenticrail.nz/api-terms/) · [Data Processing Agreement](https://agenticrail.nz/dpa/) Last updated: 2026-07-08 He toi whakairo, he mana tangata --- # API Terms of Use — AgenticRail > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/api-terms/ > Site context: https://agenticrail.nz/llms.txt # API Terms of Use Version 2.9 · Last updated 2026-08-10 · supersedes v2.8 (2026-07-28) Effective: upon any use of the API. Operator: **TUARA KURI LIMITED** Trading as: AgenticRail Email: [hello@agenticrail.nz](mailto:hello@agenticrail.nz) These API Terms govern access to and use of the AgenticRail API. They apply in addition to the [AgenticRail Terms of Service](https://agenticrail.nz/terms/) and [Privacy Policy](https://agenticrail.nz/privacy/). Capitalised terms not defined here have the meanings given in the main Terms of Service. ## 1. Purpose of the API The AgenticRail API provides a deterministic execution gate that: - validates incoming actions - enforces sequence order - applies policy constraints - returns ALLOW or DENY enforcement decisions, or refuses the request with HALT The API does not generate actions or guarantee outcomes. ## 2. API Keys & Account Access to the API requires a valid API key. - You are responsible for all activity under your key. - Do not share, expose, or embed keys in public code (e.g., client-side JavaScript, mobile apps). - You must promptly notify us if your key is compromised. AgenticRail may rotate keys, revoke keys, or limit or suspend access at any time to protect system integrity. ## 3. Request Contract (Required Payload) All API requests must follow the documented structure. Minimum required payload: ``` { "schema_version": "1.0", "model_id": "MSMD", "sequence_id": "string", "step": "string", "function": "string", "action_type": "string", "nonce": "string", "ts_ms": 0, "action": "string", "inputs": {} } ``` **Required rules:** - `step` MUST equal `function` - `nonce` MUST be unique per request (UUID or equivalent recommended) - `action_type` MUST be allowed for the given step/function - `sequence_id` MUST be consistent within a sequence Requests that do not meet this contract will be rejected. ## 4. Deterministic Enforcement The API enforces: - strict ordered sequence (8-step spine) - function validation - action-type allowlists - nonce replay protection - sequence sealing after completion Violations result in `DENY` — an enforcement decision, written to a signed Receipt — or `HALT`, a refusal at the boundary before enforcement runs, which produces no Receipt, or structured error responses. The API is designed to fail closed, not fail open. ## 5. Sequence Rules - Steps must follow the defined order. - Steps cannot be skipped, repeated, or reordered. - Each sequence must use fresh nonces. - Once a sequence reaches the final state (`settle`), it is sealed. After sealing, further requests on that sequence will be rejected. ## 6. Response Model Responses include: - `decision`: ALLOW or DENY. A HALT carries `status` rather than `decision`, and produces no Receipt - `reasons`: array of reason codes - `meta`: validation metadata (step, action_type, etc.) An ALLOW decision means the action passed current policy constraints. It does **not** mean the action is correct, the action is safe, or the action should be executed without human review. ## 7. Error Handling & Reason Codes Clients must handle errors correctly. | Code | Meaning | | `DENY` | Action not permitted by policy | | `REPLAY_NONCE` | Nonce already used for this sequence | | `SEQUENCE_VIOLATION` | Step order incorrect (skip or repeat) | | `SEALED_SEQUENCE` | Sequence already completed (settle) | | `ACTION_NOT_ALLOWED` | `action_type` not valid for the current function/step | | `STALE_TIMESTAMP` | `ts_ms` is more than 300 seconds from server time | Clients must not assume retries will succeed without correcting the underlying issue. ## 8. HTTP Status Codes The API may use standard HTTP status codes, including: - `200` — Request processed successfully (ALLOW or DENY decision returned) - `400` — Invalid request structure - `401` / `403` — Authentication or API key issues - `429` — Rate limit exceeded - `500` — Internal server error Clients must not rely solely on HTTP status codes and should always inspect the response body. ## 9. Rate Limits & Usage The public demo key is rate-limited to 300 requests per minute per IP address, enforced by a single-threaded Durable Object per rate-limit key — no race conditions. Production API access is arranged directly with the Operator (see Onboarding, below). The applicable rate limit is agreed as part of that arrangement and enforced per API key by the same Durable-Object mechanism. There is no published self-serve pricing tier or monthly request quota. Access, rate limits, and pricing for production use are configured directly with each Client based on their use case. Exceeding the applicable rate limit may result in throttling (HTTP 429), temporary denial, or suspension of access. We may change rate limits with reasonable notice. The AgenticRail website ([agenticrail.nz](https://agenticrail.nz)) is the authoritative source for current pricing. **Onboarding:** Production API access is arranged directly with the Operator. We work with each Client to understand their use case and configure their enforcement policies before a production key is issued. The public demo key remains available immediately, at no charge, for evaluation. To arrange production access, contact [hello@agenticrail.nz](mailto:hello@agenticrail.nz). ## 10. Idempotency and Retries Requests are not idempotent by default. - Reusing a nonce will result in `REPLAY_NONCE` errors. - Each request must use a new nonce. Clients must generate unique nonces per request, design retry logic carefully, and avoid blind retries. ## 11. Client Responsibilities Clients must: - validate all API responses before execution - implement fallback or safe failure behaviour - ensure compliance with applicable laws (including the EU AI Act) - ensure safe use in their domain AgenticRail is a control layer, not a decision engine. AgenticRail must not be used as the sole control mechanism in any system where a DENY decision or a HALT refusal could result in harm, financial loss, or regulatory impact. The Client must implement appropriate fallback behaviour. The Client is responsible for ensuring their configuration — including step order, function names, and action types — is correct. Unexpected DENY decisions resulting from misconfiguration are not a defect in the System. ## 12. Prohibited Use You must not: - attempt to bypass sequence enforcement - send malformed or adversarial payloads to break the system - reverse engineer API behaviour - use the API to build competing enforcement systems - conduct unauthorised stress testing Violation may result in immediate suspension. ## 13. Security You must: - protect API keys - rotate keys if compromised - use secure transport (HTTPS only) - avoid submitting personal or sensitive data unless appropriate safeguards and legal basis are in place AgenticRail is not a secure data storage system. ## 14. Availability & Changes The API is provided "as is" and "as available." We do not guarantee uptime or response times, but we use reasonable efforts to maintain availability. The API may evolve over time, including new validation rules and updated payload requirements. Backward compatibility is not guaranteed. Breaking changes will be notified at least 30 days in advance. ## 15. API Versioning - Versioning is indicated via the `schema_version` field. - Clients are responsible for maintaining compatibility. - Deprecated versions may be removed with reasonable notice. ## 16. Suspension & Termination We may suspend or terminate API access immediately if you breach these API Terms or the main Terms, your use poses a security risk, your use disrupts the API for others, or you fail to pay outstanding fees within 15 days of notice. Upon termination, API keys will be revoked and outstanding fees become immediately due. ## 17. Limitation of Liability These API Terms are subject to the Limitation of Liability clause in the [main Terms of Service](https://agenticrail.nz/terms/). In summary: liability is capped at fees paid in the previous 12 months or NZ$100 (whichever is greater); no liability for indirect or consequential damages. Use of the API is at your own risk. ## 18. Governing Law These API Terms are governed by the laws of New Zealand. Disputes shall be resolved in the courts of New Zealand. ## 19. Governing Principle The API enforces structure, not truth. It decides what is allowed. It does not decide what is correct. ## 20. Contact For API access, key management, or questions: [hello@agenticrail.nz](mailto:hello@agenticrail.nz) By using the AgenticRail API, you acknowledge that you have read, understood, and agree to be bound by these API Terms of Use, together with the Terms of Service and Privacy Policy. Version & Change Log — v2.9 Version: 2.9 · Effective date: 2026-08-10 · Operator: TUARA KURI LIMITED · Supersedes v2.8 (2026-07-28) · prior v2.7 (2026-07-08) **v2.9 (2026-08-10):** removes the registered street address from the operator block. It was a contact detail, not an address for service: notices are given by email to hello@agenticrail.nz, and the registered address of TUARA KURI LIMITED remains publicly available from the New Zealand Companies Register. No other change. **v2.8 (2026-07-28):** corrects the response model and reason-code table. The `decision` field carries ALLOW or DENY only; a HALT is returned as `status` and produces no Receipt, because the request was refused before enforcement ran. Removes the HALT row from the reason-code table: HALT is not a reason code, and the behaviour that row described is a DENY (`SEQUENCE_VIOLATION`), which is receipted. Sections 1, 5 and 12 corrected to match. **v2.7 (2026-07-08):** removes the tiered (Free/Growth/Scale/Enterprise) monthly request-quota table from Section 9 — those quota figures were never enforced anywhere in the deployed system and no self-serve pricing tier exists. Replaced with an accurate description: demo key rate limit (300 req/min per IP, enforced today) and production rate limits agreed directly per Client. No other change;. [agenticrail.nz](https://agenticrail.nz) · [Terms of Service](https://agenticrail.nz/terms/) · [Privacy Policy](https://agenticrail.nz/privacy/) · [Data Processing Agreement](https://agenticrail.nz/dpa/) Last updated: 2026-07-08 He toi whakairo, he mana tangata --- # Privacy Policy — AgenticRail > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/privacy/ > Site context: https://agenticrail.nz/llms.txt # Privacy Policy Version 2.8 · Last updated 2026-08-11 · supersedes v2.7 (2026-08-08) Effective: upon any use of the System. Operator: **TUARA KURI LIMITED** Trading as: AgenticRail Email: [hello@agenticrail.nz](mailto:hello@agenticrail.nz) ## 1. Overview This Privacy Policy explains how AgenticRail collects, uses, and handles data when you use the System. AgenticRail is designed as a deterministic execution gate, not a data processing or storage platform. We minimise data collection and avoid reliance on user content wherever possible. ## 2. What We Collect ### 2.1 Metadata (Primary) We collect operational metadata required to run the System, including: - Sequence identifiers (IDs you provide or we generate) - Nonce values (unique random values per request) - Timestamps (milliseconds since epoch) - Step names and action types - System outcomes (ALLOW / HALT / DENY) - Request counts (for billing and usage) ### 2.2 Technical Data (Limited) We may also collect: - IP addresses (processed transiently for security and debugging purposes and not retained beyond what is necessary for those functions) - Request headers (standard HTTP) - Error logs - Latency and performance metrics ### 2.3 What We Do NOT Intentionally Collect AgenticRail is designed to avoid collecting personal data except where necessary (e.g., account email). We do not rely on personal data for core system operation. We do not intentionally collect prompt content, agent messages or responses, or user-generated data payloads. **Important:** Clients control what they send to the System. If you submit personal or sensitive data, it may pass through system infrastructure. You are responsible for avoiding this. ### 2.4 Sensitive Data Guidance The System is not designed for processing sensitive personal data, including health data, financial account data, or biometric or identity data. Clients must not submit such data unless they have implemented appropriate safeguards and legal basis. ## 3. How We Use Data We use collected data to: - enforce sequence and policy rules - operate the execution gate - prevent replay attacks (nonce validation) - maintain system integrity - debug errors and improve performance - measure usage for billing **We do not**: - train AI models on your data - profile users - sell or share personal data for marketing **Legal basis (GDPR):** Legitimate interest (operating and securing the Service) and contract performance (where account data such as email is provided). ## 4. Data Minimisation Principle If the System does not need the data to enforce a rule, it should not store it. The System is designed to operate on structure (step, function, action_type) rather than content. ## 5. Data Retention AgenticRail retains two distinct categories of data on different schedules. **Enforcement receipts** (Ed25519-signed decision records stored in R2): retained to preserve the integrity of the verifiable receipt chain and to enable compliance reporting. There is no tiered or automated deletion schedule — retention is not differentiated by plan. A client requiring a specific retention or deletion schedule can agree one directly by contract. **Server and operational logs** (HTTP access logs, error logs, latency metrics): retained for 90 days, then automatically deleted. **Account information** (email address, optional name): retained while the account is active, plus a reasonable period for legal or security purposes. You may request deletion of your account data at any time (see Section 11). Enforcement receipts cannot be individually deleted, as doing so would break the verifiable receipt chain — contact hello@agenticrail.nz to discuss a specific retention or deletion arrangement. ## 6. Data Security We implement reasonable technical and organisational measures, including: - Encryption in transit (TLS 1.3) - Access controls on logs and systems - Regular security reviews No system is completely secure. Clients should not rely on AgenticRail for storage of sensitive data. ## 7. Data Breach Notification In the event of a data breach affecting personal data, AgenticRail will notify affected users and relevant authorities where required by law. ## 8. Client Responsibility Clients are solely responsible for: - ensuring they do not submit unnecessary personal data - complying with applicable privacy laws (e.g., NZ Privacy Act 2020, GDPR) - implementing safeguards for sensitive data AgenticRail acts as a processor of structure, not a controller of user data. ## 9. International Use & Data Transfers AgenticRail is operated from New Zealand but uses Cloudflare's global network, which may process data in multiple countries. By using the Service, you consent to this transfer. For EU users, we rely on Cloudflare's compliance mechanisms, including Standard Contractual Clauses. New Zealand has been recognised by the European Commission as providing an adequate level of data protection (Adequacy Decision, 2012, reaffirmed 2024). ## 10. EU AI Act & Privacy Context AgenticRail does not determine the purpose of AI systems. The Client is responsible for classification of their AI system, handling of personal data, and compliance with privacy and AI regulations (including the EU AI Act). AgenticRail provides enforcement logic, not data governance. ## 11. Your Rights (Including GDPR) Depending on your jurisdiction, you may have the right to: - access your personal data - correct inaccurate data - request deletion ("right to be forgotten") - restrict or object to processing - data portability Because AgenticRail stores minimal personal data, these rights may be limited in practice. To exercise your rights, contact [hello@agenticrail.nz](mailto:hello@agenticrail.nz). We aim to respond within 30 days. New Zealand users may contact the Office of the Privacy Commissioner: [privacy.org.nz](https://www.privacy.org.nz). ## 12. Third-Party Services & Subprocessors AgenticRail uses the following infrastructure providers: | Provider | Purpose | Privacy Policy | | Cloudflare | API hosting, Durable Objects, R2 storage, KV, D1, networking | [cloudflare.com/privacy](https://www.cloudflare.com/privacy) | | Stripe | Payment processing for subscription plans | [stripe.com/privacy](https://www.stripe.com/privacy) | | Resend | Transactional email delivery (welcome emails, API key delivery) | [resend.com/privacy](https://www.resend.com/privacy) | These providers process data only under contractual obligations and appropriate safeguards. We do not sell or share user data for marketing. A Data Processing Agreement (DPA) incorporating Standard Contractual Clauses is available at [agenticrail.nz/dpa](https://agenticrail.nz/dpa/). The DPA takes effect automatically upon your first paid API call — no separate signature required. ## 13. Changes to This Privacy Policy We may update this Privacy Policy at any time. Material changes will be communicated via email (if provided) or through the Service. Continued use of the System constitutes acceptance of updates. ## 14. Contact AgenticRail — TUARA KURI LIMITED Email: [hello@agenticrail.nz](mailto:hello@agenticrail.nz) By using AgenticRail, you acknowledge that you have read and understood this Privacy Policy. Document Fingerprint — SHA-256 — v2.8 05e319d2bda51d626a7b721af079f4bf1366b78624497caf918d87208987279f Reproducible independently using any SHA-256 implementation over the pipe-delimited canonical string below. **Canonical string (UTF-8, no trailing newline):** `Privacy Policy|2.8|2026-08-11|TUARA KURI LIMITED|GDPR + NZ Privacy Act 2020|Cloudflare,Stripe,Resend|metadata-only; no payload retention|no tiered plans; receipts retained to preserve chain integrity|no model training; no marketing sale|New Zealand|supersedes v2.7 2026-08-08` Version: 2.8 · Effective date: 2026-08-11 · Operator: TUARA KURI LIMITED · Supersedes v2.7 (2026-08-08) **v2.8 (2026-08-11):** removes the registered street address from the operator block and Section 14, and the NZBN from the fingerprint metadata and canonical string. Neither was an address for service: notices are given by email to hello@agenticrail.nz, and TUARA KURI LIMITED remains identifiable on the public New Zealand Companies and NZBN registers. No change to what is collected, how long it is kept, who processes it, or any individual's rights. This fingerprint supersedes the v2.7 hash `cc9a1fd11471e87464d4c2222ebd804bcc6cdc527fc9bad52649ced64a92860c`. **v2.7 (2026-08-08):** removes the AI Provider from the subprocessor list in Section 12. Verification report summaries are composed by AgenticRail's own code from the enforcement data in the receipts; no language model or external service is involved, so Google (Gemini) is no longer a subprocessor and the category is retired rather than reassigned. The subprocessor list is now Cloudflare, Stripe and Resend. No change to what is collected, how long it is kept, or any individual's rights, and no personal data was ever within the removed entry's scope. This fingerprint supersedes the v2.6 hash `6acc0ae5fed5d2e9c855788d4ffe5fb48fc327fbc95596abc4156f5f200f9a2d`. **v2.6 (2026-07-08):** removes the tiered (Free/Growth/Scale/Enterprise) receipt retention schedule from Section 5 — no such tiered plan structure or automated deletion mechanism exists; the prior text named a specific "R2 lifecycle policy" that does not exist in the deployed system. Replaced with an accurate statement: receipts are retained indefinitely by default to preserve chain integrity, with no automated tiered deletion, and a specific schedule available by direct agreement. No other change; this fingerprint supersedes the v2.5 hash `041eba3fe3c5123241ffb0f27701a9f632235f63ae977aaa67083d44d9ff2490`. [agenticrail.nz](https://agenticrail.nz) · [Terms of Service](https://agenticrail.nz/terms/) · [API Terms of Use](https://agenticrail.nz/api-terms/) · [Data Processing Agreement](https://agenticrail.nz/dpa/) Last updated: 2026-08-11 He toi whakairo, he mana tangata --- # Data Processing Agreement — AgenticRail > Markdown mirror for AI agents, generated 2026-08-12 from the live page. > Canonical: https://agenticrail.nz/dpa/ > Site context: https://agenticrail.nz/llms.txt # Data Processing Agreement Version 2.2 · Last updated 2026-08-11 · supersedes v2.1 (2026-08-08) Between TUARA KURI LIMITED (Processor) and Customer (Controller). Effective: upon execution of a paid AgenticRail subscription. ## 1. Definitions **"Controller"** means the Customer — the entity that determines the purposes and means of processing personal data through the AgenticRail service. **"Processor"** means TUARA KURI LIMITED, a New Zealand registered company trading as AgenticRail. **"Subprocessor"** means any third party engaged by the Processor to process personal data on behalf of the Controller. Current subprocessors are listed in Section 8. **"Personal Data"** means any information relating to an identified or identifiable natural person, as defined in Article 4(1) of the GDPR. **"Service"** means the AgenticRail API (sequence enforcement, receipt generation, compliance reporting). **"GDPR"** means Regulation (EU) 2016/679. ## 2. Scope and Purpose of Processing The Processor processes personal data solely for the purpose of providing the Service: - Receiving API requests at the Wrapper endpoint - Authenticating API keys against the Processor's database - Evaluating enforcement decisions via the Core Worker + Durable Object - Writing cryptographic receipts to R2 tamper-evident storage - Generating compliance reports on request The Controller determines what data is sent in API request payloads. The Processor does not inspect, retain, or use payload data beyond what is necessary for enforcement evaluation. ## 3. Duration This DPA is effective for the duration of the Controller's paid AgenticRail subscription. Upon termination, at the Controller's choice, the Processor will delete or return all personal data within 90 days and delete existing copies, unless retention is required by applicable law, in accordance with the retention schedule in Section 7. The Controller may exercise this choice by written notice to hello@agenticrail.nz prior to or at termination; absent such notice, the Processor will delete the personal data. ## 4. Processor Obligations The Processor shall: - Process personal data only on documented instructions from the Controller, including with regard to international transfers, unless required to do otherwise by applicable law (in which case the Processor will inform the Controller of that legal requirement before processing, unless the law prohibits such notice) - Immediately inform the Controller if, in the Processor's opinion, an instruction from the Controller infringes the GDPR or other applicable data protection law - Ensure persons authorised to process personal data are committed to confidentiality - Implement appropriate technical and organisational measures as described in Section 6 - Assist the Controller in fulfilling data subject requests (access, rectification, erasure) where possible - Assist the Controller in ensuring compliance with its obligations under Articles 32 to 36 of the GDPR, including conducting data protection impact assessments and prior consultation with a supervisory authority where relevant - Notify the Controller without undue delay, and in any event within 48 hours, upon becoming aware of a personal data breach - Make available to the Controller all information necessary to demonstrate compliance ## 5. Controller Obligations The Controller shall: - Ensure a lawful basis exists for processing personal data through the Service - Not include special categories of personal data in API request payloads unless a specific derogation applies - Provide necessary notices to data subjects regarding the processing - Ensure API keys are stored securely and not exposed in client-side code or public repositories ## 6. Technical and Organisational Measures The Processor implements the following measures: | Measure | Implementation | | Encryption in transit | TLS 1.3 for all API endpoints | | Access control | Bearer token authentication per API key. Timing-safe comparison on all credential checks. | | Infrastructure isolation | Enforcement core is air-gapped (no public URL). Accessible only via authenticated service bindings between Cloudflare Workers. | | Audit trail | Ed25519-signed cryptographic receipts on every enforcement decision. Tamper-evident R2 storage, with sealed receipts copied to an independently held write-once archive. | | Availability | Deployed on Cloudflare's global network (330+ data centers). Durable Objects provide consistent state. | | Incident response | Personal data breaches notified to the Controller without undue delay and within 48 hours of detection (Section 4). | ## 7. Data Retention and Deletion | Data | Retention | Automatic Deletion | | API request payloads | Duration of enforcement evaluation only (not persisted) | N/A — not stored | | Enforcement receipts | Retained to preserve the integrity of the verifiable receipt chain; no tiered or automated deletion schedule currently applies | None currently — no R2 lifecycle policy is applied to production receipts; a specific retention/deletion arrangement can be agreed by contract | | API keys (hashed) | Duration of subscription + 30 days | D1 record deletion | | Usage logs | 90 days | Wrapper cron job (daily) | | Client account data | Duration of subscription + 30 days | D1 record deletion | The 90-day deletion commitment in Section 3 applies to personal data. Enforcement receipts retained beyond that period contain only enforcement metadata — cryptographic hashes, nonces, step labels, decision codes, and timestamps — and do not contain personal data from Controller payloads, which are never persisted. Where a Controller's chosen identifiers (for example, a `sequence_id`) could themselves constitute personal data, the Controller is responsible for avoiding the inclusion of personal data in such identifiers. ## 8. Subprocessors | Subprocessor | Service | Location | Processing | | Cloudflare, Inc. | Workers, Durable Objects, R2, KV, D1 | Global (data processed at edge) | Hosts the Service infrastructure. All enforcement execution, receipt storage, and API authentication. | | Stripe, Inc. | Payment processing | Global | Processes subscription payments. Receives customer email and payment details. | | Resend, Inc. | Transactional email | Global | Delivers API key welcome emails. Receives customer email address only. | **Report content.** The enforcement summary in a verification report is composed by the Processor's own code from the enforcement data in the receipts. It involves no third party and no external service call, so the summary adds no subprocessor to the list above and discloses nothing beyond what the receipts already record. The Processor will notify the Controller of any intended changes to subprocessors at least 14 days in advance. The Controller may object on reasonable data protection grounds. The current authoritative subprocessor list is the version of this DPA in force at the time of any given enforcement decision; the document fingerprint at the bottom of this page identifies that version cryptographically. **Subprocessor obligations and liability.** The Processor shall impose, by written contract, data protection obligations on each subprocessor that are no less protective than those set out in this DPA, in particular the obligation to implement appropriate technical and organisational measures meeting the requirements of the GDPR. Where a subprocessor fails to fulfil its data protection obligations, the Processor remains fully liable to the Controller for the performance of that subprocessor's obligations. ## 9. International Data Transfers The Processor is established in New Zealand, which has been recognised by the European Commission as providing an adequate level of data protection (Adequacy Decision, 2012, reaffirmed 2024). Cloudflare processes data at the edge — the data center closest to the Controller's users. For EU-based Controllers, data is processed within the EU where possible. Where data is transferred internationally, it is protected under Cloudflare's Data Processing Addendum, which incorporates the EU Standard Contractual Clauses (SCCs) where applicable. ## 10. Audit Rights The Controller may audit the Processor's compliance with this DPA by: - Requesting the Processor's most recent security documentation - Verifying enforcement receipts independently through the public verification portal at `report.agenticrail.nz` - Requesting a remote audit (no more than once per 12-month period, at the Controller's expense) The Processor will provide reasonable cooperation for any audit required under Article 28(3)(h) of the GDPR. ## 11. Governing Law This DPA is governed by the laws of New Zealand. Any dispute arising from this DPA shall be subject to the exclusive jurisdiction of the courts of New Zealand. ## 12. Execution This DPA is incorporated into the AgenticRail Terms of Service and takes effect upon the Controller's first paid API call to the Service. No separate signature is required. **TUARA KURI LIMITED** — trading as AgenticRail hello@agenticrail.nz Incorporated by reference into the AgenticRail [Terms of Service (v1.8)](https://agenticrail.nz/terms/) and [API Terms of Use (v2.9)](https://agenticrail.nz/api-terms/). Read alongside the [Privacy Policy (v2.8)](https://agenticrail.nz/privacy/). Document Fingerprint — SHA-256 — v2.2 1bc5ac284ef664870ac31919a1dd0d7cc742f260232e6c46ba0ca6a3c4f96b87 Reproducible independently using any SHA-256 implementation over the pipe-delimited canonical string below. **Canonical string (UTF-8, no trailing newline):** `Data Processing Agreement|2.2|2026-08-11|TUARA KURI LIMITED|GDPR|Cloudflare,Stripe,Resend|no tiered plans; receipts retained to preserve chain integrity|Ed25519|k2_2026-06-07_ed25519|New Zealand|automatic on first paid API call|AgenticRail Terms of Service v1.8` Version: 2.2 · Effective date: 2026-08-11 · Operator: TUARA KURI LIMITED · Supersedes v2.1 (2026-08-08) **v2.2 (2026-08-11):** removes the registered street address and the NZBN from the Section 1 "Processor" definition, the execution block, the fingerprint metadata and the canonical string. TUARA KURI LIMITED remains the named Processor and remains identifiable on the public New Zealand Companies and NZBN registers; notices under this DPA are given by email to hello@agenticrail.nz. Updates the Section 12 cross-references to their current versions (Terms of Service v1.8, API Terms of Use v2.9, Privacy Policy v2.8). No change to processing activities, subprocessors, retention, security measures, or any party's obligations. This fingerprint supersedes the v2.1 hash `7670894b957e20f5fefae9fbaffcf76162ef80cb9a8fad096c57df73b7dd1ecc`. **v2.1 (2026-08-08):** removes the AI Provider subprocessor. Verification report summaries are composed by the Processor's own code from the enforcement data in the receipts; no language model or external service is involved, so Google (Gemini API) is no longer a subprocessor and the category is retired rather than reassigned. The subprocessor list is now Cloudflare, Stripe and Resend. No change to processing activities, retention, or any party's obligations, and no personal data was ever within the removed category's scope. This fingerprint supersedes the v2.0 hash `2b43a67a3da4bd3280cd2c12235644b34c3f24a9a0bf99d5047efe31b6313498`. **v2.0 (2026-07-24):** corrects the description of receipt storage. Two clauses described R2 as "immutable storage", which overstates the guarantee: the primary receipt store is tamper-evident, meaning an alteration is detectable through the signature and the hash chain, and it is not write-protected. Only the independent archive bucket carries a write-once lock rule. Both clauses now say tamper-evident, and the audit-trail row records the independently held archive copy of each sealed receipt. No change to processing activities, subprocessors, retention, or any party's obligations. This fingerprint supersedes the v1.9 hash `33976762fd264192febb6828b6d73d73ea3f89251b0963dd3736b04ee9229491`. **v1.9 (2026-07-08):** (1) completes the v1.8 NZBN correction — the Section 1 "Processor" definition still cited the superseded NZBN after v1.8 shipped; corrected in the body text itself, not just the fingerprint block. (The NZBN was removed from this document entirely at v2.2.) (2) Removes the tiered (Free/Growth/Scale/Enterprise) receipt retention schedule from Section 7 and the "R2 lifecycle policy" automatic-deletion claim — neither exists in the deployed system. Replaced with an accurate statement: receipts are retained to preserve chain integrity, no automated tiered deletion currently applies, and a specific schedule is available by direct agreement. (3) Updates the Terms of Service / API Terms of Use cross-references (Section 12/Execution) to their current versions (v1.6 / v2.7). This fingerprint supersedes the v1.8 hash `9a9c40bf04fc8a2bd06d8844e19a56d0a90236e52fc8b6a8a77c773c1a4405f5`. [agenticrail.nz](https://agenticrail.nz) · [Terms of Service](https://agenticrail.nz/terms/) · [Privacy Policy](https://agenticrail.nz/privacy/) · [API Terms of Use](https://agenticrail.nz/api-terms/) Last updated: 2026-07-24 He toi whakairo, he mana tangata