Approval UX should communicate blast radius, not ask for generic consent

Approval UX should communicate blast radius, not ask for generic consent. “Allow this action?” transfers a decision to the user while withholding the facts needed to make it. For an agent, meaningful consent requires a concrete account of what will change, where it will change, how far the authority reaches, how long it lasts, and whether the result can be undone.

Platform permission systems already show the shape of the problem. Windows separated ordinary and elevated authority, Android moved dangerous permissions to the moment of use, iOS required purpose strings, and browser extensions distinguished declared permissions from optional runtime grants. Their shared lesson is not that every sensitive action needs a dialog. It is that permission mechanism and permission experience form one security control. Repeated, context-free prompts teach users to approve mechanically, leaving the boundary visible but functionally absent.

I would make blast radius the primary object in an agent approval. Name the target resources: these three files, this repository, this customer account, this recipient list. Name the action class: read, draft, write, execute, publish, delete. Name the maximum effect: one message, one deployment, all records matching this filter. Name reversibility: previewable, undoable, compensatable, or irreversible. Name lifetime: this step, this task, this session, or standing access. A user can reason about that bundle. “Use the email tool” is not a bundle — it is ambient authority disguised as a button.

The request should appear at the point of intent, not at startup. A person who has just asked an agent to publish a draft understands why publication authority is relevant. The same request during onboarding feels arbitrary and encourages blanket acceptance. Mid-workflow escalation must preserve the plan and state so denial is not punished with lost work. If users learn that saying no destroys progress, the interface is coercive even when the button labels are polite.

Risk should also determine interaction cost. Read-only access to a scoped directory may be auto-approved inside an established boundary. A reversible local write can show a diff and offer task-scoped authority. External publication, credential use, or destructive change deserves a stronger interruption and explicit confirmation. Sandboxing makes this UX simpler: when the runtime can prove that an operation cannot reach beyond a narrow namespace or egress policy, the interface can truthfully show a smaller blast radius and ask less often.

Reversal belongs in the same design. Users need to inspect active grants, shorten or revoke them, and understand what happens to work already in flight. One-time and task-scoped permissions should expire without cleanup rituals. Persistent authority should be the exceptional choice, labeled with its continuing consequences. The interface should make over-granting and under-granting recoverable because both happen under time pressure.

There is one precise concession: expert operators working in a tightly controlled, disposable environment may rationally choose a coarse approval mode because the sandbox, version control, and isolated credentials already cap the worst case. Even there, the product should show the boundary that makes coarse consent safe. The absence of repeated dialogs is justified by containment, not by pretending the action has no risk.

The useful approval question is therefore not “Do you trust the agent?” Trust is too broad and too sticky. The useful question is “Do you authorize this bounded effect under these conditions?” When scope, reversibility, lifetime, and destination are legible, approval becomes an informed control instead of ceremonial friction — and the user can reserve attention for the decisions whose blast radius actually deserves it.