Can you prove what your
AI did last Tuesday?
Most businesses running AI are legally obligated to document what that AI does — not because it's "high-risk" under the EU AI Act, but because it's touching personal data under GDPR. The obligation is already in force. The documentation requirement is already on you.
AgenticRail's receipt chain answers that obligation structurally. Every agent action is timestamped, HMAC-signed, sequenced, and sealed. You can produce the full record for any sequence — what the agent did, when, in what order, whether it was authorised or blocked. That record cannot be edited after the fact.
That is AI action provenance. Same infrastructure as enforcement. Different front door.
structurally
full provenance report
required
Why this word. What it means here.
Provenance comes from the art world. Chain of custody. Proof of origin. Who held it, when, and in what sequence. When a painting's provenance is intact, you can trace every owner, every sale, every transfer — back to the moment it was made. When provenance is broken, the work's value and authenticity are in question regardless of how it looks today.
The same concept applies to AI agent actions. When your AI made a decision that affected someone — processed their data, denied their claim, approved their transaction — your ability to demonstrate what happened, in what sequence, at what time, is your provenance record. If that record was self-reported by the AI system, it is not provenance. It is testimony. Testimony can be reconstructed. Provenance cannot.
AgenticRail produces provenance. Every gate decision writes a cryptographic receipt at the moment of enforcement — before the agent acts. That receipt chain is the structural record. It cannot be generated after the fact because the cryptographic links depend on the exact state at the time each step was processed.
Logs are testimony. Receipts are provenance.
This is the only distinction that matters in a compliance context.
Written by the AI agent or application layer, after the fact.
The agent decides what to report and in what form. If the agent malfunctions, misremembers, or is asked to reconstruct a record, the log reflects that reconstruction.
An auditor cannot distinguish a genuine log from a reconstructed one. They look identical. This is not a theoretical problem — it is the exact problem UnitedHealth faced in federal court when asked to produce evidence of what their AI actually executed. They could not.
Logs satisfy record-keeping in the administrative sense. They do not satisfy the demonstrability requirement of GDPR Article 5(2). Documentation and proof are different standards.
Written by the enforcement infrastructure, before the agent acts.
The receipt is generated by the gate layer — independent of the AI model's own reporting. The gate decides whether the step is allowed, writes the receipt, and only then does the agent proceed. The agent cannot influence the receipt content.
Each receipt is HMAC-signed with a key the agent does not hold. The chain linkage (prev_receipt_id) means receipts cannot be reordered or have entries inserted after the fact without breaking the chain. Chain verification is deterministic and can be performed by any third party.
This is what auditors can verify independently. Not what the system claims happened — what the gate recorded at the moment it happened.
Three articles. One receipt chain.
These obligations apply to any organisation processing personal data with AI — not just high-risk systems under the EU AI Act. If your AI makes decisions about people, or processes their data as part of a workflow, these obligations are already active.
| Article | Obligation | What AgenticRail produces | |
|---|---|---|---|
| Art. 5(2) | Accountability principle The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1. The word is demonstrate — not document, not assert. Active proof is required. | The signed receipt chain is the demonstration. Not a policy document. Not a log export. A cryptographic record that proves the system operated as governed — verifiable by any third party with the sequence ID. The demonstration is structural, not procedural. | ✓ |
| Art. 22 | Automated individual decision-making Where automated processing produces decisions with significant effects on individuals, the controller must implement suitable safeguards and maintain documentation of that processing. | Every gate decision is timestamped to the millisecond, linked to the step that triggered it, and preserved immutably. The receipt documents not just what decision was made, but what sequence state existed when it was made — the exact conditions under which the automated decision occurred. Attestation fields allow per-decision evidence (risk scores, KYC results) to be embedded directly in the receipt. | ✓ |
| Art. 30 | Records of processing activities Controllers must maintain records of processing activities under their responsibility, containing information about the purposes of processing, categories of data, and recipients. | One receipt per gate decision. One compliance report per sequence. Generated automatically as a structural output of the enforcement layer — no manual record-keeping, no secondary logging system. The sequence ID is the retrieval key. Pull any sequence, at any time, and the full record is there. | ✓ |
These obligations activate when you process personal data — not only when you deploy a system the EU AI Act classifies as high-risk. If your AI agent touches customer data, employee data, or any data that relates to an identifiable person, Articles 5(2), 22, and 30 apply. The EU AI Act adds further obligations on top. AgenticRail satisfies both layers from the same infrastructure.
What is inside a receipt — and what each field proves.
Every gate ALLOW produces a receipt written to immutable storage before the agent action proceeds. This is what that receipt contains, and what each field means in a compliance context.
{ "pack_id": "80fe6e6887ca024d2325260f83224c86c3d2157b10ef60cc73ee8fded4661552", "key_id": "k2_2026-06-07_ed25519", "signature": "3hJ1m0Qm8eYJ0n2k9xqQ2b...", ← Ed25519 (base64) over canonical JSON "signature_alg": "Ed25519", "prev_receipt_id": "3d72a1c0e9f5...", ← links to previous step's receipt "payload_hash": "f4a3c2d1e8b792...", ← SHA-256 of request body — data never stored "ts_ms": 1748908800000, ← gate decision time (ms precision) "version": "2", "attestation": { ← per-step evidence, signed in "kyc_provider": "acme-kyc", "result": "pass", "check_ref": "KYC-2026-00791" } }
| Field | What it proves | Why it matters in compliance |
|---|---|---|
| pack_id | Unique identifier for this enforcement decision — a SHA-256 hash of the canonical receipt content. | The canonical reference. Any dispute about whether a specific enforcement decision occurred can be resolved by locating the pack_id in immutable storage. |
| signature (HMAC-SHA256) | Tamper evidence. Generated using a key held by the enforcement infrastructure — not accessible to the AI agent or client system. | If the receipt was altered after writing, signature verification fails. The receipt cannot be reconstructed to produce a valid signature. This is the technical guarantee that testimony and provenance are different things. |
| prev_receipt_id | Chain linkage. The pack_id of the receipt immediately preceding this step in the sequence. | Proves ordering. Steps cannot be reordered after the fact, and entries cannot be inserted into the chain, without breaking linkage. A broken chain link invalidates the compliance report. This satisfies Art. 5(2)'s requirement to demonstrate the sequence of processing. |
| ts_ms | Timestamp to millisecond precision — recorded at gate decision time by the enforcement infrastructure. | Proves when the decision was made — not when the agent reported it, when the gate made it. For Art. 22 (automated decision documentation), the decision moment is the legally relevant timestamp. |
| payload_hash | SHA-256 of the raw request body. The hash of your payload — not the payload itself — is what enters the receipt chain. | Your agent's input data (customer records, financial data, personal information) never reaches immutable storage. Only the fingerprint does. An auditor can verify the receipt is bound to a specific payload without ever seeing that payload's contents. Privacy-preserving by design. |
| attestation | Per-step evidence signed into this receipt. Any JSON object you supply — a risk score, a KYC reference, a human approval token, a document hash — is included in the HMAC computation and stored immutably. | Proves what evidence justified this specific decision. Not just that a step ran — what was known at the time it ran. A fraud check result embedded at the risk assessment step is signed evidence, not a claim made afterward. |
Your auditor sees the proof. Not your data.
This is the property most compliance tools miss — and the one that matters most for sovereignty, GDPR, and data minimisation.
The agent writes: "processed customer record 8821, outcome: approved." The log contains the event description, written by the same system being audited. It may contain fragments of the data. Reconstruction is possible because the source is the agent itself — it chose what to record.
The gate stores: the SHA-256 hash of the request body (payload_hash). Not the body. The fingerprint. Your customer records, financial data, and personal information never reach R2. An auditor verifying the chain sees a proof that the action occurred — not the action's content.
If your AI agent processes Māori community data, patient records, or any personal information governed by territorial law — the audit trail cannot be the place where that data travels. AgenticRail's payload_hash field means your data stays in your system. The gate signs the fingerprint, not the content. Compliance evidence and data sovereignty are not in tension.
Stateless verification — the receipt is an independent asset
A receipt signed with Ed25519 needs only the public key to verify — no call back to AgenticRail, no live API, no dependency on the enforcement infrastructure continuing to exist. The receipt is complete evidence of the enforcement decision at the moment it was written. Ed25519 signing is active (since 2026-06-07), and the public key is published — so any third party can verify a receipt offline, forever.
The receipt is the evidence — the gate is just where it was produced. The audit trail survives system migrations, vendor changes, and the decommissioning of AgenticRail itself. The signed records remain verifiable. (Receipts issued before the cutover are HMAC-SHA256 — symmetric, so verified through the report endpoint; the verifier picks key and algorithm per-receipt, so a chain spanning the cutover verifies intact.)
Active signing key — Ed25519, offline-verifiable by anyone:
kid: k2_2026-06-07_ed25519 spki: MCowBQYDK2VwAyEA1ejM0xb/nkaPO8NhNWtXHOpqR1BgYqAOLWqig02FZdI=Full keyring (JWKS + SPKI, with the retired HMAC key id) at
/spec/receipt-public-keys.json.
Verify a receipt's signature against the canonical JSON of the receipt with the signature field removed — see /spec/canonical.txt.
payload_hash receipt is privacy-preserving structural evidence: proof of the event, without disclosure of the event's content.
One command. This is what you hand to your lawyer.
After any sequence completes, one call to the report endpoint generates the full provenance record — every receipt, every decision, chain-verified from step 0 to N, with an audit narrative written for regulatory submission. No login, no manual export, no reconstruction.
Every receipt's HMAC signature is verified. Chain linkage (prev_receipt_id) is checked step by step from the first receipt to the last. If any receipt was altered after writing, the verification fails and the report flags the broken link.
The verification is deterministic — run it once, run it a hundred times, the result is the same. Anyone with the sequence ID can verify independently.
A two-paragraph compliance statement generated for each sequence — written for EU AI Act Article 11 technical documentation requirements and suitable for regulatory submission.
Not a template. Generated from the actual enforcement record: the steps that ran, the decisions made, the evidence embedded at each step.
# Generate the full HTML provenance report for a sequence curl -X POST https://report.agenticrail.nz/report \ -H 'Content-Type: application/json' \ -H 'x-slp8-key: YOUR-API-KEY' \ -d '{ "sequence_id": "your-sequence-id", "format": "html" }' # Or JSON — for programmatic ingestion, automated compliance filing curl -X POST https://report.agenticrail.nz/report \ -H 'Content-Type: application/json' \ -H 'x-slp8-key: YOUR-API-KEY' \ -d '{ "sequence_id": "your-sequence-id", "format": "json" }'
Demo sequences are public — no API key required. Use the public demo key DEMO-AGENTICRAIL-PUBLIC-2026 and any sequence ID prefixed demo-.
Same product. Same receipt chain. Different question.
AgenticRail was built for teams under enforcement pressure. The enforcement framing — ALLOW/DENY, fail-closed, sequence blocking — is the right frame for engineers integrating AI agents into production systems. The provenance framing is the right frame for the conversation that happens after: when the lawyer, the auditor, or the regulator asks what the AI actually did.
Already has an AI agent running. Feels the risk of uncontrolled actions — steps skipping, replay attacks, sequences proceeding without authorisation. Thinks in terms of gate calls, DENY codes, and fail-closed design.
Comes to AgenticRail through the enforcement door.
- ALLOW / DENY before each step executes
- Replay and skip enforcement at infrastructure level
- Sequence sealing — no re-entry after completion
- SDK integration in three lines
Has been told by a lawyer, an auditor, or a DPO to document what the AI is doing. Doesn't think about enforcement. Thinks "I need a paper trail I can show someone." May not know — or care — how the enforcement works underneath.
Comes to AgenticRail through the provenance door.
- GDPR Article 5(2), 22, 30 — satisfied structurally
- Full sequence record on demand — one command
- Tamper-evident — verifiable by any auditor
- Chain proof + audit narrative ready for submission
These are not two different products. The engineer who integrates the gate produces the provenance record as a structural side-effect. Every ALLOW is both an enforcement decision and a provenance event. The compliance buyer does not need to change anything about the integration — they just need to know the report endpoint exists and what it returns.
See a live provenance report
Run a demo sequence. Pull the full chain-verified record. No login, no API key, no signup. This is what you hand to your auditor.
See the provenance report → Full compliance matrix →