Who Controls Trust? From Identity to Authority

How Trust Gets Established

In this article series, Security Sovereignty means retaining control over identity, authorization, and policy even when providers, infrastructure, or operating conditions change. That control depends on something we touched on in the previous article, Who Controls Trust? How Do You Regain It? but did not yet explore in detail: the authority an organization wants to govern has to be explicit enough for both people and machines to understand.

Identity is often treated as the alpha and omega of access control: establish who or what is acting, and let the rest follow from there. We authenticate a user, application, workload, or AI agent, establish who or what it is, and then allow access decisions to flow from that identity.

That model becomes increasingly incomplete as actions move across systems. A user may initiate a process that continues through several APIs. A workload may act without a person present. An AI agent may be given an objective and then decide which tools, APIs, and other systems it needs to use in order to achieve it.

In those environments, knowing the identity remains essential, but it no longer tells us enough. The more important question becomes: what authority does this actor have for the action being attempted? That may sound like a subtle distinction, but in practice it changes how trust gets established.

It is worth being precise, and perhaps a little nitpicky, about what trust means here, because "how trust gets established" can easily sound like a question of whether we should trust AI agents, and that is not the question I’m asking. In this series, trust is the justified basis on which an organization allows an actor to perform an action: the system has established who or what is acting, on whose behalf, under which mandate, with what authority, and within which boundaries. In that sense, trust is not confidence in an agent's judgment but something the architecture establishes. That is why the question of who controls trust is ultimately a question of who controls the mechanisms that establish it.

Identity tells you who. Authority tells you what they may do.

Identity should be relatively stable. A customer remains the same customer whether they check an order, change an address, or request a refund. An employee remains the same employee whether they read a report or approve a payment. A workload retains its identity even though the task it performs may change from one request to the next.

Authority is different because it exists for a purpose. It may apply only to a particular resource, action, transaction, or period of time. It may be granted directly or delegated by somebody else, and it may need to narrow as a process moves through different systems. 

For an organization, getting this wrong creates risks that go well beyond a single failed task. An agent with excessive authority could expose customer information, modify records it was only supposed to read, or carry out actions that should have required human approval. The organization still has to govern and account for those outcomes, even when an autonomous system carries them out.

That is why I find it useful to separate persistent identity from temporary authority. When the two become too tightly coupled, identity starts accumulating power. A user authenticates, receives a broad role, and that role follows them everywhere. A service account receives permissions because they were required for one integration and keeps them long after anybody remembers why. An AI agent receives the same access as the person who initiated a task because that is the easiest way to make the integration work.

All of those systems may know perfectly well who or what is acting. What they do not necessarily know is whether that actor has the right authority for this particular action, on this particular resource, for the purpose that caused the process to begin. 

That is the gap between identity and authority.

A legitimate objective does not grant unlimited authority to pursue it

A recent incident in Australia, reported by ABC News, made that distinction unusually concrete.

A user asked a personal AI agent to book a gym class, and the agent discovered that the booking system allowed reservations much further into the future than the gym intended. Later, when the user asked whether it could move him up a waitlist, the agent tested what the system would allow and canceled another person's reservation. According to the agent's own response reported by ABC, the booking API did not perform an authorization check preventing one user from canceling another person's reservation.

The user did not instruct the agent to remove somebody else from the class. The agent pursued a legitimate objective, explored the actions available, and chose a path with a consequence the user did not explicitly request.

The lesson is not that every autonomous agent will try to hack the systems it encounters. It is that an agent pursuing a legitimate goal may select actions and paths its user did not anticipate, so the systems it touches need a way to distinguish the objective the agent has been given from the authority it actually possesses. In the gym case, identifying the user or the agent correctly would not have solved the problem, because the missing question was whether the authority behind that request extended to another person's reservation.

In the terms of this series, the problem was not whether the agent could be trusted to make the same choices a human would. It was that the trust boundary did not prevent an action for which the agent lacked sufficient authority.

A mandate such as "move me up the waitlist" sounds entirely harmless, and that is precisely the point. It describes an objective, not permission to take any action the system happens to accept to achieve it, which is why identity alone is not enough.

Making the mandate machine-readable

Once we make that distinction, the next problem is how to express it.

Humans are very good at carrying implicit context around with them. If I ask somebody to move me up a waitlist, they will normally understand that I have not also authorized them to remove another person from it. If I ask an assistant to pay one particular invoice, I do not expect that instruction to mean that every invoice in the system is now theirs to approve. Software cannot safely rely on the same assumptions.

A broad OAuth scope can tell us that an application may interact with bookings, payments, or customer records, but many business actions require considerably more context: which booking, which payment, which account, which action, which amount, and which resource.

This is one of the reasons Rich Authorization Requests (RAR) are interesting. RFC 9396 extends OAuth with authorization_details, letting clients express fine-grained authorization requirements as structured data rather than through broad scope strings. Those details describe the type of authorization being requested and can include elements such as the actions involved, the resource location, or an identifier for a specific resource, with the exact structure defined for the API and business domain concerned.

Applied to the gym example, "manage bookings" is a broad capability, while an authorization detail identifying a specific class, customer, and permitted action is much closer to an actual mandate. That authorization detail contains boundaries a machine can reason about, because the requested action and the resource to which it applies are represented rather than inferred from a broad permission and whatever the agent decides to do with it. Nothing in such an authorization detail would extend that mandate to somebody else's reservation.

Rich Authorization Requests do not magically provide the authorization model, nor would they fix an API that failed to check whether somebody was allowed to cancel another person's booking. The business still has to decide which actions to allow and under which conditions. What the standard gives us is a way to make richer authority explicit and machine-readable, and that is an important step: an objective expressed in natural language can remain flexible and probabilistic, but the authority granted to pursue that objective does not have to be.

Delegation should not mean inheritance

The same problem becomes more pronounced once an action moves between actors.

Suppose an employee has legitimate access to customer records, billing information, and internal reports, and asks an AI agent to summarize one customer case. The easiest implementation may be to give the agent the employee's permissions, which is also a very efficient way to give the agent far more authority than the task requires.

The employee may need access to hundreds of functions as part of their job. The agent may need to read one customer record for a few minutes. A downstream service may need to retrieve one document, while another component involved in producing the summary may have no reason to modify the underlying information at all. If each participant simply inherits the authority of the one before it, a narrow mandate can become a very broad chain of privilege.

Delegation should work in the opposite direction. The authority passed to another actor should remain tied to the task and should normally become no broader than what the next step requires.

OAuth Token Exchange, defined in RFC 8693, provides a mechanism for doing this across services and security domains. Instead of forwarding the same original credential throughout a process, a token can be exchanged for another that is appropriate for the next service, with authority shaped for that context. The important idea is not simply that another token is issued, but that authority doesn’t have to travel through the entire system unchanged.

The goal is not to make credentials move more easily. It is to make authority move safely.

Who is acting, and on whose behalf?

Delegation also introduces another distinction that identity alone cannot capture: the person or system on whose behalf something happens may not be the actor actually performing the action.

If I ask an AI assistant to perform a task for me, my identity remains relevant because my mandate initiated the process. The assistant also has an identity, because it is the actor carrying out part of that process. If another service continues the task downstream, that service may become another actor, while the original subject remains relevant to the authority behind the request.

Losing either side of that relationship creates problems. Recording only the original user hides which intermediary actually performed the action, while recording only the intermediary loses the connection to the person or process whose authority made the action legitimate in the first place.

OAuth Token Exchange, defined in RFC 8693 gives that distinction a technical representation. In delegation scenarios, the subject remains identified separately while the act claim identifies the actor exercising delegated authority, and nested act claims can represent prior actors when authority passes through a chain of participants. The same standard also distinguishes delegation from impersonation. In delegation, the actor retains its own identity while acting on behalf of another party. In impersonation, the actor effectively assumes the other party's identity within the authority represented by the token.

The gym incident shows why preserving that distinction matters for autonomous systems. The reporting does not tell us how the booking system represented the agent technically. What it does tell us is that the system accepted an action affecting another person's reservation without the necessary authorization boundary. Whether the intermediary was represented separately from the user is therefore less important than the architectural lesson: once software acts on somebody's behalf, the trust model should be able to preserve both who granted the authority and who actually exercised it.

Explicit authority is governable authority

Making authority machine-readable does not mean putting every authorization rule into a token, which would simply move the problem somewhere else. Some information belongs in credentials, some belongs in policy, and some comes from the resource being accessed, the current transaction, or the surrounding business context. What matters is that the organization can describe enough of the authority to understand what has been granted, to whom, for what purpose, over which resources, and under which conditions. Rich Authorization Requests help describe the mandate, and Token Exchange helps preserve the distinction between subject and actor as authority moves, but neither standard decides what an organization's business rules should be, nor should it.

Authorization belongs to the business, not the platform.

An organization still has to decide what canceling a booking means, whether a particular actor may initiate a payment, when human approval is required, or how much authority an agent should receive for a particular task. Here, too, broad roles reach their limits. A finance manager's role may permit payment approval, yet the amount, the state of the transaction, or segregation-of-duties requirements may still determine whether one particular approval should go ahead, just as an agent allowed to manage a gym booking should not gain authority over everybody else's reservations.

A role can contribute to the decision without having to become the entire decision. The more precisely authority is described, the less of it needs to be delegated and the more clearly its limits can be preserved from one actor to the next.

This matters most with agentic systems, because their objectives are intentionally flexible. We want an agent to reason about how to achieve an outcome rather than requiring a human to specify every API call in advance, and that flexibility is precisely why the authority surrounding the agent cannot be equally ambiguous: the objective may leave room for reasoning, but the boundaries of authority need to remain explicit. We cannot assume that an agent will always choose the action we would have chosen. We need a trust architecture that constrains what the agent is authorized to do when it chooses differently.

Trust, in other words, builds up in layers, from identity to mandate to delegated authority, and by the time a process reaches an action that moves money, releases information, or affects another person, the system should understand considerably more than who authenticated at the beginning. Persistent identity provides continuity, while temporary and bounded authority provides control, and making that authority explicit gives the organization something it can govern, delegate, and preserve as systems and infrastructure change.

The next question is what happens when that authority reaches the APIs and systems where actions are actually carried out. That is where the next article begins: Governing Trust Across APIs and AI.