Scope Your Agent
Agentic tools don't just suggest code; they read files, run commands, and reach the network. That power is useful, which is exactly why you set limits up front. When an agent eventually does something unexpected, the damage should be local and recoverable.
Four dials to set
Filesystem access
The working directory, not your home folder. Not /etc. Not even the whole repo if the task doesn't need it. Remember: anything readable includes .env and every credential file in scope.
Approval settings
Require confirmation for shell commands, network calls, and writes outside the project. Auto-approve only the categories you've watched behave for a while — and never destructive ones.
Credentials
Don't give the agent your cloud root key. A scoped service account with the minimum permissions for the task — or no credentials at all, with you executing the privileged step yourself.
Network
Allow-list the domains the agent can reach rather than opening the whole internet. Most tasks need a package registry and your repo host, and little else.
The blast-radius question
Before a long or autonomous run, ask: if this agent did the worst plausible thing with its current access, what would I lose? If the answer is “uncommitted work in one directory,” you've scoped well. If the answer involves production data, another project, or credentials, tighten a dial before you start.
- Commit before you unleash. A clean git state means any agent mess is one command from undone.
- Watch phase boundaries. The core workflow's slices are natural checkpoints — review between them rather than letting an agent run for hours.
- Prefer disposable environments. A branch, a container, or a scratch copy makes “undo” trivial.