Run in observation mode.
Grant read-only access to a sandbox and log every call the agent attempts, including the ones that fail. The attempted set is the honest requirement.
Start at nothing.
Add on evidence.
Least privilege for agents is a procedure, not a principle: observe what a task actually needs, grant exactly that, and make the grant expire.
READ THE DEFINITION ↓DERIVE · BOUND · EXPIRE
01 / DEFINITION
The short answer first.What is least privilege for AI agents?
Least privilege for AI agents means granting only the capabilities a specific task requires, for only as long as it runs. For agents the principle carries more weight than in ordinary software, because an agent's actions are chosen at runtime by a model that can be influenced by the content it reads.
In conventional software, excess privilege is dangerous only if an attacker finds a way to use it. An agent will exercise whatever it holds on its own initiative, if a plausible reason appears in its context. The gap between granted and needed capability is therefore not latent risk but available behaviour.
02 / DERIVING THE MINIMUM
A procedure that produces a defensible set.Separate need from convenience.
Many attempts are exploratory. Distinguish calls without which the task cannot complete from calls that merely made it easier.
Grant the narrowest form.
A specific tool rather than a general one; one collection rather than a store; an identifier rather than a query. Narrow the shape, not just the scope.
Attach an expiry.
Every grant carries a lifetime and a renewal that requires current evidence. Without expiry, the set only ever grows.
Step one is the part that makes the exercise empirical rather than argumentative. Asking a team which permissions an agent needs produces a list shaped by convenience and imagination; logging what it actually attempts across a realistic workload produces a shorter and more defensible one, and the difference between the two lists is usually large.
Step three deserves emphasis because it is where most of the reduction is available. Replacing a generic query tool with three purpose-specific calls removes an entire class of unexpected behaviour, since the model can no longer compose a request nobody anticipated.
03 / TIME AND VOLUME
Two bounds that cost almost nothing.| Bound | What it prevents | Typical setting |
|---|---|---|
| Credential lifetime | A compromise that outlives the run | The duration of the task, not the calendar |
| Records per run | A silent bulk read inside a legitimate grant | A small multiple of what a real task touches |
| Actions per run | A loop that repeats a side effect | A hard cap with a boundary event when reached |
| Step limit | Trajectory drift in a long loop | Enough for the task, plus margin, then stop and report |
| Egress destinations | Arbitrary outbound requests | An allowlist; no general-purpose HTTP tool |
Volume bounds have a second benefit beyond containment: they produce a signal. An agent hitting its record cap is either mis-scoped or doing something unexpected, and both are worth knowing. A capability with no bound produces no such event, so the first indication of trouble is the consequence.
04 / WHY IT DECAYS
Three predictable ways the set grows back.The incident grant.
Access widened during an urgent fix and never narrowed afterwards. Expiry by default is the only control that survives this reliably.
The shared agent.
One agent is extended to a second use case and inherits the union of both requirements. Two narrow agents are usually safer than one broad one.
The convenience tool.
A general-purpose capability added to avoid writing three specific ones, trading a week of engineering for a permanent widening.
The review-only default is the strongest form of least privilege available to an AI system, and it is a capability restriction rather than a permission one: the agent proposes, a person confirms. Privilege AI applies the same ceiling to its own supervision work — MKC2 reports and flags and does not act, with 25 of its 45 checks held at report-only authority. The reasoning generalises to agents and is set out in human-in-the-loop AI.
05 / QUESTIONS
Asked when reducing an existing agent's rights.How is least privilege different for agents than for users?
+
A user exercises a fraction of their permissions and does so deliberately. An agent may exercise any permission it holds at any time, on the basis of reasoning influenced by content it has read. Unused privilege is therefore far less benign.
Does least privilege break an agent that needs to explore?
+
It should not, if the grant is scoped by resource rather than by sequence. An agent permitted a whole matter with a volume cap can explore freely within it. What least privilege removes is the ability to explore outside the task's subject.
How do you handle an agent that occasionally needs more?
+
Just-in-time elevation: the agent requests the additional capability, a human or a policy engine grants it for that run, and it lapses. Standing access granted for an occasional need is the most common source of excess privilege.
Is least privilege enough on its own?
+
No. It bounds the damage of a wrong action without preventing wrong actions, and it does nothing about disclosure of data the agent is legitimately allowed to read. It composes with enforcement and egress control. See AI agent access control.
Who should approve a capability increase?
+
The accountable owner of the agent, with evidence from the evaluation record, and with a defined expiry. Approval routed only through engineering tends to optimise for unblocking rather than for bounded risk.
Grant the task,
not the store.
Privilege AI designs permissions and retrieval boundaries that define what a model can access and which actions it can propose.