Who authorized the next action?

A traditional application lives inside a fairly stable boundary. It has a service account, permissions set by an administrator, and code that decides most of what it does. When it calls a database, the authorization decision involves a known caller, a known resource and a known operation.

An agent complicates every part of that. It may act for a person, an organization, another agent, or several at once. It may find a tool its developer never knew about, hand part of a job to another agent, spin up temporary helpers, remember things across sessions, and run for hours with nobody watching each step. The question is no longer just whether a request is authenticated. It is whether this action is allowed, here, now.

Identity is not authority

Every agent needs a stable identity, so the system can say who or what is acting. That identity anchors its permissions, audit trail, lifecycle and accountability. The major cloud platforms have started treating agents as security principals in their own right, which is a sign this idea is moving from architecture diagrams into production.

But identity only tells you who is acting. It doesn't tell you on whose behalf.

Delegation is the missing dimension

Ordinary authorization asks whether A may do X to Y. Agents add a question: under whose authority is A acting?

Suppose you ask a travel agent to arrange a business trip. It finds a booking agent and delegates the hotel. The booking agent calls a payment service. There is now a chain: you, then the travel agent, then the booking agent, then the payment service. If the payment service sees only the last caller, it has lost the reason the payment was allowed.

So the book proposes delegation provenance: every consequential action should be traceable back through its chain of authority. Not only who did it, but who authorized it, what scope was handed down, which policies applied, and whether that authority was still valid at that moment.

Authority versus execution

The deepest distinction in the chapter is between authority and execution. The runtime decides how an agent does its work. The control plane decides whether that work is permitted, under whose authority, within which limits, and with what accountability.

Keeping them apart lets everything else change. Models can improve without redesigning identity. Runtimes can move from containers to sandboxes without rewriting policy. New agents and tools can join without each one inventing its own rules. The control plane is the stable layer around an adaptive and unstable execution environment.

For anyone running an organization, the lesson is that governance can't be a document read after deployment. It has to be operating infrastructure: known identities, bounded authority, traceable delegation, enforceable policy, auditable decisions, and an off switch that works independently of the agents it governs.

This essay is drawn from Chapter 16 of The Agentic Mind, "The Agent Control Plane".