Least privilege is a decades-old security principle, and it's the single most reliable control you have over AI coding agents. You can't guarantee an agent will never misbehave or be hijacked — but you can guarantee that when it does, the damage is small. That guarantee comes from what you didn't grant.
What least privilege means here
Applied to agents, least privilege is simple: give each run exactly the access its task requires, and deny everything else by default. Most coding tasks need to read a repo and run a build. They do not need your secrets vault, unrestricted network egress, or the ability to deploy. So don't grant those.
Scopes: grant the minimum
Think in explicit scopes. On: read and edit this project, run the build and tests. Off: open network access, read the secrets vault, deploy to production. The default posture is "no," and you turn things on deliberately, per run, when a task genuinely needs them.
The privileges you never grant are the ones you never have to worry about. Default to "no" and earn each "yes."
Sandboxes and worktrees
Isolation is least privilege applied to the filesystem. Each task runs in its own git worktree on its own branch — a separate working directory backed by the same repo — so an agent can only affect its branch. A bad run is discarded by deleting the branch. Containment isn't a hope; it's how the run is structured.
Secrets stay out
The highest-value privilege is access to secrets, so it gets the strictest default: none. Keys live in the OS vault and a per-project secrets vault that's excluded from every prompt. Agents get pointers, never credentials. This single rule defangs most exfiltration scenarios.
Deploys wait for credentials
Production access is the last thing an agent should hold. Gate deploys on explicit credentials supplied for the specific run, with a human approving the promotion. The agents that wrote the code never touch production keys, so there's no path from a compromised run to a compromised deploy.
Security isn't a wall you build around a capable agent — it's the capabilities you decline to hand it.
Which scopes to grant — and which to deny
Least privilege gets concrete when you enumerate scopes. For a typical coding task, grant: read and edit the project repository, and run the build and test commands in a sandbox. That's enough to do almost any change. Deny by default: access to the secrets vault (the agent should get pointers, never credentials), broad outbound network access (limit it to what the build genuinely needs), the ability to touch other projects' files, and any unattended production deploy. When a specific task truly needs more — say, a one-off that must hit an external API — grant that scope deliberately, for that run, and revoke it after. The discipline is simple: every capability is off until a real task forces you to turn it on, which means the dangerous ones are almost never on.
Least privilege vs "just trust the agent"
It's tempting to reason "the model is well-aligned, so broad access is fine." Least privilege is the answer to why that's the wrong frame. The threat isn't only a malicious agent; it's a careless one, a confused one, or a prompt-injected one — and you can't audit the model's behavior the way you'd audit a script. So instead of trying to guarantee good behavior, you constrain the consequences of bad behavior. An agent that holds no secrets, works in a throwaway branch, and can't merge or deploy without you simply doesn't have the reach to cause a serious incident, no matter what it's told to do. Trust is something you extend to the review step you control, not to the autonomous run you don't.
Rolling out least privilege across a team
For a team, least privilege works best as a default baked into the tooling rather than a rule people have to remember. Standardize on isolated git worktrees per task so every run is contained, a per-project secrets vault excluded from prompts so no one pastes a key, a verify gate plus human review before any merge, and deploy credentials supplied explicitly per run rather than held by agents. Document who can grant elevated scopes and for what. The reason to enforce this by architecture is that policies-by-reminder erode under deadline pressure, while a tool that simply doesn't let an agent see the secrets vault or deploy unattended keeps the guardrails on for everyone. Command Fleet ships with exactly those defaults, which makes "least privilege" the path of least resistance instead of an extra step.
A least-privilege checklist for AI agents
Audit your setup against this list — each "yes" shrinks what a misbehaving or hijacked agent can do:
- Repo access only. The agent can read and edit the project it's working on, and nothing else.
- No secrets in scope. Keys live in the OS vault and a per-project secrets vault excluded from prompts; the agent gets pointers, never credentials.
- Network locked down. Outbound access is limited to what the build genuinely needs, not the open internet.
- Isolated runs. Each task runs in its own git worktree on a throwaway branch.
- No unattended deploy. Production access is gated on explicit, per-run credentials and a human approval.
- Review before merge. Nothing reaches main without a verify gate and your sign-off.
Default every capability to "off" and turn each on only when a real task forces you to — that way the dangerous ones are almost never on. Command Fleet ships with these defaults baked in, so least privilege is the path of least resistance rather than an extra configuration step.
Frequently asked questions
What is least privilege for AI agents?
It's granting an agent only the access a task needs and denying everything else by default — read this repo and run the build, yes; broad network, secrets, and unattended deploy, no. The smaller the grant, the smaller the damage if the agent misbehaves or is hijacked.
What permissions should an AI agent have?
Enough to do the task and no more: read and edit the project repo, run the build and tests in a sandbox. Deny access to the secrets vault, broad network egress, and production deploys unless you explicitly grant them for a specific run.
How do worktrees enforce isolation?
Each task runs in its own git worktree on its own branch, a separate working directory backed by the same repo. An agent can only affect its branch, which you can discard — so a bad run is contained and reversible by construction.
Should an agent have deploy access?
Not by default. Deploys should be gated on explicit credentials supplied for the run, with a human approving the promotion. The agents that write code never need to hold production keys.
Least privilege, by default
Command Fleet isolates every run in its own worktree, keeps secrets out of prompts, and gates deploys on credentials. Free for 7 days, no credit card.