Agent least privilege

Agent least privilege is the design rule of granting an autonomous agent only the tools, data, credentials, and network reach its current task requires, and no more, so that a mistaken, hijacked, or over-eager agent has less it is able to do wrong in the first place.

How it works

Least privilege scopes four things an agent would otherwise accumulate by default: the tools it can call, the data and filesystem paths it can touch, the credentials it carries, and the network destinations it can reach. The unit of the grant is the task rather than the agent, so a worker dispatched to summarize logs gets read access to the logs and nothing that writes, and a grant made for one job is not inherited by the next. It is enforced at more than one layer, since a permission rule decides whether a tool call clears, a sandbox bounds what the granted call can reach, and a credential proxy keeps raw secrets out of the agent's hands while still delegating authority, so the principle is a property of the design rather than of any single mechanism. The discipline runs against a standing pressure to over-grant, because a broad grant removes friction now and its cost shows up only on the run that misuses it. It pairs with deny-by-default: the safe starting point is an agent that can do nothing, with each capability added deliberately, rather than a capable agent narrowed after the fact. The test of a grant is not whether the task can proceed but whether the task could proceed with less.

Why it matters

Least privilege is the control that shrinks the blast radius before anything goes wrong, because reach the agent never had is reach no failure can use, which is why it sits underneath sandboxing, threat modeling, and the lethal-trifecta defenses rather than beside them. It is also a strong defense against prompt injection, cheapest when grants are scoped from the start rather than retrofitted onto a broadly granted agent, since an agent that was never granted an outbound channel cannot exfiltrate through that denied path even when hijacked, though it can still leak through a permitted output, and the corner of the trifecta you remove by under-granting is one you do not have to guard. The trade-off is real friction: a tightly scoped agent fails on work it could have done with a broader grant, so the rule is not minimum capability but minimum sufficient capability, tuned against what the task genuinely needs. The honest limit is that least privilege bounds what an agent can reach, not what it does inside that reach, so an agent scoped correctly can still take a wrong permitted action, which is why it is one layer of a stack rather than the whole defense. The common failure is privilege creep, where grants accumulate across tasks and nobody removes them, so the agent slowly acquires a standing scope far wider than any single job requires. The principle is classic least privilege; what is agent-specific is the grant surface, an agent's tools, data, credentials, and outbound reach, and the per-task timing, not a new security law.

In practice

An agent that triages incoming support tickets is granted read access to the ticket queue and write access to a drafts folder, and nothing else: no production database, no outbound email, no deploy keys. When a ticket arrives carrying injected text that tries to make the agent email customer records to an external address, the instruction has nowhere to land, because the agent holds neither the customer data nor a send capability, assuming the queue does not itself carry those records and the drafts folder is not a sync-or-send path. The scope did the work that watching the agent could not, since the dangerous action was never in its reach. A broader grant given for convenience could have turned the same injected ticket into an incident.

Practical considerations

Start from deny-by-default and add capabilities deliberately, because narrowing an over-granted agent after the fact tends to miss the grant nobody remembers making. Scope per task and per dispatch rather than per agent, so a subagent sent to do one job carries one job's access and returns it, which keeps a surprised worker bounded to what its dispatch allowed. Treat credentials as the highest-value grant: a proxy that injects secrets the agent never sees is more durable than any rule that asks the agent not to misuse them, though the proxy still grants authority and must itself be narrowly scoped. Audit standing grants on a schedule, since privilege creep is quiet and a scope that was minimal at setup widens as tasks are added. Remember that the four dimensions are separate decisions, so an agent correctly denied write access can still leak through an open network path, and a narrow tool list means little if one granted tool unlocks everything downstream. Test grants by what the agent cannot do, because a least-privilege posture that has never been probed is an assumption, not a control.

Defined by Ready Solutions AI