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 — 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.
Every gate decision produces a receipt, issued before the action executes. Real fields, not illustrative placeholders:
The DENY receipt is as tamper-evident as the ALLOW. It proves the gate intercepted a violation before the write executed — 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 sealed sequences are additionally copied to an independently held archive at the moment of sealing.
Worth being honest about, since the cited study reports its own system's number and it's easy to blur the two: 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, pressure-tested under real adversarial load, measures roughly 1.5–2.1 seconds for a cold-started sequence, with a further ~0.6–0.7 seconds of durable-storage write cost on every call. Not sub-100-millisecond. The property that matters isn't speed — it's that the decision happens, and the receipt is written, 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 | Policy declares permitted functions and action types per step. An action type not in policy returns DENY · ACTION_NOT_ALLOWED before the tool runs. |
| 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 pre-action receipt written 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 receipt written before it executes.
Try the demo Compliance report