An AI agent can finish a task while the permission granted for that task remains available. The work stops. The credential may not.
That creates an awkward definition of done. A successful output says something about the job that just ran. It says much less about what the same process, a later run or somebody holding the credential could still do afterwards.
For a tool-using agent, I'd include the end of authority in the task design. The task needs an allowed outcome and a way to tell when the permission no longer belongs to it. That is an engineering requirement for the surrounding system, not something a better final paragraph can prove.
Start with the action, not the job title
“Research assistant” is a useful description for a person reading the workflow. It is a poor access rule. Research can mean reading a public page, retrieving an internal document or changing a record to correct an error. Those actions have different consequences.
Take a simple example: an agent prepares a customer reply. It may need to read one conversation and create a draft. Sending that draft is another action. Granting mailbox-wide send permission because both steps happen in the same application turns a small assignment into a standing capability.
I'd describe the resource and the operation together. Which conversation can it read? Where can it save the draft? What action requires a separate decision? The tool interface has to enforce that distinction when the call is made. A promise in the prompt doesn't remove an operation from an API key.
Identity is necessary, but the task still needs a boundary
NIST's discussion of agent identity highlights credential sharing, long-lived credentials and broad access as recurring risks. It also notes that moving to a modern authorization protocol does not automatically make access sufficiently narrow. This is guidance about a developing field, not a certification of any particular agent product.
My practical test is whether the system can explain a specific action without reconstructing an entire chat. It should be possible to identify the acting service and connect its action to the task that allowed it. A recognizable account name is only the beginning of that explanation.
For the draft example, the permission might be limited to the selected conversation and the draft destination. If the agent encounters another conversation that appears relevant, the original grant should not quietly expand to include it. The new need is a new authorization question.
Give the permission an ending
Expiry is useful, but time alone doesn't describe the task. A credential valid for another hour may outlive a job that ended ten minutes ago. An interrupted job may need to remain stopped even though its original deadline has not arrived.
I'd define the ending conditions alongside the permitted actions. Completion, cancellation and loss of task ownership are situations the surrounding system should handle deliberately. The implementation depends on the service. Some systems support scoped tokens and revocation; others provide coarser controls. Record that difference instead of promising a boundary the service cannot enforce.
There is also an in-flight question. A call already accepted by a remote service may finish after the local worker stops. Cancelling the worker doesn't prove the remote effect was cancelled. The task needs a way to reconcile what the service actually did before anybody retries it.
Test a denied action as carefully as a successful one
NIST's work on tool use in agent systems discusses both access control and the difficulty of observing tool-enabled actions. That leaves a practical obligation for the builder: measure the boundary as well as the successful path.
I'd use synthetic resources and an authorized test environment. Prove that the permitted draft can be created, then attempt an action outside the grant. Try the original permission after the task has ended. Record what the tool accepted or rejected and whether any external effect occurred.
A tidy refusal in the agent's chat is useful feedback. The decisive evidence comes from the tool or service that would have performed the action. If the wrapper rejects an operation before it reaches the service, record that as the wrapper's behavior. Don't describe it as a downstream control you never exercised.
Keep the result and the remaining authority together
A useful completion record should let the next operator answer two questions: what happened, and what can still happen under this assignment?
For a read-and-draft task, that includes the actual draft destination and the state of its access grant. If a cleanup step failed, retain that fact beside the successful output. Another person should not have to discover the leftover permission while investigating a different incident.
These are design proposals for a workflow, not a claim that Black Ice Labs has completed or certified every control described here. The details still depend on the provider and the operation being delegated.
Before expanding an agent's tool access, I'd take one task through its full lifecycle. Prove the useful action, the denied action and the end of the grant. A task is easier to delegate when its authority has an ending someone can verify.