What an authorization chain actually is.
Authorization is one of the oldest problems in computing, and we keep solving it for the era we're in. Filesystems, capability tokens, OAuth, IAM — each model worked, each model broke, each was replaced by something that wasn't a replacement so much as a layer. Agent systems need one more layer. This post is about what shape it has to be, and why the prior shapes don't fit.
1971: the filesystem permission
The original model is Unix permissions. A file has an owner, a group, and a mode (read, write, execute) for owner / group / world. Authorization is a small bitfield, evaluated when the syscall reaches the kernel. The model works because the universe is small: a process has a real and effective UID, a file has an owner UID, comparison is trivial.
The model breaks the moment you have structured resources. A web app's "users" table is one file from the kernel's view, but inside it are millions of individual records, each with different ownership semantics. The kernel doesn't care; the application does. Application code starts re-implementing authorization from scratch, badly, in every project.
1985: capabilities
Capability systems (KeyKOS, EROS, later seL4) tried to fix this by making authorization a token, not a property of the principal. If you possess the capability, you can do the thing. Capabilities can be delegated by passing them around, revoked by the issuer, attenuated to be weaker than the source.
Capabilities are beautiful in theory and hard to operate in practice. The problem is bookkeeping: when a system is composed of dozens of services and millions of capability tokens, knowing which token grants which authority and where each is held becomes its own engineering burden. Capability systems are still cited as inspiration; they are not the deployed reality at any large company.
What capabilities did teach the field is that authorization is a relationship, not a label. A user is not "authorized" in the abstract. A user holds a token that authorizes them to do a specific thing to a specific resource until a specific event.
1995: ACLs and RBAC
Access control lists and role-based access control became the default for the next two decades. Each resource carries a list of (principal, permission) pairs, or each principal has a role with a bundle of permissions. The administrator's job is to maintain the mapping.
This is the model most enterprise systems still run on. It works because, in steady state, principals and resources change slowly. It breaks when the environment is dynamic: a contractor onboarded for a quarter, a temporary access grant during an incident, a permission needed only for a specific task. RBAC accumulates roles like a sediment; nobody removes them. By year five, every senior engineer has accidentally been granted production database write access through a role that nobody remembers attaching.
2010: OAuth and the consent model
OAuth was the first widely deployed authorization model designed around delegation. A user could grant a third-party application a scoped slice of their access. The grant was time-bounded, revocable, and visible to the user. Crucially, the third party never held the user's password — it held a token that referenced an authorization decision the user had already made.
Two things OAuth got profoundly right: separation of authentication (who are you) from authorization (what may you do), and the explicit token lifecycle (issue, refresh, revoke). The pattern of "I authorize this third party to do this on my behalf, until this" became the substrate for the consumer cloud.
What OAuth didn't address: depth. The user authorizes the application; the application then does whatever it does. There is no recursion. If the application internally has agents, contractors, scripts — none of that propagates back to the user's grant. The grant was at the boundary of the user's company; what happened after the boundary was opaque.
2014: AWS IAM and the policy language
Amazon's IAM, refined over a decade, is the most widely deployed example of policy as a first-class artifact. Authorization decisions are not a property of a role; they are the result of evaluating a policy document at request time. Policies can attach to a principal, to a resource, or to both. Decisions consider the request context (source IP, MFA status, time of day) along with the principal and the action.
IAM also introduced assume-role, which is the closest predecessor to what agent authorization needs. A principal in account A can temporarily take on a role in account B, with a clear trail of who delegated to whom. An action taken by the assumed role can be traced back to the original principal through CloudTrail.
Two limitations show up. First, the depth is bounded — IAM supports a few hops of role chaining, not arbitrary delegation depth. Second, the lifecycle is human-time. A role assumption lasts an hour by default. Agent systems have action lifetimes measured in seconds, with delegation chains that can be three or four levels deep within a single multi-agent task.
2024: the agent boundary
Now consider an autonomous agent that runs a procurement task. It is operated by a swarm controller, which is operated by a department head, who is delegated authority by the company's CFO, who is delegated authority by the board. The agent attempts to charge a virtual card. Who authorized this?
None of the prior models give you an answer that holds up to a regulator's question. The kernel sees a process making a syscall. OAuth sees the application talking to the API. IAM sees an assumed role. None of them carry the full chain from the human principal to the present action through every intermediate delegation.
The reason this matters more for agents than for humans is autonomy. A human delegating authority to a contractor knows roughly what they will do — there's a job description, a project scope, a working day. An autonomous agent is a delegation primitive that, at any moment, may decide to delegate further to another agent for a sub-task. The delegation graph is dynamic, dense, and unbounded.
What the chain actually has to be
Three properties are necessary, and they are mostly not present in any deployed system today.
Recursive. Every action carries the full chain of delegations back to a human, not just the immediate parent. If the chain has six links, the audit row records six links. This isn't a perf concern — chains in practice are short, and the cost of writing the chain is dwarfed by the cost of the action being authorized.
Attenuating. Each link in the chain may grant less authority than it received, never more. A swarm controller delegating to a worker agent should be able to scope down — same kinds of action, smaller budget, narrower merchant categories. Capability systems had this; modern IAM mostly doesn't.
Revocable through the chain. Revoking any link in the chain invalidates all descendants on the next decision check. The CFO leaves the company; every agent under their delegation tree stops authorizing on the next request. There is no "reissue all the tokens" deployment.
If a system has all three, it has an authorization chain. If it has one or two, it has a more sophisticated RBAC.
What the chain is not
It is not a blockchain. The properties an authorization chain needs are append-only ordering and tamper-evidence within a single domain. Both are achievable with hash-chained logs and a trusted operator. Distributing trust across a public ledger adds latency and operational complexity without solving a problem the model has.
It is not an LLM observability tool. Tracing tools record what the model said and what tools it called. They do not record who delegated authority for that call to happen, and they do not deny calls outside scope. They are complements, not substitutes.
It is not a replacement for IAM. Your databases and clouds still need IAM. The chain governs actions taken with those credentials, not the credentials themselves.
The argument for putting it under the agent, not in it
You could imagine asking each agent framework to maintain its own authorization chain. Some try. The problem is that authorization works only if the agent cannot bypass it. The moment the chain check is in the same process as the agent's tool-calling loop, a sufficiently capable agent (or its prompt-injected adversary) can simply skip the check.
The right place is one layer below: between the agent and the world. The card network calls the chain check before letting the swipe go through. The contract-signing service calls it before letting the signature land. The egress proxy calls it before letting the API request out. The agent doesn't have a choice about being checked, because the action doesn't happen until the check returns.
This is the same pattern as TLS termination, ingress controllers, or service meshes — pull a cross-cutting concern out of the application and put it in a layer the application doesn't get to skip. It works for the same reason.
What this means for what you build
If you are building an agent product and you have not yet been asked the audit question — you will be, soon. When you are, the answer is some form of an authorization chain. You can build it yourself and maintain it forever, or you can build on a chain primitive and spend your time on the product.
Either way, the components you need are the same: an identity hierarchy, a policy language, a budget ledger, an append-only audit log. Everything else is integration.