Permissions and approvals
An agent is only as dangerous as the tools you hand it. Permissions are where you decide that, and the defaults are rarely what you want for long.
The three buckets
Sort every action into one of three groups.
Allowed without asking. Reversible, cheap, and read only. Reading files, listing directories, running the test suite, running a linter. Approving these individually wastes your attention on things that cannot hurt you.
Ask first. Anything that writes, installs, or costs money. Editing files, adding dependencies, calling a paid API, pushing a branch. You want a beat to think here.
Never. Force pushing, deleting branches, touching production credentials, running migrations against a live database. Some harnesses let you deny outright rather than prompt. Use it, because a prompt you see fifty times a day stops being a decision and becomes a reflex.
Approval fatigue is the real risk
The failure mode is not a careless allow list. It is a strict one.
If a harness asks about everything, you stop reading the prompts within an hour. You are then approving destructive commands with the same reflex you approve file reads, which is worse than having allowed the safe ones from the start.
Allow the boring things explicitly, so that a prompt means something when it appears.
Start narrow, widen from experience
Begin with reads allowed and everything else prompting. After a week, look at what you approved without hesitating every single time. Those belong in the allow list. Anything you paused over stays a prompt.
This is the same principle as the "do not" section in a rules file: entries earn their place by happening, not by being imagined in advance.
Scope matters more than the verb
"Can it write files" is the wrong question. "Which files" is the right one.
An agent with write access scoped to your project directory is a normal working setup. The same permission scoped to your home directory is a bad afternoon waiting to happen. Prefer tools that take an explicit path, like the filesystem MCP server, over tools with implicit reach.
Sandboxes change the calculus
If the agent runs in a container with no credentials and no network, you can be far more permissive inside it, because the blast radius ends at the container boundary. See sandboxing and least privilege.
Working directly on your machine with your real credentials is the high risk configuration, and it is also the default. Know which one you are in.
A working default
Allow reads, tests, linting, and type checking. Prompt on writes, installs, and git operations. Deny force push, credential files, and anything touching production. Adjust from there based on what actually annoys you.