Authority is not authorization

The position

Authority, authorization, and execution are distinct functions, even where one person performs all three. In AI deployments, these functions may be distributed among institutions, policy authors, authorization services, and autonomous agents. Authority may reside with an accountable principal, policy may be established under delegated authority, and an action-specific determination may be rendered by a runtime authorization boundary. The separation matters because an actor's standing to make decisions does not itself establish that a particular proposed action was authorized.

The consequences are architectural, not semantic. Delegation transfers the exercise of authority within a scope; it does not convert any impermissible action into a permissible one, and it does not authorize any action in particular. An agent operating under the broadest delegation has not, by that fact, had any specific action authorized. Policy states the terms on which authority is to be exercised; it speaks in classes and determines nothing about any actual proposal until it is applied. Authorization is that application: one specific proposed action, evaluated against applicable policy, before execution. Enforcement is what makes the determination govern rather than advise.

Delegation is not authorization. Delegation allocates decision-making authority within a defined scope, including, where specified, the authority to render action-specific determinations. It does not itself determine that any particular proposed action may proceed. An agent holding scoped credentials or delegated authority has standing to exercise the rights granted, but that standing does not establish that a specific effect-bearing action received the required pre-execution authorization. Delegation determines who may exercise authority. Authorization determines whether the proposed action may proceed.

Eligibility is not authorization. A standing eligibility determination, such as conformity assessment or certification of a management system, takes a certified referent as its object, produces a status as its output, and has standing temporal effect. Runtime authorization takes a specific proposed action as its object and makes execution unavailable without an affirmative pre-execution result. Certification may establish conformity or satisfy a condition of standing eligibility; neither establishes the required action-specific runtime authorization by itself. Runtime authorization determines whether a specific proposed act may cross the execution boundary. Enforcement of standing eligibility does not, without an additional runtime dependency, produce an independently reconstructable pre-execution verdict over a specific proposed act.

Standing certification and approval are not runtime authorization verdicts. A certificate or regulatory approval may establish conformity, eligibility, or permission to operate within a defined scope. Its referent, conditions, and duration depend on the instrument. Such standing determinations do not, merely by existing, establish that a specific proposed action received the required pre-execution authorization. A mechanism does not constitute authorization merely because it produces a judgment, credential, signal, deterrent consequence, or retrospective record. The governance question remains whether the particular action was authorized under the applicable policy and authority before release.

A governance review that respects the distinction asks five separate questions: who holds legitimate power over this domain, what has been delegated and within what scope, which policy applies, whether this specific action was determined permissible before execution, and whether it could have executed without that determination. A credential may evidence a delegated scope or capability grant. It does not, by itself, establish the source of authority, identify the applicable policy, determine that a specific proposed action was permissible, or ensure that execution depended on that determination. The final two questions are where authorization becomes operational governance.

Counter-positions

“Actors are authorized all the time.” Correct, and the usage is legitimate. Actor-level authorization denotes a standing permission, credential, or delegated scope: authorized users, authorized officers, authorized agents. The doctrine does not treat that usage as invalid. It holds that the two usages are not architecturally equivalent: an actor-level grant identifies who may act within a scope, and does not establish that any particular proposed action was determined permissible under the policy in force at the moment of execution. Phrases such as “the agent is authorized” are incomplete for action-governance purposes, not wrong.

“Authorization is a solved problem in access control.” Access-control systems already provide sophisticated authorization mechanisms, including contextual, per-request decisions over subjects, resources, operations, and conditions. Such mechanisms may participate in, or constitute components of, an action-specific runtime authorization boundary. The question is what the decision binds and whether the required verdict governs release. A credential permitting an agent to call a payments API does not, by itself, establish that a particular payment satisfies the applicable policy and authority. An access-control arrangement that makes the specific proposed action subject to the required determination and enforcement conditions should be evaluated on those properties. The distinction is one of authorization scope and evidence, not a rejection of access-control technology.