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 refuses before the fact rather than recording after it. 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.

Put plainly: it removes the excuse. The gate does not prevent the consequence of a step that was skipped — it removes the sentence there was no way to know. A skipped step writes no log line, so its absence is where the explanation goes afterwards. A declared order takes that away.

What it is used for

Five situations, all of them cases where a safeguard exists on paper and the evidence that it operated does not.

• Regulated onboarding and money movement. Customer due diligence and third-party due diligence state the order itself as the obligation. New Zealand's Anti-Money Laundering and Countering Financing of Terrorism Act 2009 requires a reporting entity to carry out verification of identity before establishing a business relationship or conducting an occasional transaction or activity (s16(2)), and permits verification afterwards only where three conditions hold together, among them that money laundering risk was managed by transaction limitations and account monitoring in the meantime (s16(3)) — which is a claim about what did not happen first. Supplier and contractor onboarding has the same shape: company registry checks, beneficial ownership, sanctions and exclusions screening and jurisdiction checks are expected before engagement or payment rather than after it. The gate performs none of those checks. It refuses a step taken out of the order the caller declared in advance, and produces a signed record of the order that did run. Worked through in the customer due diligence brief.
• 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 2 December 2027 for stand-alone systems and 2 August 2028 for high-risk AI embedded in regulated products. See the EU AI Act summary and the completeness specification.
• 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.
• 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.
• 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 and the NIST AI RMF mapping. Neither is a certification AgenticRail holds — see the limits below.

The recurring shape across all five 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.

The shape is not specific to agents or to AI. Australia's Robodebt programme substituted an annual income average for the per-fortnight determination its legislation required, and the Royal Commission into the scheme reported in July 2023 that this was inconsistent with social security legislation. No model was involved. What agent deployments change is the rate at which the defect occurs and the fact that the account of what happened is written by the system that acted.

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.

The method is published and unpatented, so a team could build its own gate. What that produces is a record the operating organisation wrote about its own agent — the same position as the log it was meant to improve on. The specification is published so that a receipt can be checked without trusting us, not as a kit to deploy.

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.

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. Zero AI influence on the gate itself, no chatbot, nothing that guesses.

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.

This is sequence enforcement, not policy enforcement, and the distinction is deliberate. When you declare your own step order, every step accepts any of the eight standard action types, so ACTION_NOT_ALLOWED does not constrain a custom sequence — the narrow per-step lists belong to the eight built-in steps. What is enforced for a caller-declared order is the order itself, replay, freshness, sealing and chain integrity: five conditions, every one of them a fact about what came before. AgenticRail does not accept, hold or version your action-type policy. That is the job of a policy engine, it is a well-served one, and holding your rules would make this a configured part of your system rather than something independent of it. The receipt names the rule set that judged each step, so the record says which applied rather than leaving it blank.

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 never enter the receipt at all. It carries payload_hash, a SHA-256 of the whole request body, and none of its content. 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 as a convenience, and that copy is served to any HTTP client without a key. Carrying the bytes inline means verification never depends on reaching us at all. The keyring never shrinks, so receipts signed under a retired key continue to verify.
• A hosted verifier is available at report.agenticrail.nz/report for anyone who would rather paste a sequence identifier than write code.
• A published worked example carries a real sealed sequence, one receipt in full with its exact signed preimage, and runnable code that verifies the signature offline against the public key.
• The check is deterministic and reproducible. Verifying a receipt is a function of two things only: the receipt bytes and the public key. Two auditors running it in different code, a year apart, on machines that never reach us, get the same result. Nothing in the outcome depends on when it is run, who runs it, or whether we are still here.

How it is integrated

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.
• It does not replay execution. A receipt carries a SHA-256 of the whole request payload and none of its content, so there is nothing in it to reconstruct or re-run from, and AgenticRail is not an execution runtime. Replay elsewhere on this page means the refused attack — a reused nonce, denied as REPLAY_NONCE — and not a reproduction facility. What re-runs deterministically is the verification; what the chain reconstructs is the order in which steps were permitted and refused.
• 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 caller supplies the value. What the gate does is refuse any timestamp more than 300 seconds from its own clock, which bounds the claim without establishing it. 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, and the published specification is not one.
• 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.
• It enforces one agent's sequence, not several agents' handovers. The published receipt schema v3 names four multi-agent failure classes — SPLIT_AUTHORITY, CIRCULAR_AUTH, CHAIN_BREAK and AGENT_HANDSHAKE_FAIL — and the surfaces that would emit them are specified and not deployed. Nothing here should be read as evidence that they are. What is enforced today is a single declared sequence, start to seal.

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 carries a copy-paste request, and the browser 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.

Evaluate it on your own process, not on ours. The eight-step spine in the examples is a default, not a requirement. Send step_order with the step names your own process uses — verify_identity, screen_sanctions, approve_payment, whatever they are — and the gate enforces that order instead. One step is a valid sequence. Present a step out of turn and it is refused before it runs, with a signed receipt of the refusal.

What you are left holding is the point. At settle the sequence seals and the report is a URL that opens with no key, for anyone you send it to: the steps your process declared, the order they ran in, every refusal along the way, each receipt signed and hash-linked to the one before it. That is a record about your workflow rather than a demonstration of ours, it costs nothing, and it is the thing to put in front of whoever has to be convinced — a compliance officer, an auditor, a board. They can check it without asking us anything, which is the whole claim, tested on your own process rather than described.

Two shapes, and they are not two sizes of the same one. A developer key is self-serve at US$39 a month, and what it changes is who can see your work. Your sequences move off the public lane, so their identifiers, your step names and anything you place in attestation stop being world-readable. Your receipts persist instead of being deleted on the demo lane's 30 day clock — on any engagement longer than a month that clock otherwise reaches your earliest evidence while the work is still running. It is the same gate enforcing the same rules, and it unlocks no capability the public demo key lacks. Buy a developer key.

A production deployment has no list price, 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. If you want to start one, the useful first message is short: the steps you need enforced, and who has to be able to check the evidence afterwards. That is enough to say what a deployment would look like for it. hello@agenticrail.nz.

On a developer key, the gate, the receipts and the signing key are all on our infrastructure. A deployment is where that placement changes. What that closes, and what it does not, is set out under key custody — what the operator could do.

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.

Further reading