# What Does AgenticRail's Receipt Chain Actually Prove for Compliance?

> Markdown mirror for AI agents, generated 2026-08-06 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 & sovereignty

Aotearoa NZBounded by designWhat is stored, where, and what is not claimed

AgenticRail is an enforcement and evidence layer. It does **not** make anyone sovereign over the AI model, and it does not claim to. What it holds is deliberately small — and we state its limits plainly rather than imply more.

| Concern | How AgenticRail answers it |
 | What is stored | Receipts are **metadata and SHA-256 hashes only** — a hash of the request, never the request body. No clinical content and no personal data are stored in a receipt; the hash is not the content. |
 | Where it is stored (hosted tier) | The hosted service runs on Cloudflare R2 — **outside New Zealand**. No in-country residency is claimed for the hosted tier.

**Mitigation:** because only hashes and metadata are held, no taonga or personal record leaves your systems inside a receipt. |
 | NZ / sovereign residency | For an organisation with a data-residency requirement, a **self-hosted or sovereign deployment** can be provisioned on New Zealand-owned infrastructure. Receipts are S3-compatible and can be written to an NZ-owned store — keeping the record, and authority over it, in Aotearoa. |

This meets a documented expectation of patients for health AI — that their information stays within the health system and is not shared with outside or commercial organisations. Deploy AgenticRail into your own tenant, hold none of your data, and verify receipts against your own keys.

## Legal documents

Operating terms and data processing — each cryptographically fingerprinted so customers can prove the version in force at any point in time.

| Document | Version | What it covers |
 | [Terms of Service](https://agenticrail.nz/terms/) | `v1.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 New Zealand registered company — NZBN [9429053582867](https://www.nzbn.govt.nz/help/nzbn-register/search-the-register/) (search the public NZBN register directly), registered address 431 Omanaia Road, RD 3, Kaikohe 0473, New Zealand.

 [Try the demo →](https://agenticrail.nz/demo/) [Get a key →](mailto:hello@agenticrail.nz)