02 · Delegated authority and the agency envelope
A model's capability describes what it can do under favorable conditions. A deployment commitment concerns dependable performance under the conditions in which people will rely on it. Connecting the two requires an account of what the system can cause.
For the support service, the entrusted work is helping a customer regain access while protecting the account against unauthorized changes. The implementation includes the model, ticket contents, stored notes, the change service, identity records, and the support worker's console. Each can affect the outcome. An assessment confined to the learned component covers part of this arrangement. A system assessment follows the consequential paths through it.
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.
A permission to change one recovery address may have a large consequence for the account holder. Restricting the assistant to that field narrows its interface, but the loss associated with a misuse of that field still requires analysis. Extending the assistant's operating time may let it finish legitimate recovery work or continue acting on an unresolved mistake. Retaining notes may spare a customer repeated explanations or preserve a false premise. More concurrent work may improve service while exceeding the available capacity to review exceptional cases. I assess 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.
This distinction explains a consequential feature of prompt injection: manipulated content can redirect the use of existing permissions. The attacker may need no new credential if the assistant already has an action available that serves the attacker's objective. The analysis therefore follows both the permission and the information used to select its exercise.
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.
The relevant unit is the sequence from an earlier write to later use. Reusing the assertion makes the new decision depend on whether the earlier record was supported. A well-supported record may supply exactly the continuity the customer needs; an unsupported one may preserve the original error. The question is which property the system attributes to stored content and what supports that attribution.
Delegation extends the sequence further. A service can accept a job before it changes the account; the job may execute after the assistant stops. An assistant's action history and the downstream system's state then describe different stages of the same process. I ask what can still be stopped or reversed after a job is accepted, and what evidence shows the intervention reaches the work or state concerned.
These distinctions turn a broad description such as “an assistant with limited permissions” into an inspectable commitment. They identify the identities, information, state, and remaining work through which the assistant can affect a person. That is the basis for tracing both errors and attacks.