Authority versus Authorization

Authority belongs to actors. Authorization belongs to proposed actions.

The word authority is doing too much work in AI governance.

It appears in vendor architectures as an authority layer. It appears in enterprise policy as authority delegated to software agents. It appears in procurement reviews as authorized use, in workflow tools as authorized transactions, and in accountability frameworks as the authority an executive holds for a system's conduct. Each usage is locally intelligible. Collectively, they do not refer to the same thing.

One usage denotes an organizational fact. One names a credential. One names a sign-off event. One names an entire governance apparatus. These have different properties, different failure modes, and different architectural requirements. A credential is not a decision. A decision is not a control. An org chart is neither. When one word covers all of them, any layer of a governance architecture can be offered as the whole, and the offering is not even dishonest. The vocabulary licenses it.

Why the collapse was rational

This conflation is not carelessness. It is the residue of a long period in which the distinction did not need to be drawn.

For most of institutional history, humans possessed authority, humans performed authorization, and humans executed actions. A loan officer held delegated authority within a lending policy, determined that a particular loan was permissible, and signed the documents. One person, one motion. To say the officer had authority and to say the loan was authorized described the same event from two angles. No vocabulary was needed to separate them because nothing in the world separated them.

Computerization did not force the separation, and it is worth being precise about why. Access control systems automated exactly one question: whether a given identity may invoke a given capability. The action-level question, whether this specific use of the capability is permissible here and now, stayed with humans. The system checked that Alice could open the ledger. Whether the entry Alice was about to make was proper remained Alice's judgment, made under her authority, at the moment of action. Software took over the gate to the room. People remained the judges of what could be done inside it.

AI systems dissolve this arrangement, not by automating one role but by distributing all of them. Authority may rest with a board. Policy may be authored by compliance. The action-level determination may be rendered by software, because machine-initiated actions move beyond human tempo. Execution belongs to agents that are none of the above. The single actor in whom the concepts could remain fused no longer exists at the point of action. Once the roles separate, the vocabulary must separate with them.

Five concepts, five questions

Authority is the legitimate power of an actor to make, delegate, or override decisions within a defined domain. It belongs to actors: boards, officers, committees, regulators. It exists independently of any specific action. No inventory of an organization's authority, however complete, answers whether a given action is permitted. The inventory identifies whose answer would count. The question authority answers: who may decide?

Delegation is the assignment or transfer of that power. It changes who may exercise authority. It does not, and cannot, change whether any particular proposed action is permissible. Granting an agent scoped credentials and a mandate is delegation. It establishes that the agent acts within someone's authority. It says nothing about whether any specific action the agent proposes is permitted, for the same reason that hiring a purchasing manager does not approve any purchase. The question: who may exercise that authority?

Policy is the set of constraints governing the exercise of authority. Policy is general where authorization is particular. It speaks in classes: transactions of this type, below this amount, in these jurisdictions. No policy, however detailed, refers to the specific action an agent proposes at 14:32 against a given counterparty. A policy that has been written, approved, and published has determined nothing about any actual action. It waits. The question: under what conditions?

Authorization is the determination that a specific proposed action is permitted under applicable policy, rendered before execution. Both properties are constitutive. A determination that applies no policy determines nothing, and a determination rendered after execution is review, not authorization, whatever the workflow calls it. The question: may this specific proposed action proceed?

Enforcement is the mechanism that ensures execution cannot proceed without a valid authorization determination. Without it, authority is organizational, policy is documentary, and authorization is advisory: true statements with no bearing on what occurs. Enforcement is the layer at which governance stops being a description and becomes a constraint. The question: could the action proceed without the determination?

Two kinds of authorization

The predictable objection is that authorization is a forty-year-old solved problem. It is worth answering directly, because the vocabulary is inherited but the problem is not.

Capability authorization is the classical object of access control: whether a subject may exercise a specified operation over a resource. It is necessary, mature, and can be contextual and per-request. Effect-bearing action authorization is a broader determination: whether the proposed action, considered in its content, context, and intended effect, may proceed under the policy in force at this moment.

The gap between the two is where governance failures live. The service is entitled to call the payments API; the specific payment violates a sanctions policy that took effect this morning. The agent's grant covers file deletion in its workspace; the specific deletion destroys the only copy of a record under legal hold. In each case capability authorization returns the correct answer to its own question while the effect-bearing question goes unasked. For four decades a human stood at the point of action and answered it. Autonomous systems remove the human, and with them the only mechanism that was answering. The two forms of authorization are complements, not competitors, and neither substitutes for the other.

The test in practice

Consider an autonomous procurement agent holding credentials to submit purchase orders up to $50,000, operating under a policy that prohibits transactions with restricted counterparties. Five questions review the architecture. Who has legitimate power over procurement decisions? What authority has been assigned to the agent, and within what scope? Which rules govern the proposed purchase? Was this specific purchase evaluated against those rules before submission? Could the purchase order be transmitted if no valid authorization determination existed?

In practice, a review answers the first two questions through the agent's identity, credentials, and delegated scope. Nothing in that inventory answers the last two. Most agent deployments today are described entirely in that language, which is how a credential architecture comes to stand in for a governance architecture in reviews that never notice the substitution.

The observation

The framework reduces to a single observation:

Authority determines who may authorize. Authorization determines whether a specific proposed action is permitted. Enforcement determines whether that authorization governs execution.

Treating these concepts as interchangeable obscures the architectural requirements for governing autonomous systems. Treating them as distinct makes those requirements statable as questions any architecture either answers or does not: by whom, under what, determined when, and enforced how.

Where FERZ stands

FERZ works at the fifth question. Our position is that AI governance is an enforcement problem: a non-bypassable runtime authorization boundary, evaluated before execution, failing closed when no valid determination exists. The framework above is deliberately vendor-neutral, and the paper that develops it proposes no implementation and no product architecture. Whether a governance architecture answers those five questions is independent of who built it. The questions remain.

Read the paper

The full paper develops the framework in depth: formal definitions of the five concepts, the historical account of the collapse, the distinction from classical access control, a worked architecture review, and a canonical summary table.

Authority versus Authorization: A Definitional Framework for AI Governance. Version 1.0, FERZ, Inc., July 2026.

Read it at: https://doi.org/10.5281/zenodo.21341907