# Pre-Action Authorization for AI Agents: The Missing Security Layer

> Markdown mirror for AI agents, generated 2026-08-12 from the live page.
> Canonical: https://agenticrail.nz/blog/pre-action-authorization-ai-agent/
> Site context: https://agenticrail.nz/llms.txt

[AgenticRail](https://agenticrail.nz/)›[Writing](https://agenticrail.nz/blog/)›Pre-Action Authorization

 Security 2026-05-12 · reviewed 2026-07-22 Kade Cowper

# Pre-Action Authorization for AI Agents: The Missing Security Layer

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. An independent adversarial study found 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 written before the action executes. [Try the demo](https://agenticrail.nz/demo/) [Read the docs](https://agenticrail.nz/docs/)

## What an independent study found

Researchers published ["Before the Tool Call: Deterministic Pre-Action Authorization for Autonomous AI Agents"](https://arxiv.org/abs/2603.20953) (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.

 74.6% **Attack success — permissive policy**Social engineering attacks succeeded in manipulating the agent into executing prohibited actions, model alignment alone.

 0% **Attack success — restrictive OAP policy**Zero successful attacks across 879 attempts under a restrictive pre-action authorization policy. Same model, same attack vectors.

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. This is independent, third-party evidence for AgenticRail's own architectural bet, not a study AgenticRail ran or commissioned — cited here because it's the sharpest evidence available that this class of defence works, and because a vendor's own claims about its own product shouldn't be the only source you check.

## Model alignment, post-hoc evaluation, and pre-action authorization

| 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](https://agenticrail.nz/blog/policy-as-code-ai-agent-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.

## What a pre-action authorization receipt actually contains

Every gate decision produces a receipt, written before the action executes. Real fields, not illustrative placeholders:

loan-proc-3341a · boundaryALLOW

pack_id: "24449424...e020" // SHA-256

decision: "ALLOW"

reasons: []

executed: true // permitted — not proof the write itself succeeded

meta.action_type: "WRITE_RECORD"

payload_hash: "9080bd2a...86cb"

prev_receipt_hash: "b6a18d23...338d"

key_id: "k2_2026-06-07_ed25519"

signature_alg: "Ed25519"

loan-proc-9982b · executionDENY

decision: "DENY"

reasons: ["SEQUENCE_VIOLATION"]

executed: false

meta.action_type: "WRITE_RECORD" // attempted at the wrong step

payload_hash: "a1f0e3c8...552d"

prev_receipt_hash: "24449424...e020"

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.

## How much latency this actually adds

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.

## Pre-action authorization and OWASP's Top 10 for Agentic Applications

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 and Exploitation | 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** | Agent Identity and Privilege Abuse | The sequence contract is the privilege boundary. Steps outside the declared order return DENY · UNKNOWN_STEP; sealed sequences cannot be extended. |

## What this evidences for compliance

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.1.6 operational-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](https://agenticrail.nz/demo/) [Compliance report](https://report.agenticrail.nz/report)

Related [Policy as Code for AI Agent Enforcement](https://agenticrail.nz/blog/policy-as-code-ai-agent-enforcement/)

The full policy contract — step order, action types, and the enforcement gate that makes it operative. [Are AI Agents Deterministic or Probabilistic?](https://agenticrail.nz/blog/deterministic-vs-probabilistic-ai-agents/)

Why an enforcement layer has to be deterministic, and what that means in practice. [AI Agent Audit Log Best Practices](https://agenticrail.nz/blog/ai-agent-audit-log-best-practices/)

Deterministic replay and what an evidence-grade audit trail actually requires. [Automated Decisions and the Provable Safeguard](https://agenticrail.nz/spec/enforceable-safeguards/)

Asserted, enforced, provable — and why the difference decided Robodebt. [← All posts](https://agenticrail.nz/blog/)