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.

Is this a guardrail?

Partly, and the difference is worth being exact about. 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.

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

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.

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 sealed sequences are additionally copied 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 the witness copy. That archive is not yet held by a separate custodian, which is the residual set out below rather than hidden.

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.

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 honest 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 one before it, and whether the sequence sealed. For sealed sequences the report also shows when a separately-held write-once archive received its copy, which corroborates the timing from a different system without being an attested timestamp.

If the company disappeared tomorrow, would verification still work?

For any receipt and public key you already hold a copy of: yes, permanently — Ed25519 verification is pure offline math, it does not call home. The honest limit is upstream of that: fetching a receipt from the live report tool, or fetching the keys fresh from the live site, needs the company's infrastructure to be running. Anyone who wants verification to survive the company should save the receipt and the public keys themselves. This is also the exact gap the independently held archive exists to narrow, not fully close — it protects against the operator quietly rewriting history, but the archive is not yet run by a separate custodian, so that residual case is disclosed, not hidden.

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. That is the honest answer, and it matters, so 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. That is disclosed rather than hidden.

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.

Is AgenticRail SOC 2, ISO 27001 or ISO 42001 certified?

No. None of the three, and no certification is claimed anywhere on this site. What exists instead is evidence a third party can check: a published enforcement specification with every version frozen and fingerprinted, public verification keys, receipts that verify offline in your own code, and a documented adversarial test record.

Those are different kinds of assurance and the difference is worth stating plainly. A certification attests that an organisation follows its stated processes, assessed periodically by an auditor. A receipt chain lets anyone check a specific claim about a specific sequence at any time, without trusting the organisation or the auditor. Certification is a reasonable thing for a buyer to require, and for some procurement it is mandatory. We do not have it, and we would rather say so than imply otherwise.

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. It holds no certification either, and claims none. 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 honest 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 copy held somewhere the signer cannot reach, which is why sealed receipts are 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. 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. It is worth being plain about 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.