Least Privilege for Agents: Allowlists & Sandboxing
An agent that starts with zero tools and earns only what its job needs has a blast radius limited to exactly what it can do — the entire principle of least privilege, applied to the agent era.
The Default That Costs You Everything
The default configuration for most agent platforms is permissive. Create an agent, point it at a task, and it arrives with broad tool access — filesystem read and write, network access, sometimes shell execution. This is convenient when you are getting started. It is a disaster when something goes wrong.
When a prompt injection payload lands in the agent's context, or when a misconfig causes the agent to write to the wrong path, or when an attacker uses a leaked credential to impersonate the agent — the damage is bounded by what the agent can do. If the agent can do everything, the damage is unbounded.
Least privilege is the principle that addresses this directly: an agent should start with zero access and gain only the tools and permissions its specific job requires. Nothing more. The blast radius of any failure — injection, misconfiguration, compromise — is limited to exactly what the agent was allowed to do.
This is not a new idea. It is one of the oldest principles in security. What is new is that agents make the stakes higher: they run autonomously, they process untrusted input by design, and they operate at a speed and scale that makes manual blast-radius assessment impossible. Least privilege is not optional for a production agent stack. It is the structural control that makes everything else survivable.
The Three-Question Grant Protocol
Before granting any tool to any agent, three questions must be answered:
Does the task require this tool? Not "could the agent use this tool," not "it might be helpful" — does the specific job this agent does require this specific tool? A research agent browsing documentation does not require fs_write. A code-review agent does not require git_push. If the job doesn't require it, the answer is deny.
Is the tool scoped to the minimum necessary resource? Even when a tool is legitimately needed, its scope can be narrowed. An agent that needs filesystem read access for a documentation task needs read access to the docs directory — not to the entire filesystem. An agent that writes code needs write access to its worktree directory — not to the secrets directory or infrastructure config. Scope is a parameter, not a binary.
Is the action reversible? A tool that reads a file, fetches a URL, or queries a database can be retried if something goes wrong. A tool that pushes a commit, deploys a service, sends an email, or deletes a record cannot. Irreversible actions belong behind approval gates: the agent proposes the action, a human or policy engine reviews and approves before execution. This is not a bureaucratic hurdle — it is the difference between a mistake that can be corrected and one that cannot.
Allowlists vs Denylists
Most agent platforms offer two configuration models. Allowlists enumerate the tools an agent may use — everything else is denied. Denylists enumerate what the agent may not use — everything else is permitted.
Least privilege requires allowlists. Here is why the difference matters structurally:
An allowlist starts at zero. Every tool grant requires an explicit decision and justification. When a new tool is added to the platform, existing agents are automatically denied access to it until someone consciously grants it.
A denylist starts at everything. Every restriction requires an explicit block. When a new tool is added to the platform, every existing agent automatically gains access to it unless someone remembers to update every denylist. "Someone remembers" is not a security control.
Allowlists are harder to configure initially — you must enumerate what the agent needs rather than what it should not have. That friction is the feature. The act of enumerating an allowlist forces a clear-eyed assessment of what the job actually requires. Denylists trade that friction for a configuration convenience that silently grows the attack surface every time the platform adds a capability.
For paths and commands, the pattern is inverted: deny-listed paths (secrets directories, infrastructure config, the root filesystem) complement an allowlisted tool set. An agent's tool allowlist says what it can do; its path denylist says where it cannot do it even with those tools.
Sandboxing Layers
Least privilege is not just about which tools an agent has. It is about what those tools can reach. Sandboxing adds environmental constraints that limit the impact of a tool even when legitimately used:
Filesystem scope. An agent's read and write access should be bounded to the directories its job requires. A builder agent working in an isolated worktree should not be able to write to /home/dev/.env or the infrastructure config directory. This is enforced at the filesystem level, not by trusting the agent to make good choices.
Network egress rules. An agent that reads documentation from external sources does not need to make outbound POST requests to arbitrary URLs. A content pipeline agent that writes to a knowledge layer does not need access to internal services. Network egress restrictions break the exfiltration leg of the lethal trifecta described in the indirect injection lesson.
Separate credentials per agent. Each agent role should authenticate with its own credential. This is the single most important sandboxing decision. When all agents share a credential, the blast radius of any one compromise is the blast radius of that credential across the entire system. When agents use separate credentials, a compromised research agent can only authenticate as a research agent — it cannot leverage a builder agent's write access even through indirect means.
Read-only mode for analysis jobs. Any agent whose job is analysis, review, or summarization should operate in a read-only mode: no write tools, no outbound channels, no mutation capability. Analysis requires reading things; it does not require changing them. A read-only agent cannot exfiltrate via push, cannot corrupt data via write, and cannot be weaponized into a lateral movement vector.
The Fleet Pattern
A well-designed agent fleet applies these principles structurally, not as individual agent configurations:
Research agents have web fetch and read access to the knowledge layer. Zero write tools. Zero outbound POST. Their job is to find information; they are not equipped to do anything with it other than store it in the designated knowledge layer.
Builder agents have filesystem read, and write access scoped to an isolated worktree. Git commit within the worktree. Git push is behind an approval gate. No access to secrets directories, infrastructure config, or paths outside the worktree. Their job is to implement changes in a bounded space.
Orchestrators have the broadest grants because they coordinate across agents — but even they have approval gates on irreversible actions (push to main, deploy, spend, delete). The orchestrator proposes; a policy engine or a human disposes.
Analysis agents are strictly read-only. They cannot commit, push, write, or send anything. Their output is a report, surfaced for human review.
When a research agent is compromised through an injection payload, it can at most corrupt the knowledge layer entries it writes to — the blast radius is its write scope. It cannot push a malicious commit. It cannot send an exfiltration request to an attacker's endpoint. It cannot access the builder agent's worktree. That narrow blast radius is the whole point.
Approval Gates for Irreversible Actions
The approval gate pattern deserves specific attention. Most incidents involving agent systems are not about reading the wrong data — they are about agents taking irreversible actions: committing to the wrong branch, deploying an untested change, deleting a record that should not have been deleted, sending a message to the wrong recipient.
The pattern is simple: the agent proposes the irreversible action, stops, and waits. A policy engine checks the proposal against predefined rules (is this within the allowed scope? does this target a protected resource? has this operation been approved for this agent in this context?). If the policy engine approves, the action proceeds. If not, it is blocked and surfaced for human review.
This does not mean every action requires manual human approval — that would make agents useless. It means irreversible actions are gated by a policy that can be expressed, reviewed, and automated. Over time, the policy engine learns what constitutes a routine approval for a given agent role and automates it. Novel actions outside the routine pattern surface for human judgment.
The distinction between "the agent can commit to any branch" and "the agent can commit to a feature branch starting with its own name" is not a large implementation difference. It is a significant security difference. Scope rules in approval gates are what make the fleet trustworthy enough to run autonomously.