Permissions must be granted by task scope, not all at once

What it is

Which tools an agent may call, which objects it may touch, which world boundaries it may cross, should follow the scope of this task — not a one-time dump of mail, drive, payments and contacts at install or first consent. Scoped permission grants is least privilege in agent form: the one mail this run will send, the one folder it will edit, and the permission stops there.

“Allow access to your Google account,” a one-shot unrelated to the task, is taking the boundary down in advance.

Why it happens

Permission is fuel for action-level automation. After a blanket grant, the task scope moves and the fuel remains. People cannot imagine every later task at the moment of consent, so they swap per-task judgement for “grant it for now.” If the agent’s plan reroutes mid-way, the old grant does not retract itself, and crossing the line becomes cheap. In supervisory control, how far action implementation is automated is permission; a UI that makes permission an install-time switch locks the action stage at the top rung and tells people it is only “connecting an account.”

Per-task grants put the judgement back on each task’s boundary, and divide labour with confirmations: the grant decides “may it touch this class of object,” the confirm decides “does it touch this time.” Without per-task grants, confirmation has to carry the whole boundary and will be clicked through.

Studying it

Hold the same agent, compare a blanket grant with per-task grants (objects and acts listed each time). Mid-task, reroute the plan toward an object outside the grant. Dependent variables: whether the cross happens, whether people notice the grant was too wide, whether the grant dialog was clicked blindly. Independent variables: grant granularity (account / folder / single object), whether grants expire, whether a reroute triggers a new grant.

Separate “clicked allow” from “understood the scope.” A scope read-back is a necessary probe.

Where it stops holding

Read-only, sandboxed agents that cannot cross a world boundary are less harmed by a blanket grant. OS-level capabilities (notifications, local network) are not the same layer as task objects; do not mix them into a per-task grant to scare users, and do not treat them as task scope. Whether a cross is blocked or reported after the fact is the next claim. Audit records are the one after that.

Applying it

• Bind the grant dialog to the task: list object classes and acts for this run, default to expiry or retract at task end. Do not let “connect account” impersonate permission for this task.
• When a plan reroute hits a new object class, run the grant again; do not reuse the old ticket.
• Check: the grant says “read this folder,” then let the agent write another folder. If the write succeeds, scope is not following the task. Then ask a person to recast what they just allowed — if they recast it as “the whole drive,” the dialog is still a blanket.

Related

• Same group: L4.06.2 Out-of-bound acts must be blocked, not reported after the fact · L4.06.3 Records of permission use must be auditable
• Nearby: L4.07 Pre-action Confirmation · L4.14 Plan Visibility and Revision for Multi-step Tasks · L4.01 Levels of Automation
• Search terms: least privilege · scoped OAuth · agent permissions