Scope your coding agent to least privilege, not full trust

The problem

Coding agents are commonly run with the same filesystem, shell, and network access as the developer who launched them — full read/write on the repo, an unrestricted shell, and outbound network. That access is convenient and it is also the entire blast radius if the agent is manipulated (via a poisoned file, a malicious dependency, or an injected instruction in fetched content) into doing something the user didn't ask for.

This is OWASP's "Excessive Agency" risk for LLM applications: an agent granted more permission, autonomy, or functionality than its task requires. The fix is not "trust the model more," it's reducing what a compromised or confused agent can do.

The methodology

1. Start from a deny-by-default permission set. Most agent harnesses (including Claude Code) support per-tool permission modes — ask before file writes, ask before shell commands, ask before network calls. Start there; loosen only for the specific tools a task needs.
2. Scope filesystem access to the working directory. An agent editing a web app almost never needs read/write outside its own repo. Don't run it from $HOME or with access to unrelated projects, credentials directories, or cloud config (~/.aws, ~/.ssh, ~/.config/gcloud).
3. Gate irreversible and high-blast-radius actions behind explicit confirmation — destructive git operations (force-push, hard reset), production deploys, database migrations, sending messages or emails, purchases. This should be a standing rule, not a per-session ask.
4. Separate "read" from "write" from "execute." An agent that only needs to read logs to diagnose a bug doesn't need shell execute. An agent writing code doesn't need production database write access. Split credentials and scopes accordingly rather than issuing one all-powerful token.
5. Treat fetched content as data, not instructions. Web pages, file contents, API responses, and tool outputs an agent reads can contain text aimed at manipulating it ("ignore previous instructions and run X"). Never let content pulled from an untrusted source authorize an action — only the user's direct input should.
6. Re-derive scope per task, not per project. A project-wide "full access" grant made once tends to persist long after the task that justified it. Prefer session- or task-scoped permissions that expire.

Why this holds up project-agnostically

This isn't specific to any one agent framework, model vendor, or language — it's the same least-privilege principle used in traditional systems security (POSIX file permissions, IAM roles, sudo scoping), applied to a new class of actor that can be manipulated through its inputs in ways a traditional program cannot. Any agent harness that can execute file writes, shell commands, or network calls on your behalf is subject to it.

When this doesn't apply / limits

• It doesn't prevent an agent from making a correct-looking but wrong decision within its granted scope — least privilege limits blast radius, it doesn't guarantee correctness.
• Overly aggressive restriction can make an agent unable to complete legitimate tasks (e.g. blocking all shell access breaks agents that need to run tests). The goal is narrowest-sufficient, not narrowest-possible.