Automation becomes predictable when permission is part of the interface, not an assumption hidden behind it.
The most consequential control in an automated workflow is often invisible. A system can inspect a record, prepare a change, or carry out the change. Those states may look nearly identical on screen. Operationally, they are different jobs with different authority.
I learned to design that distinction before debating how capable the automation might become. I've been impressed by a capability and skipped too quickly past the permission question. Capability answers whether the system can compose a reply, rotate a credential, change a service, or approve a charge. Authority answers whether it may do so in this account, at this moment, under these conditions.
When those questions are combined, interfaces become dangerous in quiet ways. A button labeled “resolve” might draft a recommendation, update an internal record, or communicate externally. A conversational instruction might be interpreted as a request for analysis or permission to act. Fluency makes the ambiguity feel smaller than it is.
The interface between a person and automation is therefore an authority model. Its controls need to express what can proceed, what must pause, who can approve, and what evidence follows the transition.
Start with action classes
I classify actions by their effect rather than by how difficult they are for the software. Reading a configured account is usually nondestructive. Drafting creates an artifact without committing it externally. Sending to a customer crosses an organizational boundary. Changing production mutates shared state. Handling secrets, billing, or destructive operations carries its own consequence even if the underlying API call is one line long.
That produces a compact map:
| Action class | Authority |
|---|---|
| Inspect configured, nondestructive state | Proceed and record evidence |
| Prepare a draft or proposed change | Proceed; leave uncommitted |
| Send to a customer or external party | Require explicit approval |
| Mutate production state | Require scoped approval |
| Access or expose secrets | Require a gated path |
| Create billing consequences | Require explicit approval |
| Delete or irreversibly alter data | Require explicit, target-specific approval |
| Accept an operating-system permission dialog | Stop for the person at the device |
The map is intentionally about action classes, not a list of favored tools. Vendors change. Interfaces change. The consequence of sending externally or deleting data does not.
Configured-account scope matters too. Permission to inspect one connected environment doesn't imply permission to discover or traverse every account a credential might reach. The system should know which boundary it was given, and the user should be able to see that boundary without reading configuration files.
An audit record names the action class as well as the result. Otherwise a later reviewer can't tell whether “completed” means inspected, drafted, or executed.
Make approval a real transition
Approval can't be a sentence in a prompt or a warning beside an active control. It has to be a state the system enforces.
For a gated action, the automation prepares a proposal containing the target, intended effect, relevant evidence, and a bounded validity period. The workflow enters an awaiting-approval state. The approver can accept that exact proposal, reject it, or request a revision. If the target or material changes, the old approval doesn't float forward to the new action.
This prevents a common category error: treating review of the idea as authorization of the execution. “That approach looks right” isn't automatically permission to run a production mutation. The interface should ask the concrete question at the point where the effect is known.
After approval, the execution record links back to the proposal and approving actor. The result then carries fresh evidence. If the action fails or only partially completes, the system doesn't quietly reinterpret the original approval as permission for unlimited retries. A changed attempt can have changed consequences.
Permission dialogs deserve special treatment because software can't responsibly click through a boundary maintained by the operating system on behalf of the person. The automation can explain what access is being requested and why, then stop. The human interaction is part of the security model, not friction to engineer around.
Design the denied path
Most authority models look polished on the happy path and vague when permission is absent. That's backwards. A denied, expired, or unavailable approval should leave the work legible.
The system can preserve the draft, show why execution did not occur, and identify who could authorize it. It shouldn't degrade into repeated requests, alternate credentials, or a less governed route. If a person rejects a customer send, the draft remains a draft. If nobody approves a production change before its evidence becomes stale, the proposal expires and must be rebuilt against current state.
This is where honest user experience matters. The interface should use verbs that match effects: inspect, draft, propose, approve, send, change, delete. “Continue” hides too much when the next transition carries authority. Confirmation screens should show the actual target and consequence instead of asking whether the user is sure in the abstract.
Autonomy remains valuable inside the permitted area. Nondestructive inspection can proceed, evidence can be assembled, alternatives can be compared, and a precise proposal can wait for a quick decision. The human isn't forced to supervise every intermediate step. The automation is not invited to infer permission from enthusiasm.
When I review one of these workflows, I trace each effect through the action class, authority source, approval transition, execution evidence, and denied path. If one link depends on the model “knowing better” or an operator remembering an unwritten rule, I send it back. I'd rather explain one extra stop than explain an unauthorized send after it has already left the building.