Frequently Asked Questions — Proving an AI Safeguard Actually Ran

What does it mean for an AI safeguard to be provable rather than just claimed?

There are three tiers. Asserted: a policy or press release states the check happens, but the system doesn't require it and no independent record exists. Enforced: the system structurally cannot proceed past a skipped or out-of-order step — a decision with a missing safeguard is denied before execution, not flagged. Provable: every decision leaves a cryptographically signed, sealed, tamper-evident receipt of the steps that ran, in order, verifiable by a party outside the operator, offline, against published keys, without trusting the operator's servers. Most deployed safeguards today sit at tier one.

How is this different from a normal system log?

A log written by the same system whose conduct is in question answers a narrower thing than people assume. "We logged it" is not the same as "we can prove it" — a log that can still be added to, edited, or tidied after the fact cannot establish that what it shows is the complete account as it stood at the time. A provable record is created before the action, independent of the system being recorded, cryptographically signed, and sealed, so the account is fixed at the moment it happened and cannot be reopened without leaving a detectable break.

There is also a whole class of failure a log cannot report at all, however honest it is. If a step never runs, it writes nothing — no error, no warning, no gap — and what comes back is a complete record of everything that did happen. A correct run produces the same thing. The log is not concealing the omission; it has nothing to conceal it with, in the way a numb foot is not hiding an injury. A family tree shows the same failure plainly. Remove one generation and what is left is still a list of names: it reads correctly, it recites fluently, and nothing in it marks the hole. You see the gap only if you already knew who belonged there. It is also not a shorter family tree. It is not a family tree at all — descent is a chain, so a missing link does not weaken the claim, it voids it, and the names that remain no longer establish that anyone came from anyone. Catching that requires a statement of what should have happened, made before the run, by something other than the system doing the work. Why a skipped step leaves nothing behind.

Is this a guardrail?

Partly. Content guardrails filter what a model says — toxicity, PII, jailbreaks — by reading the text. AgenticRail never reads content and does nothing about what a model writes. The second sense is closer: a rule about what an agent may do. Most implementations of that are advisory — the rule is described to the model in a prompt or a docstring, or checked by a second model — so a confident agent can reason its way around it, or simply not call the checker.

AgenticRail is runtime enforcement in the strict sense. The check is a call made before the step runs, the verdict is computed by deterministic code rather than inferred by a model, and a DENY comes back the same way no matter how the agent argues for itself. The gate is a deterministic control plane sitting outside the model, so it cannot be persuaded, and it does not get more permissive under a longer context.

In AI runtime security terms, it is a control on one part of excessive agency, the OWASP Top 10 for LLM Applications risk of an agent taking actions it should not: it refuses any tool call or step that falls outside an order declared before the run began. It does not limit what an agent is permitted to reach or what tools it has; that remains the job of access control. Every decision, ALLOW or DENY, becomes a signed, tamper-evident receipt.

The limit: this is enforcement at the point of integration. An action routed through the gate cannot proceed without a verdict, but a code path never wired to the gate is outside it. Where you place it matters far more than any setting in it.

Can AgenticRail stop a rogue or misaligned AI agent?

It does not detect misalignment and does not read what an agent intends. Any step routed through it that falls outside the order declared before the run is refused, so an unsanctioned step is denied rather than carried out, and every decision, ALLOW or DENY, becomes a signed, tamper-evident receipt from a party other than the agent’s owner.

It does not see how a permitted step is carried out: an agent that bypasses an access control, uses exposed credentials or injects a command inside a step it was allowed to take is outside the gate, as is any action on a path never wired to it.

What changes after an incident is the record: instead of the agent’s owner searching its own logs for what went wrong, there is an account signed by someone else of what the agent was permitted to do, in what order, and what it was refused.

Is AgenticRail a policy enforcement point?

Yes, in the standard meaning of the term. It sits in the path of the action, receives a proposed step, and returns permit or deny before that step executes. If your vocabulary comes from XACML or Zero Trust, the gate is the PEP and the published enforcement specification is the policy.

Two differences from a classic PEP are worth knowing. First, a classic PEP evaluates each request independently — the same request gets the same answer whenever it arrives. AgenticRail's answer depends on the run: an identical call is ALLOW at the right point and DENY as a replay, out of order, or after the sequence is sealed. That is deterministic sequencing, and the state is the product rather than an optimisation. Second, a PEP normally writes its decision to a log or an observability pipeline. Here the decision becomes a signed, hash-chained receipt that verifies offline against a published key, so the enforcement record is evidence rather than an entry the operator could later edit.

One thing the term can imply that is not true here: AgenticRail does not accept, hold or version your action-type policy: those rules are the enforcement layer's own and fixed. The step order is always yours. On the demo lane and with a self-serve key the caller declares it on the first call of a sequence; in a deployment it is set in the gate at setup, so the agent does not choose it (who declares the order). A policy engine such as OPA or Cedar is where per-deployment action rules belong; holding a customer's action-type rules would make this a configured part of their system rather than something independent of it. What is enforced here is sequence, not policy.

Is this "verifiable execution" or "proof of execution"?

No, and we would rather decline those terms than stretch them. Both usually promise that the work itself ran correctly, often backed by a trusted execution environment or a proof over the computation. AgenticRail proves something narrower, and the field names say so: a receipt's executed means the enforcement decision was ALLOW — the step was permitted. It does not assert that the downstream action ran or succeeded. The executor's outcome is reported separately as execution_submitted and is deliberately not signed into the receipt.

So what is provable here is the decision and its order: which steps were permitted, in what sequence, against an order declared in advance, each bound to a hash of the record. Whether a permitted action then did what it claimed is a question about your system, not ours — and a receipt that implied otherwise would be exactly the self-reporting problem this exists to remove.

Do I have to trust the company that built this?

Not to verify a receipt. Verification runs entirely offline, against public keys published at agenticrail.nz/spec/receipt-public-keys.json, with standard Ed25519 verification code you run yourself — no network call to AgenticRail required. A sealed sequence also cannot be reopened without leaving a detectable break in its hash chain, and a fingerprint of each sealed sequence is additionally written to a separate write-once archive under its own credential at the moment of sealing, so a rewrite of the primary store is detectable against that witness. Who holds that archive is your appointment, settled at deployment: an archive run by us would put the record back in the hands of the party being checked, which is the arrangement it exists to avoid.

Does this work with any AI system, or only a specific vendor's?

The gate sits between an agent and its downstream actions and evaluates the request payload against a declared policy — it does not care which model or vendor produced the request. Any agent, on any model, can be wired to call the gate before it acts. It is an independent enforcement layer, not a feature of one AI provider's stack.

Does AgenticRail only work with AI agents, or with any automation?

Any automation. AgenticRail is sequence verification for an automated process: it holds each step to an order declared in advance and signs every decision, and it does not know or care whether a model is involved. A scheduled job, a script, a CI pipeline, a webhook chain or a no-code workflow calls the same HTTP endpoint an agent does.

The failure it exists for is older than AI. Out-of-order execution and skipped steps in ordinary automation return success like everything else, so monitoring that checks liveness reads them as healthy and they surface later, at an audit or a reconciliation. Agents make the defect more frequent and add a decision-maker that can choose its own route, which is why they are the urgent case rather than the only one. The terms are defined one by one in sequence verification, defined.

One integration detail matters for simple automation. A refusal normally returns HTTP 200 with decision: DENY, and a tool that reads only the status code treats that as success and carries on. Add ?deny_status=409 to the request URL and every refusal returns HTTP 409 instead, so the flow stops on its own. The body and the signed receipt are the same either way.

This has been tested with n8n. With the flag, its HTTP Request node fails on a refusal and the workflow stops before the next step. Without it, n8n reads the refusal as success and runs the next step anyway, which is the failure the flag exists to prevent.

What does it actually take to implement this?

An agent declares its own step order and calls the gate before each action with a small payload — sequence_id, step, function, action_type, action, inputs, a fresh nonce, and a timestamp. The gate returns ALLOW or DENY before the action runs. Python and JavaScript SDKs wrap this contract directly. Full payload contract and API reference: agenticrail.nz/docs/.

Is this specific to New Zealand, or could any country or agency use it?

The mechanism itself is not jurisdiction-locked — the receipt chain is citable as evidence under frameworks including EU AI Act Article 12, ISO/IEC 42001 A.6.2.8, and NIST AI RMF Measure 2.4. The company's current outreach is focused on Aotearoa New Zealand, but nothing about the enforcement mechanism or the receipt format restricts it to any one country or agency.

Is there a public verifier anyone can use in a browser?

Yes, and it is not only a browser tool. Open report.agenticrail.nz/report, paste a sequence ID, read the report — no account, no login, no sign-up, nothing to install. The same endpoint answers any HTTP client, with no key at all: a plain urllib, Java or Go request returns the full report, so a compliance script can pull it exactly as easily as a person can open it. Demo sequences are open to anyone, so the mechanism can be checked end to end without asking us for anything.

The report gives you each receipt's raw Ed25519 signature alongside the exact signed_canonical preimage the signature was computed over, plus the key_id. That's deliberate: the browser tool is a convenience, not the proof. You are not asked to trust it. Take the preimage and the signature out of the report, run ed25519_verify against the published keys in your own code, and you never touch our servers again. The limits: fetching a report needs our infrastructure to be running, and reports for a client's own sequences require that client's key.

How do you verify a receipt without contacting AgenticRail?

Fetch the published public keys, take a receipt's signed_canonical preimage and its signature, and run ed25519_verify(public_key, signed_canonical, signature) in your own code. That's the whole check — no account, no callback, no dependency on AgenticRail's servers being up. Flip one character in the signed content and the verification fails.

Does a receipt prove when something happened?

It records when, and that time is signed into the receipt, so it cannot be changed afterwards without breaking verification. But the caller supplies the value, so the signature proves the time was not altered after the fact rather than proving the time is true. What bounds it is the gate refusing any timestamp more than 300 seconds from its own clock, which constrains the claim without establishing it. It is not attested by an independent party. What a receipt does prove on its own is the order the steps ran in, that each receipt commits to the exact content of the last permitted receipt before it, and whether the sequence sealed; receipts issued from 8 October 2026 also carry a signed number for every decision, so a missing receipt, permitted or refused, shows as a gap. For sealed sequences the report also shows when a separately-held write-once archive received its fingerprint, which corroborates the timing from a different system without being an attested timestamp.

Can this help with AML, KYC or customer due diligence?

Indirectly, and the distinction matters. AgenticRail performs no screening of any kind and holds no customer, sanctions or company registry data. It does not do customer due diligence, and it cannot tell you whether someone is a beneficial owner or a sanctions match. What it does is enforce and evidence the order the checks ran in.

That is narrower, and in anti-money-laundering law it is also a specified thing. UK regulation 30(2) requires the customer's identity to be verified before the business relationship is established, and the exception at regulation 30(4) permits verification after an account is opened only where adequate safeguards ensure no transaction is carried out first. Both oblige a firm to evidence a negative fact about ordering — that nothing happened before the thing that was meant to happen first. A log is poorly shaped for that, because a step that never ran leaves no entry. A refused step, signed and chained, turns that absence into an artifact.

The full argument, with the statutory citations and the limits, is at agenticrail.nz/spec/customer-due-diligence/.

Does AgenticRail work with LangGraph, CrewAI, or LangChain?

Yes. The gate is a plain HTTPS JSON call made before each step, so it works with any agent framework and does not care which model or vendor produced the request. The Python SDK ships purpose-built integrations for LangGraph and CrewAI, with runnable examples for both. The JavaScript SDK ships no framework-specific modules: it is a plain client that drops into any JS agent loop, whether that is LangGraph.js, Mastra, Genkit or your own. Agents that speak Model Context Protocol can call the gate directly through the MCP server at mcp.agenticrail.nz, which exposes evaluate_step and verify_receipt as tools.

There is nothing framework-specific in the enforcement itself: the framework decides what your agent wants to do next, and the gate decides whether it is allowed to do it. Integration detail is at agenticrail.nz/docs/, and the machine-readable API description is at agenticrail.nz/openapi.json.

Can I run AgenticRail myself, and who holds the signing keys?

AgenticRail is a hosted service today. There is no self-hosted build, and AgenticRail holds the receipt signing keys. Here is precisely what it does and does not mean.

Because every receipt ships with the exact preimage its signature was computed over, you never have to trust our verifier — you check signatures yourself, offline, in your own code, against published public keys. What key custody does affect is narrower: someone holding the signing key could in principle rewrite an entire chain and re-sign it, and the hash chain alone would not catch that. A second, write-once archive held under a different credential exists to catch exactly that rewrite, and every report compares against it. The residual we do not claim to have closed is the account owner, who can reach both stores.

Closing it does not require new engineering. It requires the archive, or the signing key, to be held by someone who is not us — an ordinary commercial arrangement with an established industry behind it: escrow agents, trustee corporations, qualified trust service providers, or your own law firm under a deed. No such custodian is engaged today. Which one holds it, and what conditions release it, is a term settled at deployment rather than a decision we make on your behalf. That is why there is no automatic key issue and why getting one starts with a conversation.

Which agentic AI tools are ISO 42001 certified?

None of them, and none can be. ISO/IEC 42001:2023 is a management system standard: it certifies that an organisation operates an AI management system meeting the standard, within a defined scope. There is no product conformity scheme under it, so no tool, model, framework or API holds the certification.

A vendor may hold ISO/IEC 42001 certification as an organisation. That certificate covers their management system rather than the software they sell you, and it produces no records about your deployment, which is what your own certification auditor will ask to see. Two fields carry almost all of a certificate's meaning: the scope statement, which defines which parts of the organisation and which activities are covered, and the certification body, and whether it is accredited by a recognised national accreditation body.

AgenticRail is not in this category at all. There is no language model anywhere in its decision path and no model is consulted. Zero AI influence on the gate itself, no chatbot, nothing that guesses. It governs AI agents rather than being one. The longer answer, including the three questions worth asking a vendor instead, is in Which agentic AI tools are ISO 42001 certified?

What does it mean for a sequence to be sealed?

A sequence seals when the last step in the order the caller declared is allowed. From that moment no further step is accepted into it: anything else presented against that sequence identifier is refused with SEALED_SEQUENCE. Sealing is not a status flag someone sets, it is what happens when the declared order runs out.

The point of it is that a sealed sequence is finite. An open record can only ever say what happened so far, which means it cannot be hashed as a whole, archived as one object, or cited as a complete account of anything. A sealed one can. The limit: the hash chain makes a single altered receipt detectable immediately, but a full rewrite of everything downstream by whoever holds the signing keys is not caught by the chain on its own. What catches that is a record held somewhere the signer cannot reach, which is why a fingerprint of each sealed receipt is also written to a separate archive under its own credential. The report shows seal_status as SEALED or OPEN so you never have to infer it.

Why can't the agent doing the work certify that the work was done?

Because it is not allowed to. The step that carries out the action can only select the next step or pause the cycle. Recording a result is not among the actions available to it, so an agent cannot mark its own work complete no matter what it sends. Attempting it is refused.

Recording a result happens at a later, separate step, and even there it must name the artifact it is attesting to. That reference is checked twice: it has to match the last allowed receipt that was durably written, and that receipt is then fetched back and confirmed to exist, to be an ALLOW, and to be the step immediately before. A pointer that merely looks right is not enough. If the binding is missing or does not match, the record is refused with ARTIFACT_UNBOUND. This is ordinary segregation of duties, which is a routine expectation in audit and risk practice and structurally absent from most agent deployments.

What happens when a step is presented out of order?

It is refused before it runs, with SEQUENCE_VIOLATION, and the response tells the caller which step the sequence was actually waiting for. Nothing executes. The agent is not trusted to notice the problem and stop itself, because an agent that skips a step generally does not know it skipped one.

The refusal is then written as a signed receipt of its own, and that is the part which matters. A step that never ran leaves no line in an ordinary log, so its absence is invisible and unfalsifiable afterwards. A declared order converts that silence into a dated, signed record of an attempt that was denied. The sequence is not destroyed by it either: the caller can present the correct step against the same sequence identifier and carry on. One ordering detail worth knowing, since it changes which refusal you see: the action type is checked before the position, so an action that is not permitted at that step is reported as ACTION_NOT_ALLOWED and masks the ordering problem underneath it.

How much does AgenticRail cost?

Two different things are on sale, and they are not two sizes of the same one. A developer key is US$39 a month, bought without speaking to anyone, 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, which matters on any engagement longer than a month. It is limited to 120 requests a minute, about fifteen eight-step sequences, and there is no monthly quota. The key is emailed when the payment clears. Buy a developer key.

A deployment has no list price, because what an organisation takes on there is a working reference deployment and the support to run it, not a quantity of anything. It is priced per deployment and it starts as a conversation, at 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.

Evaluation still costs nothing and needs no account. The public demo key works immediately, the verifier is open to anyone in a browser, and the enforcement specification, receipt schemas and public keys are all published, so the mechanism can be tested end to end before any money changes hands. What the developer tier does not buy: it is the same gate, enforcing the same rules, and it unlocks no capability the demo key lacks. What you are paying for is privacy and persistence, not power.

My AI agent did the work. How do I prove it followed the process?

Not afterwards, and that is the whole difficulty. A log can only report what it contains. When an agent skips a required step, nothing is written, because nothing happened — so the omission leaves no entry to find. Reading the record back tells you what the agent did do, never what it was supposed to do and didn't. The word complete has no meaning unless something declared in advance what should have been there.

So the order has to be declared before the run, not reconstructed after it. You send the steps your process requires, in the order it requires them. Each step is submitted to the gate before it executes, and a step presented out of order is refused with SEQUENCE_VIOLATION and never runs. Every decision, permitted or refused, is written as a signed receipt bound to a hash of the one before it. The proof is not a narrative anyone assembled later; it is the sequence of decisions itself, and a refused attempt is as much a part of it as a permitted one.

Be clear about what this does and does not establish. It proves which steps were permitted, in what order, against a list declared in advance, and that none was skipped or replayed. It does not prove the work inside a step was correct — a permitted step can still produce a wrong answer, and any system claiming otherwise is reporting on itself. Ordering is the part that cannot be checked by reading the output, which is exactly why it is the part worth enforcing.

My software vendor put an AI agent in the product. I am liable for the output. What can I do about it?

About their agent, directly: nothing, and you should be told that plainly rather than sold something. Enforcement runs in front of a step, so it can only be applied by whoever operates the agent. If the agent is embedded in software you licence, that party is not you.

What you are describing is a split between control and consequence. The vendor decides what the agent does; you sign the work it produced and carry the professional or regulatory exposure for it. Those two things now sit in different companies, and no product you buy can move them back together.

Two things are still available to you. The first is a question worth putting to the vendor in writing, because the answer is informative either way: can you evidence the order your automated steps ran in, or only the output they produced? Most systems can produce the second and not the first, and a vendor discovering it cannot answer is how the requirement eventually reaches it. The second is narrower and entirely yours: wherever your own organisation runs its own agents, control and liability are held by the same party, and that is the place enforcement can be applied today.