# 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 <key>`. 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