Frequently Asked Questions — Proving an AI Safeguard Actually Ran
Direct answers, no pitch. Every answer below is drawn from AgenticRail's published docs and specs — nothing here is a new claim.
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 an independently held write-once archive at the moment of sealing, so even a rewrite by the operator is detectable against the witness copy.
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.1.6, 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 AgenticRail generates the timestamp — the signature proves we asserted that time, not that the time is correct. 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.
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 covers LangGraph.js, Mastra, Genkit and custom loops. 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 or ISO 27001 certified?
No. Neither, and no certification is claimed anywhere on this site. What exists instead is evidence a third party can check without taking our word for it: 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.
How much does AgenticRail cost?
There is no public price list and no self-serve sign-up. Pricing is set per deployment, because what an organisation takes on is a working reference deployment and the support to run it, not a number of seats.
Evaluation 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. The mechanism can be tested end to end before any conversation about money. For a figure against a specific deployment, hello@agenticrail.nz.
Full enforcement spec — agenticrail.nz/spec/
Asserted vs. enforced vs. provable, with Robodebt as the case study — agenticrail.nz/spec/enforceable-safeguards/
Verify a real sealed record — report.agenticrail.nz/report
API documentation — agenticrail.nz/docs/