02 · Delegated authority and the agency envelope
A model's capability describes what it can do under favorable conditions. A deployment commitment concerns what people can depend on under operating conditions. To connect the two, I ask what the system can cause.
For the support service, the work is helping a customer regain access while protecting the account against unauthorized changes. The model, tickets, stored notes, change service, identity records, and worker's console can each affect that outcome. An assessment confined to the learned component covers part of the arrangement. A system assessment follows the paths through which the whole arrangement can affect the customer.
I preserve the distinction developed in AI Vision & Future: the operating boundary states the commitment—entrusted work and authority under acceptance criteria and error limits. The agency envelope describes the delegation and controls implementing it. Changing a review process may preserve the commitment while changing its implementation. Allowing the assistant to take on additional kinds of account changes may change the commitment itself. Agentic develops these terms.
The envelope has six dimensions: action space and permissions; horizon; state; delegation and concurrency; reversibility and containment; and oversight capacity. Their significance comes from how they interact in a particular workflow.
Changing a single recovery address can have a large consequence for the account holder. A narrow interface still needs analysis of what misuse could cause. Giving the assistant more time may let it finish legitimate work or continue acting on an unresolved mistake. Retained notes may spare a customer repeated explanations or preserve a false premise. More concurrent work may improve service while exceeding the team's capacity to review exceptional cases. I would count those benefits alongside the exposure.
Permission, authorization, and justification#
Three questions organize the authority analysis. What can the acting identity execute? Which use has been entrusted for this task? Whose interests and obligations justify that use? I use effective permission, task authorization, and justification for these respective questions.
In the example, the assistant may possess a credential accepted by the change service. That establishes an execution path. The customer's authorization must still concern the particular account and proposed destination. The service's commitments determine why the change should be made and which competing interests must remain protected. A correct credential check can answer its own question while leaving the other two unresolved.
Prompt injection can redirect the use of permissions the assistant already has. The attacker may need no new credential if an available action serves the attacker's objective. I therefore follow both the permission and the information that led the assistant to use it.
The worker's console adds another path. Suppose the automated change service rejects a proposal, but the assistant's explanation persuades a worker to make the same change manually. The rejection remains a successful constraint on the automated endpoint. A claim about preventing the account change across the service must also account for the worker's evidence and authority. Human participation changes the path to consequence and the conditions under which it can be trusted.
State extends the decision#
The current request may contain only part of the information shaping an action. Suppose a prior case note records an address as verified, and a later assistant copies that description into a new proposal. The present decision now depends on how the note was created, what verification actually occurred, and whether that verification remains applicable.
We need to follow the sequence from the earlier write to its later use. A supported record may give the customer exactly the continuity they need; an unsupported one may carry the original error forward. What matters is what the system takes that record to establish and whether the evidence supports it.
In this example, the critical crossing is the later use of a stored request as evidence of authorization; the write alone establishes neither verification of the requester nor consent to the proposed change.
Delegation extends the sequence further. A service can accept a job before it changes the account, and that job may run after the assistant stops. The assistant's action history and the downstream system's state then show different stages of the same process. I ask what can still be stopped or reversed after acceptance, and what evidence shows that an intervention reaches the work or state concerned.
An “assistant with limited permissions” becomes a more useful description when we can name the identities, information, state, and remaining work through which it can affect someone. That makes the commitment inspectable and gives us a way to trace both errors and attacks.