The Envelope: A Working Model of Agent Authority

The preceding discussion separated the agent as an actor from the human authority it may receive, then added the constraints that can travel with a delegation. This chapter connects those ideas into one request-time model: the agent authorization envelope. The model gives readers a practical test for an agent request by asking whether the right human permission, delegation path, and current execution scope meet at the same resource.

Authority is an intersection, not a role copy

An agent does not become authorized merely because a user once authorized it. Three relationships have to line up.

First, the agent must be a known actor. The policy decision must identify which agent is making the request, not just which human began the conversation. That identity is what makes the later session and action record attributable.

Second, there must be an underlying human or organizational permission for the requested resource. The agent cannot create authority from its own reasoning, and a parent agent cannot give away a right that was never present at the root. The delegation chain must lead back to a principal that is permitted to perform the relevant operation.

Third, the agent must be operating inside a compatible current scope. A valid delegation can be limited to a project, tenant, resource collection, time window, or other context. The agent’s active session has to be placed where the request is allowed. If the session has left that scope, or if a time or contextual condition no longer holds, the same identity and the same historical delegation may produce a denial.

The research framework expresses the result as an intersection. One derived set contains agents active in the resource’s scope. Another contains agents reachable through a delegation chain from the humans who hold the underlying permission. An agent receives the lifted permission only when it appears in both sets. This is more restrictive than copying a user role onto an agent because the result can shrink when any one relationship changes.

In practical terms, the intersection is a three-witness test. The first witness is the human permission on the resource. The second is the valid path from that human to the named agent, including any limits on onward delegation. The third is the agent’s live session in a compatible scope, with its time and context guards satisfied. The witnesses answer different questions, so one cannot substitute for another. A session proves where an agent is operating, not that it should access the resource. A delegation proves that authority was transferred, not that the current context remains acceptable. A human permission establishes the root, not the identity of the actor who is making this request.

This distinction is useful when an authorization system spans several domains. A user may have a document permission in one system and repository permission in another, while the same agent coordinates both tasks. The envelope does not assume that a single enterprise role can safely stand in for those different relationships. It asks each domain to expose the permission that matters and then connects the agent to that permission through a bounded path. The result is more work to model, but less ambiguity when a request crosses a system boundary.

The diagram is deliberately small. It does not represent every policy relation in an enterprise.