The Delegation Problem

In the last episode, I described the autonomy envelope as the boundary around what an autonomous system should be allowed to cause while pursuing a task. That boundary included authority, reach, impact, propagation and persistence.

Propagation deserves more attention because agent systems are quickly becoming multi-agent systems. A user may authorize one agent, but that agent may ask another agent to investigate something, create several subagents to work in parallel, call an external agent over an agent-to-agent protocol, or hand part of the work to a specialized service. What started as one relationship between a person and an agent can become a chain of actors that the person never interacted with directly.

This creates a problem that ordinary permission models were not designed to answer: when an agent delegates work, what authority should move with that work?

Delegation is already becoming normal agent behavior

Consider an incident-response agent that has been asked to help restore a production service after a failed deployment. The agent can read telemetry, inspect deployment history, query recent changes, scale infrastructure and initiate a rollback.

Rather than perform everything itself, it creates three subagents. One analyzes application logs, another compares the failed release with the previous version, and a third investigates infrastructure health. That is a reasonable way to divide the work.

The security problem begins if those subagents inherit the parent agent's tools and credentials. The agent responsible only for reading logs may technically possess the ability to roll back production, while the one comparing code may be able to modify infrastructure. If either encounters compromised content, makes a poor inference or simply interprets its assignment too broadly, the system has created authority that was never necessary for that part of the task.

Nothing in this scenario has to look like a conventional compromise. The original agent may have been properly authorized, the tools legitimate, the credentials valid and the subagents created exactly as designed. The weakness is that authority has moved farther than the work required.

This is becoming a practical question rather than a theoretical one. OpenAI's current agent tooling, for example, supports agents coordinating independent subagents, and its multi-agent documentation describes architectures in which subagents can operate with configured tools and credentials. That is useful from an orchestration standpoint, but it also exposes the underlying security question: operational inheritance and authorized delegation are not necessarily the same thing.

A handoff creates another authorization decision

Delegation is often treated as an implementation detail. The parent agent receives a task, decides another agent is better suited to one part of the work, sends that work elsewhere and waits for the result.

From an orchestration perspective, that is a handoff. From a security perspective, however, a principal that already possesses authority has decided that another principal should now be able to exercise some portion of it.

That should be treated as another authorization decision.

It is not enough to ask whether the parent agent had permission to perform an action. The system also needs to know whether that agent was permitted to delegate the action, to whom the authority could be delegated, what portion could move, how long it should remain valid, and whether the receiving agent could delegate it again.

Human organizations already make this distinction. A database administrator may be authorized to modify a production database, but that does not automatically give the administrator the right to grant the same capability to someone else. Autonomous systems need an equivalent separation between the authority to act and the authority to confer authority.

The child should not simply inherit the parent

The easiest model for multi-agent systems is inheritance. Agent A can access systems X, Y and Z, so when Agent A creates Agent B, the new agent receives the same capabilities and is simply instructed to use only what it needs.

That places too much of the security boundary inside natural-language instruction following.

A safer model is to derive the child's authority from the work being delegated. If the parent can read and modify production infrastructure but asks a subagent only to analyze telemetry, the subagent should receive only the authority needed for that analysis. The fact that the parent possesses broader authority should not determine what the child receives.

Conceptually, delegated authority should be derived from the intersection of four things: the authority still available to the parent, the specific work being delegated, the policy governing the target resource and the current context in which the work is occurring.

In most cases, the resulting authority should be narrower than the parent's authority. This is the basic idea behind authority attenuation: each delegation step constrains the next actor rather than reproducing the privileges of the previous one.

OAuth already contains useful building blocks for this kind of model. RFC 8693 distinguishes delegation from impersonation, allows an actor to remain identifiable while acting for another principal, and can represent a chain of actors. It also allows exchanged tokens to be narrowed for downstream resources. The RFC deliberately leaves much of the trust model and authorization policy to implementations, though, and autonomous systems make those policy questions considerably more important because delegation may occur dynamically and repeatedly during execution.

Permission to act is not permission to delegate

Another distinction becomes important once agents can create other agents.

Suppose a user gives a financial agent authority to review invoices up to $50,000. The agent delegates invoice analysis to another agent, which may be entirely reasonable. It does not follow that the second agent should automatically be able to delegate the same authority to a third agent.

The right to delegate should itself be part of the authority being granted. A system may allow an agent to act but prohibit onward delegation. It may allow only one delegation hop, restrict delegation to agents operated inside the same organization, require particular attestations, or permit delegation for read operations while prohibiting it for write operations.

Without this distinction, a reasonably constrained authorization can develop a much larger trust surface during execution simply because the workflow branches.

This matters even more as agent ecosystems begin to cross organizational boundaries. Google, Microsoft and others are already building identity and authorization models in which the acting agent is visible as a principal rather than remaining an invisible extension of the user. That is an important foundation because it gives us a way to identify which agent received authority. It does not, by itself, answer the harder question of what authority was allowed to move with the delegation.

Delegation can multiply authority without escalating privilege

One of the less obvious risks appears when an agent's authority includes a cumulative limit.

Imagine a parent agent whose autonomy envelope allows it to modify up to 100 customer records while completing a cleanup task. It creates five subagents, and each receives the same permission and the same 100-record limit.

No individual agent appears to violate its boundary. Every authorization check may succeed. Yet the overall system can now modify as many as 600 records.

This is not conventional privilege escalation because none of the agents acquired a permission that was individually broader than the parent's. The system instead duplicated the ability to exercise the same permission.

The same problem appears with financial limits, API consumption, infrastructure changes, outbound communication, data retrieval and other cumulative actions. If each delegated agent receives a fresh budget, multi-agent orchestration can quietly expand the impact that the original authorization was supposed to constrain.

This is why delegation has to remain connected to the original trajectory of work. When an agent creates a subagent, it should not create a new autonomy envelope from scratch. It should carve a sub-envelope from the authority and impact budget already available to the task.

If the original authorization permits 100 account changes, the parent and all descendants collectively should still have 100. If $50,000 of purchasing authority was granted, creating four purchasing agents should not produce $200,000 of effective authority.

Delegation should redistribute authority where necessary, not manufacture more of it.

The budget belongs to the work, not the worker

This is one of the places where autonomous systems begin to differ from access-control models that focus mainly on the principal.

Traditional authorization usually asks what a particular identity can do. Autonomous work increasingly requires another question: what is this course of action still allowed to do?

Some constraints therefore need to follow the work rather than the individual agent performing it. Consider an agent asked to remediate a security issue across an enterprise environment. During the task it may discover systems, create specialist agents, route work to different models and retry failed operations. The identities performing those actions may change several times.

The authorization context should not reset every time the worker changes. The original purpose, remaining impact budget, resource boundaries, expiry, policy state and relevant approval conditions should continue through the delegation chain.

I think this leads to an important way of framing agent authority: an agent receives authority in the context of a larger piece of work, but it does not own that authority independently. When it delegates, it transfers responsibility for part of the work rather than ownership of the original grant.

Recent research is beginning to explore similar ideas. Work on bounded agents and multi-hop authorization is increasingly looking at restricted delegated scope, shared budgets, runtime enforcement and aggregation bounds across multiple agents. That direction matters because it moves the discussion beyond merely identifying agents and toward governing what happens to authority when work moves between them.

Delegation needs more context than a credential can carry by itself

A delegated credential can still carry a great deal of useful information. It may identify the initiating user, the current agent, the preceding actor, the permitted resource, the allowed operation and the credential's expiration.

Even a perfectly valid credential, however, cannot answer every question that matters during an autonomous trajectory. The system may still need to know why the authority was delegated, what task the child is currently performing, how much of the original impact budget has already been consumed elsewhere, whether another branch of the workflow has changed the environment, whether the parent agent's own authority has been restricted, and whether the child is still pursuing the purpose for which the delegation was issued.

Those are runtime questions, which means delegation cannot be solved entirely through better tokens.

Tokens, capabilities and identity claims are important ways to represent authority, but part of the authorization decision still has to remain connected to live state. A delegate may possess cryptographically valid authority and nevertheless no longer be entitled to exercise it.

This is the same underlying problem we have been developing throughout the series. For autonomous systems, it is not enough to prove that authority existed at some earlier point. We need to know whether that authority remains valid for the action being attempted now.

Descendants should remain inside the original authority

There is a useful property I would want from a verifiable delegation system: no descendant should be able to produce an effect that could not legitimately have been produced within the authority of its ancestors and the remaining authority of the task.

That does not mean every child must have technically fewer permissions than its parent. Sometimes a specialist agent may need access to a resource the orchestrating agent never accesses directly.

A travel agent, for example, may delegate payment processing to a specialized payment agent even though the travel agent itself never receives the payment credential. That can still fit the model because the payment authority derives from the user's original authorization to complete the purchase and is intentionally routed to the principal designed to exercise it.

What should not happen is authority appearing solely because an agent decided another agent would be useful.

To distinguish these cases, the control plane needs to understand the relationship among purpose, principal, action and delegation lineage. Identity tells us who is acting. Authority tells us what that actor may do. Lineage tells us where that authority came from. The autonomy envelope tells us how far the overall work may go.

Delegation is the mechanism that has to preserve those relationships when execution branches.

Revocation has to travel down the same path

Delegation also creates a lifecycle problem.

Suppose a user revokes the authority granted to the parent agent while four descendants are still working. Stopping the parent is not sufficient if those descendants continue to possess usable authority that depended on the original grant.

Any descendant whose authority derives from the parent should lose that dependent authority as well. If only one branch has become unsafe, the system may need to revoke that branch while allowing the others to continue.

That implies a live dependency between delegated authority and its source.

Traditional token exchange does not automatically guarantee this behavior. RFC 8693, for example, notes that exchanging a token does not inherently create a continuing linkage between the input and output tokens, and revocation propagation remains implementation-specific. That can be manageable in many conventional service-to-service scenarios, but it becomes more consequential when autonomous agents may continue operating after the original interaction has ended.

Recent standards and research proposals are beginning to explore authority attenuation, delegation chains, provenance and revocation for agent systems. These efforts are still developing, but the direction is significant because identity is increasingly being discussed together with continuing authority rather than as a one-time authentication event.

NIST's current work on software and AI agent identity and authorization is moving in the same general direction, with explicit attention to identification, authorization, auditing, non-repudiation and the security problems introduced by multi-agent systems.

What a delegation should actually contain

If delegation is treated as a real security boundary, the handoff between agents needs more structure than a natural-language instruction such as “Agent B, please handle this.”

The receiving agent should be able to establish where the authority came from, why the work was delegated, which resources and actions are available, what limits remain from the broader task, whether further delegation is permitted, when the authority expires and what revocation relationship connects it to the original grant.

The enforcement point also needs to remain outside the reasoning model.

A parent agent should be able to propose a delegation, but it should not be able to manufacture whatever authority it wants for the child. A policy system should determine what portion of the parent's current authority can legitimately be converted into delegated authority for the requested work. That authority can then be issued to the child, bound to the child's identity and enforced when the child attempts to use it.

This preserves an important separation of responsibility. The model can decide how it wants to accomplish the work, while the control plane decides whether the authority required for that plan may legitimately move to another actor.

That distinction will matter more as agents become better at decomposing tasks on their own. We want them to have freedom to choose useful execution strategies without giving them equal freedom to redefine the security boundary around those strategies.

Where this leaves us

Multi-agent systems are attractive because specialization and parallelism can make agents considerably more capable. A planning agent may coordinate researchers, coding agents, security agents, financial agents and enterprise applications without a human having to orchestrate every transition.

We should expect much more of this, which means the security model cannot assume that the principal initially authorized by the user will remain the principal performing the work.

Authority will move between agents, tools and services. The important question is whether that movement remains visible, constrained and continuously connected to the authorization that made the work legitimate in the first place.

A delegated agent should have its own identity rather than inheriting the parent's. It should receive the portion of authority required for its task rather than automatically receiving everything the parent could do. Its activity should remain part of the original trajectory, its impact should count against the same overall boundaries, and dependent authority should disappear when the authority above it is revoked.

But there is another assumption underneath all of this. We are assuming that the system deciding what work to delegate is not also free to change the controls that determine what it may delegate. If the same autonomous system can choose its next action, select the agent or tool that performs it, and alter the boundaries governing those choices, then even a well-designed delegation model starts to lose meaning.

That is where the next problem begins. Governing autonomy requires some controls to remain outside the autonomous system itself, especially when those controls determine its authority, limits and ability to continue acting.

Episode 6: The Agent Must Not Hold the Keys to Its Own Cage