Delegation Must Carry Boundaries
This chapter focuses on how authority travels from a human to an AI agent and, when necessary, from that agent to another one. The key question is not whether delegation exists, but whether each delegation carries enough limits to survive recursion, changing context, and expiry. Readers should come away able to distinguish a broad impersonation grant from a bounded, inspectable authorization relationship.
Why a token does not carry the whole chain
A simple delegation can look easy. A user asks an assistant to read a project document, and the system gives the assistant a token that permits the read. The trouble begins when the assistant discovers that the task requires another service or another agent. If the first agent passes along the user’s broad token, the second agent may inherit more authority than the task requires. If it receives a new token, the system must still explain where that authority came from, what was narrowed, and whether the new agent may delegate again.
The problem is not that tokens are useless. OAuth-style tokens can allow an application to act for a user without exposing the user’s credentials, and their scopes can represent a subset of the user’s capabilities. They are valuable for secure transfer of authority and for interoperability. But the research paper argues that static token contents do not by themselves express the full behavior of an agentic system. An agent may delegate recursively, respond to a new context, or generate an action that was not enumerated when the original token was issued.
Nested tokens can represent multiple hops, but they do not automatically answer the questions that make the chain accountable. Which human permission was the root? Was each onward delegation permitted? Did a condition still hold? Was the later agent confined to a narrower resource set? Did the active session belong to the correct project or organization? A collection of credentials may carry pieces of the answer while leaving the relationship between those pieces implicit.
The proposed alternative is to treat delegation as a runtime relationship with terms that can be checked continuously. In ordinary language, a delegation says that one principal authorizes another principal to perform a defined class of work under stated conditions. The terms may include a resource boundary, a time limit, a location or device requirement, a purpose, a limit on further delegation, or a requirement for more than one approver. The point is not to turn every agent action into a legal contract. It is to make the conditions of authority explicit enough for a policy system to evaluate them.
This changes what must persist. A static credential can persist until it expires or is revoked. A runtime delegation also needs the relationship it represents: who delegated, to whom, with what constraints, and whether the delegate may act as a further delegator. The authorization system must preserve enough state to trace a chain, rather than treating the last token presented as the beginning and end of the explanation.
That state is especially important when an agent is not merely a tool invoked by a user but a coordinator of other agents. A planning agent may ask a document agent to retrieve information and a coding agent to prepare a change. The planner should not automatically transfer its entire authority to both. The document agent may need read access, while the coding agent may need repository access under a separate condition. If a later action is challenged, the system should be able to distinguish these paths instead of reporting that “the user’s assistant” did everything.
A recursive chain also changes the meaning of failure. Suppose the original user may view a project document, and the first agent receives that permission for the duration of a session. The first agent may be allowed to ask a second agent to summarize the document, but not to let that second agent edit the project repository. If the second agent requests a repository write, the policy must reject it even if the original user happens to have repository rights elsewhere. The missing link is not the authenticity of the second agent; it is the absence of a delegation path that covers that resource and action.
The same reasoning applies when a sub-agent returns a result to its parent. A result can be useful information without becoming a new grant of authority. The parent may decide to request another action, but that action must be checked against the parent’s own delegation and, if it involves a sub-agent, the new relationship. Treating every message between agents as an implicit transfer would make the communication graph indistinguishable from the authority graph. Explicit delegation keeps those graphs related but not identical.
This is why the framework calls delegation contractual rather than merely transmissive. A token can be passed, but a contract has terms that constrain the recipient and the next transition. The policy engine can then ask whether the requested hop is allowed instead of inferring authority from possession alone.
The forms of delegation that make limits explicit
The framework describes several kinds of delegation because “on behalf of” is too vague to govern by itself.
Full delegation gives the delegate the authority to act without an additional restriction. The paper compares this to classical impersonation. It is easy to understand, but it creates the largest accountability and blast-radius problem because the delegate can appear to carry the delegator’s entire authority.
Scoped delegation narrows the permitted actions, resources, or both. A user might allow an agent to edit proposals but not budgets, or to read one project collection but not the organization’s entire document store. Scope attenuation means that an onward delegation should not widen the envelope it received. The source does not claim that every domain has one universal ordering for scopes; “narrower” must be given meaning by the policy designer and the resource model.
Conditional delegation adds a predicate that must be true when the authority is used. The condition might concern network location, device state, tenant, or another contextual fact. A delegation can be both scoped and conditional. The important property is that the condition is evaluated at the time of use rather than treated as a statement that remains true forever.
Depth-bounded delegation limits how far authority may propagate. A bound of zero forbids onward delegation; a larger bound permits a controlled number of hops. This does not replace the authorization engine’s own termination rules. It adds a governance constraint that says how much transitive authority the delegator is willing to permit. The distinction matters because an agent that may delegate once is not equivalent to an agent that may create an unbounded chain.
Temporal delegation makes validity depend on time. It can express an expiry or a not-before condition. A short-lived grant is not automatically safe, but it reduces the period during which a stale or misdirected authority can be used. The policy still needs to determine what happens at the boundary and which clock or trusted context is used to evaluate it.
Group delegation requires authorization by multiple principals, such as an approval pattern involving several people. This is useful when one person should not be able to give an agent a sensitive power alone. The paper describes such counting as a trusted predicate or schema pattern rather than claiming that the underlying relational algebra has a universal counting operator.
These forms can combine. A coding agent might receive a repository-write delegation that is limited to a test branch, valid only during a work session, and unable to delegate further. A document agent might receive read access within a project scope, while a human approval condition is required before a result is published. The value of the taxonomy is that each limit becomes a property that can be inspected and tested rather than a vague expectation about what the agent will choose to do.
The combinations also expose trade-offs. Full delegation is simple to evaluate but grants the widest authority. Narrow scope reduces the blast radius but requires the domain to define meaningful resource and action boundaries. A time limit reduces stale authority but introduces clock and renewal questions. A depth limit reduces recursive spread but may prevent a workflow from creating a legitimate specialist agent. Group approval adds accountability for sensitive actions but adds coordination and availability requirements. These are not reasons to avoid constraints; they are reasons to make the constraint and its operational cost visible.
A good policy should therefore distinguish the constraint that prevents an action from the one that merely records it. An audit entry saying that an agent was outside the approved project does not enforce the boundary. A scope or context guard evaluated before the tool call can block the request, while the audit entry explains that the guard caused the denial. This difference becomes important when an agent is operating quickly or when a chain changes during execution: the control must be active at the decision point, not reconstructed only after the side effect.
The lifecycle in the diagram has more than a beginning and an end. Issuing authority creates a relationship, but it does not mean every request is active. The agent must authenticate, establish a session, and enter a compatible scope. A later sub-delegation can narrow the work. Expiry, revocation, or a failed context check moves the next request to denial even if the original relationship once existed.
Sessions and scopes make “now” part of the decision
A delegation chain describes how authority was granted. It does not necessarily describe where or when the agent is currently operating. The research model therefore distinguishes a session from a scope. A session is a live instance of an agent acting under a particular delegation. A scope represents an organizational or resource context, such as a tenant, project, collection, or hierarchy of containers. The active session is placed in that scope, and the resource is associated with a compatible scope.
This separation prevents a valid delegation from becoming a roaming capability. An agent may be authorized to read documents for one project while its session is active there, but not to use the same authority against a neighboring project. A session can also disappear while the underlying agent identity remains valid. That is a meaningful state change: the actor still exists, but the execution context that made the request acceptable no longer does.
Hierarchical scopes make inheritance possible without making it unlimited. A resource can belong to a folder, workspace, or organization, and a session may be valid in an ancestor context. The policy must still define which relationships inherit and which do not. A session in one branch of a hierarchy should not become a session in every branch merely because the same agent is recognized globally.
The envelope created by these relationships is best understood as an intersection. The agent must be reachable through a valid delegation chain from a human who holds the relevant underlying permission. At the same time, the agent must have an active session in a scope compatible with the requested resource. If either path is missing, the agent does not receive the permission. This is stricter than adding all of the delegator’s rights to the agent, because the final authority is limited by the narrowest applicable relationship.
The distinction also gives revocation a concrete meaning. Removing a delegation edge can break the chain. Removing a session from a scope can make a resource inaccessible without deleting the agent’s identity. Invalidating a time or context guard can make a request fail even though the original delegation record remains. These are not merely administrative updates to a directory; they are changes to the state used by the next authorization check.
Revocation must also respect the shape of the chain. If a human withdraws the authority given to a parent agent, a child delegation should not remain a back door to the same resource. If only one session leaves a project scope, another valid session may still be allowed to operate elsewhere. If a temporal condition expires, the agent identity can remain active for a later, separately authorized task. These distinctions are the operational reason to represent delegation, sessions, and scopes as separate relationships rather than compressing them into one long-lived credential.
The model also supports a more precise audit question. Instead of asking only whether an agent had access at some vague time, an investigator can ask which delegation path was present, which scope held the session, which guard was evaluated, and which relationship disappeared before a later request. The supplied framework treats this authorization state as observable because agent boundaries change during execution. Observability is not a guarantee that every record is tamper-proof, but it gives policy improvement and forensic analysis a faithful state to inspect.
There are limits to what this model settles. The sources do not provide one general method for translating every natural-language purpose into a scope, or for deciding whether a newly generated action is semantically narrower than an earlier one. They leave scope orderings domain-specific. A document system, a source-control system, and a financial workflow may express “narrower” in different ways. The framework supplies places to represent the constraints and requires them to be checked; it does not remove the policy design work needed to define their meaning.
That boundary is preferable to pretending that a broad token can encode intent perfectly. When the system cannot safely infer whether a proposed action fits the delegated purpose, it may need a human decision, a domain-specific rule, or a narrower workflow. The agent’s distinct identity and the delegation chain make that uncertainty visible. They do not justify silently extending authority to make the task complete.
The practical test is therefore straightforward. Before an agent acts, ask whether the authority has a human root, whether every onward hop is permitted, whether the requested resource and action fit the current scope, and whether time and contextual conditions still hold. A token may help transport the facts. It is the living relationship among those facts that determines whether the agent is authorized now.