Authority is not authorization

The two concepts were historically collapsed because one human actor held authority, performed authorization, and executed the action. The distinctions could remain implicit as long as a person stood at the point of action. AI systems distribute those roles: authority may rest with a board, policy may be authored by compliance, the action-level determination rendered by software, and execution performed by autonomous agents. Once the roles separate, the vocabulary must separate with them.

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.

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.

“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.” The vocabulary is inherited; the problem is not. Capability authorization, the classical object of access control, decides whether a subject may exercise a specified operation over a resource, and it can be contextual, per-request, and centrally administered. Effect-bearing action authorization decides whether a specific proposed action, considered in its content, context, and intended effect, may proceed under current policy. The distinction is one of decision scope and governed object, not timing or contextuality. The service entitled to call the payments API can still propose a payment that violates a sanctions policy in force since morning. The two forms of authorization are complements, not competitors, and neither substitutes for the other.