Pre-action authorization
I coined the term for the check that happens before an agent's tool call is issued, not after. Here is what it means, what I measured, and where the idea came from.
Pre-action authorization is deciding whether an autonomous agent may take an action before the tool call is issued.
That is the whole definition. The interesting part is the word "before". Most agent safety work happens either earlier, in the model, or later, in the transcript. Pre-action authorization sits in the gap: after the model has chosen what to do and before anything happens in the world.
I named it in Before the Tool Call, published on arXiv in March 2026. The idea is older than the paper, and the paper is not where it went right the first time. Both of those are on this page.
Why the check has to be before
An agent picks its next action from a probability distribution. A wire transfer
is not a probabilistic act. Neither is DROP TABLE, or a shell command, or an
email to a customer list.
Two familiar places to put a control, and what each one misses:
In the model. System prompts, refusal training, and instructions like "never transfer more than $500 without asking." An injected prompt is text arriving through the same channel as the instruction, so it competes on equal terms. In my own testbed, attackers talked the model past its instructions over 70 percent of the time.
In the log. Audit trails, transcript review, anomaly detection after the fact. These are worth having, and they tell you about a transfer that already cleared.
Pre-action authorization puts a deterministic check between the decision and the call. Same inputs, same answer, no sampling. It terminates in allow, deny, or escalate to a human, and it cannot be argued with, because it is not reading the argument.
What I measured
I ran a public adversarial testbed, the APort Vault CTF, with a $5,000 bounty, and published the numbers rather than a summary of them.
| Permissive tier | Restrictive tier | |
|---|---|---|
| Attacker success | over 70% | 0% |
| Attempts | 800+ | |
| Bounty claimed | none |
Across the full run: 3,900+ authorization decisions over 1,100+ sessions, over half of them denied. Median decision latency 53ms, p95 63ms, p99 76ms over 1,000 requests.
The result that matters is the dull one. Players social-engineered the model successfully on the restrictive tier too. The infrastructure refused the transfer anyway. That says the fix is architectural, which means a team can adopt it now instead of waiting for a model that cannot be talked into things.
Where the term came from
The first public version of this argument is a post from August 2025, seven months before the paper. It is about passports for agents and it does not use the phrase "pre-action authorization" anywhere. The mechanism was right and the vocabulary took another year.
In between I built a version of it at Chimoney that did not work, and wrote up what was wrong with it. The short version: I checked identity and forgot to check capability, so a correctly authenticated agent could still do something nobody had authorized.
The specification that came out of that is the Open Agent Passport. The paper formalizes the check; the passport is the credential the check reads.
Adjacent work, and how this differs
- The IETF has a draft on AI agent authorization that covers how an agent obtains delegated credentials. Pre-action authorization starts after the agent has them.
- Microsoft Entra Agent ID gives agents directory identities. Identity answers who; this answers what they may do with it.
- NIST's AI Agent Standards Initiative is the venue where a control category like this would eventually live. The paper proposes it as one, mapped to the AI Risk Management Framework.
Reading, roughly in order
- Before the Tool Call, the paper, arXiv:2603.20953.
- Open Agent Passport, the specification and where it came from.
- I built the wrong AI agent passport system, the version that failed first.
- Guardrail drift and audit trails, on why the log is not enough.