What is pre-action authorization?

The short version: sessions and scopes authorize the actor. Pre-action authorization authorizes the action — the exact destination, the exact amount, the exact parameters — before execution.

The shape of the problem

Most authorization systems answer one question: is this caller allowed to do things in this category? A user with a valid session and the right role can transfer funds. An AI agent with a valid OAuth token and the right scope can call the wire-transfer tool. The system says yes.

That answer was good enough when the gap between "decided to act" and "acted" was a human pressing a button. It is not good enough when the actor is an autonomous program that can be steered — by a prompt-injected document, by a compromised data source, by a malformed model response — into actions the human never authorized. The session was real. The scope was real. The action was not.

What pre-action authorization adds

Pre-action authorization asks a sharper question: was this exact action — these arguments, this destination, this amount — approved by a named human, and is the approval still valid?

That requires four things the older systems don't typically produce together:

• Action binding. The authorization names the exact parameters of the action. A captured authorization for "wire $1,000 to Acme" cannot authorize "wire $50,000 to Acme" or "wire $1,000 to a different account."
• Authority chain. The authorization records who held the authority, where it came from, and which policy it was issued under — pinned at request time so later policy changes don't retroactively legitimize past actions.
• Named signoff. A human principal signs off explicitly. Not "the user is logged in." A signature, by name, over the bound action context.
• Verifiable evidence. What emerges is a self-verifying receipt — checkable offline, by an auditor with no access to the issuing system.

Where it matters

The places where pre-action authorization earns its weight are the places where the cost of an unauthorized action is unrecoverable — not just unwanted:

• Wire transfers, ACH releases, treasury operations.
• Beneficiary changes, vendor bank-account updates, payment-destination rewrites.
• Production deployments, infrastructure changes, IAM permission changes.
• Bulk data exports, cross-tenant reads, anything that touches PII.
• Government benefit disbursements, caseworker overrides, claim approvals.
• Any AI-agent-issued action where prompt injection has a meaningful blast radius.

What it does not replace

Pre-action authorization is a layer, not a replacement. It assumes you already have:

• Authentication (so you know who is asking).
• Session and scope authorization (OAuth 2.1, OIDC, MCP authorization, IAM roles).
• Audit logs (for forensics and detection).

What it adds is the missing question between authorization and execution: not can you do it, but did a named human authorize the specific thing you are about to do?