Why Agent Authorization Needs a Preflight Plan, Not Just Permission Checks

A permission check answers a useful but narrow question: may this actor invoke this capability? Agent systems need a second answer before they create, send, pay, delete, deploy, or disclose: is this exact action still authorized under the current evidence, target state, approval scope, and risk boundary? Treating both questions as one boolean hides the difference between having access to a tool and having authority for a particular side effect.

The sharper model is plan-first authorization. The system resolves intent, policy, live state, evidence, approval requirements, execution limits, and recovery into one inspectable preflight plan. The agent may execute only that frozen plan. A changed recipient, payload, price, environment, policy version, or evidence set invalidates the plan instead of inheriting authority from an earlier check.

Role-based and capability checks are good at controlling broad access: an operator may review invoices, a deployment agent may call a release tool, or a support workflow may draft a reply. They are weaker at expressing action-local constraints. The invoice amount may exceed a threshold, the deployment target may have changed, the reply may now contain private data, or the evidence that justified the action may be stale.

Long-running agent loops widen this gap because interpretation and execution happen at different times. An agent can form a valid intention, wait for approval, retry after a tool failure, and act against a different world. Without a plan that binds the approved action to a state snapshot or freshness rule, the system quietly converts old authority into new side effects.

Authority Router provides a public portfolio example of this boundary: it is a vendor-neutral architecture project that converts human and AI workflows into deterministic, auditable authority plans with explicit permissions, accountable owners, approval states, evidence requirements, escalation paths, and execution limits. Public project context: portfolio projects.

The transferable lesson is not that every product needs a separate policy engine. A small workflow may implement the same contract inside its existing application service. What matters is preserving the separation between proposing an action, proving its authority, executing the approved plan, and recording evidence of what actually happened.

Represent the preflight result with a compact contract such as {plan_id, actor_id, capability, intent_ref, target_ref, target_version, payload_digest, evidence_refs, policy_version, decision, required_approvals, approval_scope, expires_at, idempotency_key, execution_limits, recovery_mode}. Keep secrets and full sensitive payloads outside the plan; store stable references and a digest so the executor can prove it received the authorized input without turning the audit record into another disclosure surface.

Use an explicit lifecycle: proposed -> evaluated -> needs_approval | denied | ready -> executing -> succeeded | failed | uncertain -> verified | compensated. Three invariants make the boundary meaningful: only a ready unexpired plan may execute; the executor recomputes target and payload bindings before the side effect; and every retry reuses the idempotency key or returns to evaluation when the action cannot be safely repeated.

Approval drift is the first failure mode: a human approves a summary, but the recipient, payload, amount, or target changes before execution. Stale-state execution is the second: the plan remains structurally valid after the resource, policy, or business context has moved. Retry ambiguity is the third: a timeout leaves the system unsure whether the side effect happened, so a second attempt duplicates it. A fourth failure is audit overcollection, where the authorization trail stores more private content than the decision required.

Plan-first authorization adds latency, schema work, and operational states. Not every read-only tool call deserves the same ceremony. Apply it proportionately: lightweight checks for reversible reads, freshness and idempotency for routine writes, explicit approval and compensation for high-impact actions. The cost is justified when an incorrect side effect would create financial, privacy, safety, compliance, or recovery work that a boolean check cannot contain.

Take one agent action that changes durable state and ask ten questions. Which actor and capability are involved? What exact target and payload were authorized? Which evidence and policy version justified the decision? Who owns approval? When does authority expire? What change forces reevaluation? How is a retry deduplicated? How is success verified? What happens when the outcome is uncertain? How can the action be reversed or compensated? If the audit trail cannot answer these questions from one plan identifier, authorization is distributed across assumptions the system cannot reliably enforce.

Test a payload change after approval, a target version change, expired evidence, revoked actor access, two simultaneous executions, a timeout after the external service accepted the request, a partial side effect, an unavailable approver, a policy update during a queued job, and a recovery attempt with broader permissions than the original plan. Useful measures include stale-plan rejection rate, approval-to-execution delay, duplicate-side-effect rate, uncertain-outcome duration, compensation success, and the share of executions whose evidence can be reconstructed without exposing unnecessary sensitive data.

Once authority is represented as a plan, security and product teams can discuss the same object. Product defines the intended action and recovery promise. Security defines evidence, policy, expiry, and approval constraints. Engineering defines binding, idempotency, execution, and verification. Operators can see why an action paused or failed without granting the agent wider permissions to make the workflow appear smoother.

Apply this tomorrow by choosing the highest-impact tool your agent can call and writing a one-page preflight contract for it. Bind one concrete target and payload, name the evidence and policy version, set an expiry rule, choose an idempotency strategy, and define the uncertain-outcome path. Then change the target after approval. If the executor still proceeds, the system has permission checks but not an authorization plan.