The Authorization Chain

Why agent authorization is a chain, not a check

The thesis

The Action Layer names where consequential AI actions should be controlled. This paper names the structure inside that layer: the authorization chain.

Most discussions of agent authorization treat it as a check: a decision made at a single point, by a single system, against a single policy, returning permit or deny. That framing is behind most of the architectural failures now appearing in production agent systems.

Authorization is not a check. It is a chain.

It starts with a human principal who holds the authority. It is narrowed through a bounded delegation. It is exercised by a registered subject. It is evaluated at a deterministic boundary. It produces a signed proof tied to one exact action. And it is executed by infrastructure that refuses to act without that proof.

Every link in that chain answers a different question. Skip a link and the system cannot tell you who decided, what authority they held, what was actually permitted, or what was actually done. Industry has spent the last two years building agents as if they were the principal. They sit near the bottom of the chain. Treating them as principals is the architectural inversion that makes the later failure modes predictable.

The authorization chain is the structure inside the action layer.

Where we are in May 2026

The agent industry has converged on a particular shape of mistake. Models are given identities. Identities are given tools. Tools are given credentials. The agent becomes, in effect, a principal: a thing that holds authority, decides what to do with it, and acts.

This is the wrong shape. It is the shape that produces over-spending agents, prompt-injected agents, agents that act on stale or fabricated data, agents whose refusals cannot be proven, and agents whose actions cannot be traced back to the human who authorized them.

The identity primitives that emerged across the major cloud, security, and enterprise platforms in 2025–2026 solved a real problem: who the agent is. They did not solve what the agent is allowed to do, under whose authority, with what proof. An identifier is not authority. A claim that "this is agent X" is not the same as "this human authorized agent X to perform this action against this account for this amount until this expiry under this policy." The first is identity. The second is the chain.

The orchestration frameworks compose tool calls. They do not bind those calls to delegated authority. The transport protocols move requests between agents and tools. They do not specify the authority under which the request is being made.

The chain is missing not because anyone thinks it is unnecessary, but because every layer assumes some other layer is providing it. None of them are.

A concrete example

Return to the agent from the previous paper — the small-business agent asked to book a flight under $200.

In the current stack, the agent reads the chat message, infers the budget, calls a flight booking tool, receives a confirmation, and reports success. Authority is implicit in every step. The user said "$200" but did not commit to anything. The agent inferred a constraint but cannot prove it inferred faithfully. The tool received an instruction but cannot tell whether the instruction reflects what the user actually authorized. The booking happens. Money moves. No part of the chain is verifiable.

In a system built on the authorization chain, the user is the principal — the holder of the authority being exercised. The principal issues a bounded delegation to the agent: this operation, this provider, this account, this ceiling, this expiry, under this policy. The agent, a registered subject of the system, proposes an action describing exactly what it intends to do. The proposed action reaches a deterministic boundary that evaluates it against the delegation, the policy, and the ledger of consumed authority. The boundary emits a signed receipt bound to that exact action. Only then does an executor — holding the actual provider credentials in infrastructure the principal controls — verify the receipt and perform the booking.

What survives the transaction is an evidence chain — delegation, authorization, execution — each independently attributable, all linked, and all verifiable after the systems that produced them are no longer in the room.

The agent never holds the credential. The boundary never holds the credential. The credential lives where it belongs: with the principal's infrastructure. The receipt is the executable evidence of authority. Without the receipt, nothing happens.

The agent did not authorize itself. It could not have. The path to authorization does not run through it.

Why agent authorization must be a chain

The argument for the chain is not theoretical. It is what every system that crosses from suggestion into execution has converged on.

Financial systems work this way. The customer is the principal. The bank's account agreement is the delegation. The trader is the subject. The clearing house is the boundary. The settlement record is the proof. The receiving bank is the executor. No link is collapsible. The trader cannot be the clearing house. The bank cannot certify its own settlement.

Operating systems work this way. The user is the principal. Their permissions are the delegation. The application is the subject. The kernel's syscall interface is the boundary. The syscall return is the proof. The hardware is the executor. The application cannot grant itself privileges, and the privileges it does receive are not the user's privileges — they are a narrower bounded delegation issued by the user's session.

Web traffic works this way. Certificate authorities issue bounded delegations of identity. The browser does not trust the server's word about who it is; it verifies a chain against authorities the server does not control. Payment networks work this way. The cardholder is the principal, the card is the bounded delegation, the merchant is the subject, the network is the boundary, the authorization code is the proof, the settlement processor is the executor — and the receipt of settlement outlives the transaction, which is why disputes are resolvable years later.

The pattern recurs in every domain where consequences accumulate. The principal and the subject are different things. The boundary and the executor are different things. The proof outlives the action. Each link is separately attributable, and the chain as a whole is what makes the system trustworthy.

AI agent systems are now entering this class of systems, but much of the current stack was built before that discipline became unavoidable. That is the gap. The authorization chain is what closes it.

The chain links

The chain matters because each link answers a structurally different question.

The principal is the human or organizational authority on whose behalf the system acts. Not an account, not an API key, not a session token — the holder of the authority being exercised. Every other link derives from this one.

The delegation is a bounded grant of authority from the principal to a specific subject. It specifies what is permitted: which operations, against which providers, on which accounts, within which limits, until when. The subject cannot widen it. The system cannot widen it. The delegation is the ceiling.

The subject is the agent — a registered software entity bound to the principal that delegated to it, identifiable by an enforceable identifier rather than a self-asserted name. Its role is to propose actions within the delegation. It has no authority of its own.

The boundary is the deterministic enforcement layer that evaluates proposed actions against the delegation, the policy, and the system's ledger of consumed authority. Identical conditions produce identical decisions. The model that proposed the action has no path to influence them.

The proof is a signed receipt bound to the exact action authorized — not the operation in the abstract, not the class of operation, the specific action with its specific parameters. If the action changes after the receipt is issued, the receipt no longer matches it and execution does not occur.

The signed execution is performed by infrastructure that holds the actual provider credentials — typically in the principal's own secret management — and that refuses to act without first verifying the proof. After the provider call returns, the executor emits a signed attestation, and the boundary issues a final wrapping receipt that binds the authorization, the attestation, and the outcome into one verifiable artifact. The chain closes with that signature.

The point is not the number of links. The point is that these questions remain separable, attributable, and independently verifiable over time.

How this differs from what each layer already provides

A fair question: do existing systems not provide some of this? They provide necessary pieces. They do not, by themselves, produce the authorization chain.

The hyperscaler identity primitives say who the agent is. They do not say what authority the agent holds for this specific action. The orchestration frameworks compose tool calls. They do not bind those calls to delegated authority. The transport protocols specify how requests move between agents and systems. They do not specify the authority under which the request is being made.

These layers are not wrong. They are necessary. They are not sufficient. An identifier without a bounded delegation is a name without authority. A composed tool call without an authorization receipt is an instruction without proof. A protocol-level authentication without a deterministic boundary is a handshake without a decision.

The authorization chain exists because these concerns converge operationally but remain structurally distinct.

Authorization shapes

The chain is universal. What varies between domains is the cadence of the interaction it authorizes.

• Single message send. One action, one receipt, one execution. The delegation, the proposal, and the proof collapse into a single round trip.
• Commerce booking. A quote, a hold, an approval, and a commit — four authorizations against a tightening delegation, each receipt narrowing the authority of the next.
• Coding session. One delegation opens a window. Many bounded actions occur within it. An approval gates the proposed changes. An evidence chain is produced as work lands, and the window closes on its own terms.
• Regulated approval. A licensed human's signature stands as an irreducible separate link. No other link can substitute for it, and no automation can produce it.

Different operational shapes; the same underlying structure. Mature systems do not invent authorization from scratch for every action. They reuse patterns that preserve bounded authority, deterministic evaluation, attributable execution, and survivable evidence across domains.

Why this matters now

Three drivers, all from the prior paper, all sharper a month later.

Regulation specifies the chain even when it does not name it. Article 12 of the EU AI Act requires automatic recording of events for high-risk AI systems, with tamper-evident retained logs, enforced from August 2, 2026. "Tamper-evident" is not a documentation property; it is a cryptographic one. A logging system that records what the agent said it did is not tamper-evident. Systems that can bind authorization, execution, and evidence into a tamper-evident record are closer to what the regulatory language implies. Regulation does not create this requirement. It reveals the structure that already had to exist.

Agent commerce is being launched against the wrong shape. The agent-commerce protocols shipped between January and April 2026 — Stripe ACP, Visa Intelligent Commerce Connect, Mastercard Verifiable Intent, Google's Agent Payments Protocol — each address a fragment. Visa addresses transport. Mastercard addresses post-execution audit. Google addresses authorization mandates. Each addresses part of the surface. None should be mistaken for the entire authorization structure. Settlement networks tend to converge toward this structure over time; the early architectural choices are being locked in now.

The failure modes are already visible. An agent acts on stale pricing, sends data to an address it generated mid-session, or exceeds a budget because no system can prove the cap that was actually delegated. The pattern is consistent: an agent acted; the action was wrong; nobody could prove what was authorized or what was refused. The chain is the answer to the question every post-mortem ends on.

As autonomous systems move deeper into regulated and financial domains, the authorization chain becomes difficult to avoid. The systems that lack one will be the case studies the others cite.

What the chain is not

A few clarifications, because these comparisons are easy to overstate.

It is not a centralized identity provider. The chain consumes identity tokens from upstream providers as inputs to the principal-identity link. It does not replace them. Identity tells you who is calling. The chain tells you what authority they hold.

It is not a workflow tool. Orchestration frameworks continue to compose tool calls. The chain sits beneath them. What changes is what happens after the agent decides what to do.

It is not a credential vault. Credentials live with the principal — in their secret manager, their key vault, their key management infrastructure. The executor fetches them at execute time and releases them after. The chain's job is to issue the authorization the executor requires before fetching anything.

It is not a content moderator. Whether the natural-language input is harmful is a question for the model and orchestration layers. The chain evaluates proposed actions against deterministic policy. It does not interpret prose.

It is not a single product. It is a contract with observable, testable properties. Multiple implementations of the chain can coexist, just as multiple implementations of any layered protocol coexist. What matters is that the links are present, that no actor can silently collapse them, and that the resulting composition is verifiable.

What this paper does not argue

This paper does not argue that any specific implementation is the right one. It argues that the chain is the architecture, that each link is necessary, that the composition is what makes systems trustworthy, and that agent systems will continue to expose predictable gaps wherever this chain is absent.

Subsequent papers will go deeper on specific properties of the action layer:

• The Authorization Boundary
• The Receipts Primitive
• The Protocol Shape
• The Payments Surface

Each will stand alone and assume only the framing established here and in The Action Layer.

A closing observation

The importance of this architecture is not in any single link. Every individual primitive is decades old — bounded delegation comes from operating-systems research in the 1970s; signed receipts come from financial clearing; deterministic enforcement comes from kernel security; hash chains come from cryptographic research in the 1970s. Each, alone, is unremarkable.

The significance is in the composition. A principal who issues a bounded delegation. A registered subject who can only act within that delegation. A deterministic boundary the model cannot reach. A proof bound to one exact action. A signed execution that refuses to act without that proof and closes the chain with its own attestation.

Systems of consequence eventually converge on attributable authority, bounded delegation, deterministic enforcement, and survivable evidence. AI systems are now entering the same convergence. The authorization chain is not a feature of autonomous systems. It is the structure that allows them to become infrastructure.

A system without this chain is not insecure. It is incomplete.

Once actions have consequences, "we cannot tell you exactly who authorized this, what was permitted, and what actually happened" is not an acceptable answer.