AI agents that run shell commands are genuinely useful: they explore a repo, run the test suite, fix the breakage, and show you a diff. They are also, operationally speaking, a very fast intern with root-adjacent curiosity and no sense of what "production" means. If you let one loose on your daily driver with your SSH keys and cloud credentials in reach, you are one misunderstood prompt away from a very educational afternoon.

The fix isn't to avoid agents. It's to treat them like any untrusted workload: least privilege, containment, and a review gate. Here is the playbook I use.

1. Never let it work on your main checkout

Before the agent runs a single command, isolate the blast radius in version control:

git worktree add ../myproject-agent-run -b agent/experiment

A worktree gives the agent a full, separate working copy on its own branch. Your main checkout stays clean, git status stays honest, and when the experiment goes sideways you delete the directory and the branch. If the agent has no git access at all, at minimum point it at a disposable copy of the project — never the only copy.

2. Plan mode before action mode

Most capable agents offer a read-only or "plan" mode: they explore, propose, and write a plan without executing anything. Always start there. Read the plan like a change request from a colleague you don't fully trust yet. Only switch to execution mode once the plan names the files it will touch and the commands it will run. Surprises in the plan become disasters in the terminal.

3. Run it as someone with nothing to lose

Create a dedicated, unprivileged user for agent sessions — no sudo, no membership in docker or other privileged groups, and a home directory that contains nothing sensitive. An agent running as your everyday user inherits your SSH keys, your browser profiles, your cloud CLI credentials, and your password manager's unlocked state. A dedicated user inherits an empty room.

4. Sandbox the filesystem it can see

Even as an unprivileged user, the agent can read anything your user can read. Contain it:

  • systemd-run with filesystem guards for quick one-off sessions: options like ProtectSystem=strict, ProtectHome=read-only, and TemporaryFileSystem give you a throwaway view of the OS in a single command.
  • firejail or bubblewrap for a persistent sandbox profile around the agent's working directory.
  • Containers when you want full reproducibility: mount only the project worktree into the container, nothing else.

The goal is simple: the agent should see the project directory, its toolchain, and nothing else. If it can't see your ~/.aws, it can't leak your ~/.aws.

5. Keep secrets out of its line of sight

This is the rule people break most often. Don't paste API keys, tokens, or passwords into agent prompts "just this once" — prompts get logged, cached, and sometimes shipped to a model provider. Keep secrets in environment files the agent's sandbox can't read, and prefer test or sandbox credentials for anything the agent needs to exercise. If the agent truly needs a real credential, inject it at runtime through the environment of the sandboxed process, never through the chat box.

6. Review the diff before anything runs or merges

The agent's output is a proposal until you say otherwise. Read the full diff. Run the tests yourself in your own environment. Ask the two questions every code review asks: what does this change? and what else could it affect? Agents are excellent at producing plausible-looking changes that subtly alter behavior — dependency version bumps, "harmless" refactors of auth code, config files rewritten from memory.

Automation with a leash beats automation with regrets. A worktree, a plan-first habit, an unprivileged user, a sandbox, clean secret hygiene, and a human review gate — six cheap habits, and the agent goes from liability to the most productive junior on your team.