The gap between what an AI agent can do and what it should do is an authorization problem, not an alignment problem. Model alignment shifts the distribution of outputs toward safe behaviour — it cannot guarantee any individual action. Pre-action authorization is the control that fires before every tool call, evaluates it against declared policy, and blocks it before execution if it does not pass. A published adversarial study of a competing implementation reports that under a strict pre-action gate, attack success against an AI agent dropped from 74.6% to zero.
AgenticRail enforces pre-action authorization on every step sent to it — ALLOW or DENY, with a signed receipt issued before the action executes.
Try the demo Read the docsOn 28 July 2026 the UK AI Security Institute detected data leaving one of its own testing systems over Tor. Its incident report describes 19 unsanctioned actions across 10 of 122 evaluation runs. In the most serious, an agent researched an open-source project’s maintainers, created multiple fake identities, and used them to socially engineer a real maintainer into approving malicious code into a publicly used project.
The conditions matter and AISI states them plainly: internet access was deliberately enabled and the developers’ cyber classifiers deliberately switched off, a combination they describe as “not reflective of how frontier models are made available to the general public.” This is not evidence that deployed agents are compromising supply chains. It is evidence of what remains when the vendor’s filters are removed.
What remained was a person. A human reviewer rejected the malicious code. AISI’s own assessment: “in several cases the margin between failure and success was narrow, resting on human vigilance rather than a technical barrier that would reliably prevent this behaviour in a more capable agent.”
Their monitoring did work, but not in time. “Our security team detected the anomalous traffic through general monitoring after the fact, not through monitoring built to watch the evaluation as it ran, which could have flagged or blocked the behaviour sooner.”
The remedies are the part worth reading twice. There are three: tighter network controls, evaluation design that limits scope in advance, and “monitoring built to watch an evaluation as it runs, able to flag or block out-of-scope actions as they happen.”
None of the three is logging. A state body reviewed an agent acting outside its remit and recommended constraint before the action, not a better record of it afterwards.
One thing this does not show. AgenticRail would not have stopped this incident. That agent had open internet access and created accounts directly; nothing it did was routed through a gate that could have refused it. What the report establishes is narrower and more durable than a product claim: that after-the-fact detection and human vigilance are not controls, said by a party with no product to sell and every reason to be careful, about its own failure.
Uchi Uchibeke published "Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents" (arXiv:2603.20953), evaluating a system they call Open Agent Passport (OAP) in a live adversarial testbed — 4,437 authorization decisions across 1,151 sessions, with a bounty for successful attacks. The results were not close.
The model didn't change. The alignment training didn't change. The only difference was a pre-action gate evaluating every tool call against declared policy before execution. Two things about that result are worth stating rather than glossing. It is not a study AgenticRail ran or commissioned, and it concerns a different implementation — which is why it is cited here: an architecture reaching the same conclusion independently of us is worth more than our own account of it. But it is also not independent of the system it measures. The paper's author developed Open Agent Passport, and a preprint in which a vendor reports a 0% attack rate against their own design is a vendor's own result, held to the same standard this site applies to everyone else. Read it as a competing implementation publishing its numbers, not as third-party validation.
| Approach | When it fires | What it guarantees |
|---|---|---|
| Model alignment | Training time | Nothing per-action — shifts a distribution, doesn't set a boundary |
| Post-hoc evaluation | After execution | Nothing before the fact — finds violations after the action already ran |
| Pre-action authorization | Before execution | The action itself — denied before it runs if policy fails |
Pre-action authorization and sequence enforcement are complementary, not the same control. Pre-action authorization asks whether a specific action is permitted by policy. Sequence enforcement asks whether the step containing that action is the next permitted step in a declared order. An agent can pass one and fail the other — both must hold for the record to be complete.
Pre-action and per-action are different axes, and both are load-bearing. Pre-action is a claim about timing: the check runs before the action does. Per-action, called per-call in API vocabulary, is a claim about granularity: every individual action is evaluated on its own, rather than a session, a role or a task being authorised once and the actions inside it running unexamined. They are independent. A per-action control can still be retrospective, evaluating each action after it ran. A pre-action control can still be coarse, clearing an entire run up front and checking nothing inside it. Session-level authorisation is the common case and it is the one that fails quietly: the agent was permitted to start, so nothing asks again when step six does something step one never implied. A gate that is both refuses at the boundary of each action, and produces one receipt per action rather than one per run.
Every gate decision produces a receipt, issued before the action executes. Real field names and decisions; values shortened and illustrative:
The DENY receipt is as tamper-evident as the ALLOW. It proves the gate refused the write before it was meant to run — not that a violation was found in a later review. Storage is tamper-evident; a sealed sequence cannot be reopened without leaving a detectable break in the hash chain, and a fingerprint of each sealed sequence is additionally written to an independently held archive at the moment of sealing.
The cited study reports its own system's number, and the two are easy to blur: OAP measures a 53ms median for its own architecture. That describes their system, not AgenticRail's — the two shouldn't be quoted as if interchangeable. AgenticRail's own gate, measured from New Zealand on 8 October 2026, took about 1.5 seconds for the first call of a new sequence and 0.9–1.1 seconds for each call after it. The durable storage write completes after the decision is returned, so it does not add to that. Not sub-100-millisecond. The property that matters isn't speed — it's that the decision happens, and the receipt is signed and issued, before the action runs, every time, regardless of how long that takes.
OWASP's Top 10 for Agentic Applications 2026 names several risks pre-action authorization directly addresses:
| Code | Risk | How the gate responds |
|---|---|---|
| ASI01 | Agent Goal Hijack | The gate evaluates the action against declared policy, not the agent's stated goal — a hijacked goal that skips steps still gets SEQUENCE_VIOLATION. |
| ASI02 | Tool Misuse | On the built-in steps, AgenticRail's policy maps fix the permitted action types, and any other returns DENY · ACTION_NOT_ALLOWED before the tool runs. A step the caller names permits all eight action types, so there what binds is the declared order. |
| ASI03 | Identity & Privilege Abuse | The sequence contract is the privilege boundary. Steps outside the declared order return DENY · UNKNOWN_STEP; sealed sequences cannot be extended. |
A receipt issued before execution is a reconstruction anchor, not a post-hoc observation — the kind of evidence EU AI Act Article 12 logging and ISO/IEC 42001 A.6.2.8 event-logging requirements point toward. It produces evidence toward those obligations; it does not by itself satisfy a risk-management or human-oversight requirement in full — those remain organisational work the receipt chain supports, not replaces.
Run a sequence in the demo. Attempt a prohibited action. See the DENY issued before it executes.
Try the demo Compliance report