The Orchestrator

This layer and the next are the ones most agent surveys still omit, and they are the ones this book cares about most, because they are where the authority model of Chapter 3 meets real infrastructure. The industry collapses at least four distinct things into the word “permissions,” and an orchestrator has to keep them apart. Identity answers who or what is acting. Authorization answers whether that principal may perform an action. Policy — the subject of the next section — expresses the rules used to decide. Enforcement ensures the decision actually constrains the capability. Traditionally all four have belonged to information security: identity and access management is a security discipline, with its own teams, its own vendors, and a decades-old vocabulary of service accounts, scopes, and least privilege.

Agents have strained that vocabulary in a specific way, and the industry’s first response has been to give agents identities of their own. Microsoft Entra issues an agent its own governable identity — a first-class record with a human sponsor accountable for its lifecycle and access, and assignments that expire; Google’s Agent Identity emphasizes per-agent cryptographic identity on the SPIFFE model, and AWS AgentCore provisions workload identities and OAuth credential flows — related solutions, not feature-equivalent ones; Okta’s Agent SSO (generally available August 2026) models agents as first-class identities alongside human ones, using the Cross App Access standard so an enterprise identity provider can govern which agents reach which applications.³²³³ Identity for agents is arriving, in other words, and it looks like identity for services — plus a sponsor, plus expiry.

Why identity matters more here than it used to. Most of what runs in production — a website, a bank’s transaction processor — is relatively static: the same few services, doing the same things over and over, deterministically, year after year. Orchestrated systems are the opposite of static. One might spawn a thousand new processes, each with its own memory and its own access to data, run for an afternoon, and disappear. Cloud platforms already run ephemeral workloads — short-lived pods and jobs churn constantly, and their workload identities can already be portable and short-lived — so process churn by itself is not new. What agents add is delegated, user-associated decision-making and recursive handoffs. Sometimes such a system acts on behalf of a named person, but more often it is just an agent inside a system — and a dedicated agent identity is what makes the connection to an owner (a person, a department, a company, a customer) reliable, with distributed trace IDs, task IDs, user-delegation context, and workload identity also contributing to attribution. That is the first reason identity matters more than it did ten years ago. The second is delegation: these systems learn, reach new data, take independent action, and hand work to other systems, so their identity has to carry who they act for, not just where they run. The questions shift from “what did the service do” to “what is this thing, who is it acting for, what does it have access to, and who granted that?”

The uncomfortable backdrop is that identity has always been an afterthought for working engineers. The evidence is in every cloud-security study: Datadog found 60 percent of AWS users holding access keys older than a year, and 18 percent of EC2 instances overprivileged; Microsoft’s cloud-permissions research found workload identities using less than 5 percent of the permissions granted to them; Netskope found that of Google Cloud service accounts with old user-managed keys, nearly 30 percent were also over-privileged.³⁴ Broad access is always easier to grant than to scope, so broad access is what gets granted. For static systems the bill for that habit arrives slowly. For autonomous systems with side effects, it is a recipe for disaster — and the disasters of the next several years are what will force the new requirements: not just identity for every agent, but deliberately scoped permissions, expiry, and an honest answer to the harder question. “Have it act on behalf of the user” is not a complete model, because these systems are replacing pieces of people’s jobs — the model has to say who sponsors the system, what it may decide alone, what requires a person, and who answers for it when it is wrong.

1.7.1 On-behalf-of tokens and the delegation problem

The harder problem — the one the identity layer is genuinely not designed for — is delegation. An agent acting for a person is not a service acting for itself, and the industry’s answer so far is the on-behalf-of token: OAuth token exchange (RFC 8693 and its successors), in which the agent presents the user’s token and receives a new one carrying subject and actor semantics — the user it acts for, the agent that acts. The authorization server decides the new token’s claims and scope, so the intersection of user, agent, and task authority is a property the deployment enforces, not one the protocol guarantees. Microsoft’s Entra flow, an IETF draft for carrying agent identity through the consent screen, and Google’s federation tooling all build on this pattern, and every serious agentic-authentication design in 2026 starts there.

It is also far more complex than that pattern, for a reason the surveys have started naming. An on-behalf-of token records that a user delegated to an agent. It does not record what the agent did with the delegation, whether the action still matched the user’s intent by the time it executed, or how authority compounded when the agent called a second agent that called a third. An agent is not forwarding a user’s intent the way middleware forwards a request; in the phrasing of one 2026 analysis, it is creating intent, and the auth system has no clean way to capture that. And when a delegation chain crosses vendor boundaries — your agent, calling a platform’s agent, calling a SaaS tool’s API — the authorization chain breaks into pieces owned by different parties, each with its own logs.

1.7.2 Decision authority as a matrix

The deepest gap is the one this book has been circling since Chapter 3: decision authority. Agentic identity has been defined so far in the context of tool use and data access — may this agent touch that resource. But when a highly orchestrated system makes a consequential decision, the responsibility for that decision may not be a single entity. It is a combination: the person who delegated the authority, the agent identity that acted, the tool’s service account that executed, the platform that hosted the run, the policy engine that allowed it. In the products and standards reviewed for this chapter, no single audit object records that full matrix. The token carries the user leg; the policy engine carries the agent-resource leg; the platform carries the execution leg; and the decision itself — who, in combination, had authority for this — lives nowhere. Some system will eventually be designed to identify that matrix, because auditors, regulators, and courts will ask for it. Until then, an orchestrator assembles the record by hand, and identity and access control — the security discipline — turns out to be only part of the answer.

That is also why this layer lands on more of the organization than the security team. If identity and access control were only about safety, they would remain an InfoSec concern. But permission envelopes, delegation chains, and decision authority are also about accountability — who answers for what the system did — and that pulls in owners, sponsors, platform teams, and the new organizational responsibilities that Chapter 11 describes. The vocabulary of information security can describe a locked door. Describing who is responsible for the decision to open it takes more than security policy.

1.7.3 Where identity shows up for an orchestrator

Identity shows up for an orchestrator at every handoff between the systems this chapter surveys, because each handoff is a moment when an agent acts under some identity and the record of that action has to answer who was really acting. The recurring encounters: provisioning — an agent gets an identity (an Entra Agent ID, a service account, a runtime profile), a sponsor, and an expiry, and the orchestrator is often the sponsor — or operates under a separately named sponsor who remains accountable for lifecycle and access; scoping — deciding which of the organization’s resources that identity may reach, which is the permission envelope of Chapter 3 expressed as infrastructure; and investigating — when something goes wrong, joining the agent’s identity to its tool calls, its human delegator, and the decision record, which today means assembling the chain by hand across identity provider, platform, and tool logs. The test of a working identity layer is simple: for any action this system took, can you name the person and the agent jointly responsible for it?