An AI system can draft a recovery plan without being authorized to commit a team to it. It can identify a supplier delay without being authorized to send a new delivery promise. These actions may begin with the same information, yet they create different obligations.
Approval becomes useful when it is attached to a specific decision. A general instruction to “keep a human in the loop” leaves important questions unanswered: which human, at what point, seeing what evidence, and with authority over which action?
Begin with one action
Consider a hypothetical engineering program. A supplier changes the expected delivery date for a test package. An assistant reads the update and proposes a revised sequence of work.
There are several possible next steps. The assistant might summarize the change, draft a recovery plan, update an internal planning document, or notify a customer that a milestone has moved. Treating those steps as one permission called “manage the program” hides the decisions that matter.
Write down a single action in concrete terms. “Draft a recovery plan for the program lead” is easier to review than “optimize execution.” It identifies an output, an audience, and a boundary.
Look for a change in consequence
A useful review gate often appears where a recommendation becomes a commitment. In the hypothetical program, these are different permissions:
| Proposed work | A useful boundary to discuss |
|---|---|
| Summarize a supplier update | Read only the approved sources and preserve their timestamps. |
| Draft a recovery plan | Make the proposal visible without changing the agreed schedule. |
| Change an internal commitment | Have the accountable owner review the exact change and recovery path. |
| Send an external delivery promise | Require an explicit decision from the person authorized to make that commitment. |
These are design examples, not universal risk classes. The same operation can carry a different consequence in another organization. A reversible edit to a draft document is different from a change that feeds a release decision.
Make approval specific enough to inspect
The person reviewing a request should be able to see the proposed action, its scope, the relevant evidence, and the expected effect. They should also be able to reject it, ask for more information, or choose a different action.
A useful question is: would this approval still make sense if the supplier date changed again? If the answer is no, the approval needs a boundary around the context as well as the action. A decision made against yesterday’s information should not quietly become permission for today’s different proposal.
OWASP’s guidance on excessive agency recommends limiting the functions and permissions available to AI systems, reviewing consequential actions, and checking authorization outside the model. These are complementary controls; a confirmation button does not replace them. OWASP LLM06 Excessive Agency ↗
Give the system a useful way to stop
“Ask a human” is incomplete when nobody has been assigned to answer. Define the owner, the information they need, and the behavior while the request is waiting. For some work, that means saving a draft and continuing to observe. For other work, it means stopping until the uncertainty is resolved.
Test the inconvenient cases: the approver is unavailable, a source is missing, two records disagree, or the requested action has expanded. A workflow that is understandable only when everything goes well is not yet a complete operating design.
Turn the conversation into a brief
The AI authority canvas is a starting point for that discussion. It maps a proposed role, action, resources, human owner, and renewal condition into a downloadable brief. Its accompanying reference exercise uses synthetic scenarios to make the decision rules inspectable.
The worksheet records an intention. Engineering controls still have to enforce it, and people still have to decide whether the proposed use is appropriate. That is why the most useful first question is small and concrete: what, exactly, is this system allowed to do next?