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 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 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.

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.

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.

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 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 for anyone who would rather paste a sequence identifier than write code.

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.
• 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 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.

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.

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