Is It Safe to Let an AI Agent Run Shell Commands?
The question people ask is whether the agent might delete something. The more useful question is what a command it runs can read, and the honest answer in most default setups is almost everything.
Most people weighing whether to let an AI agent run shell commands worry about destruction: a stray rm -rf, a dropped table, a force push. Those are real but recoverable, because you have backups and git. The exposure that is not recoverable is reading. A single command can read your SSH private key, your cloud credentials file and every environment variable in the session, and send the contents to a host of its choosing. No files are harmed, nothing looks wrong afterwards, and the damage is permanent.
So the useful question is not whether the agent is well behaved. It is what the boundary around those commands actually permits, by default, before you configure anything.
What the default boundary actually covers
Claude Code is a good worked example because the boundary is documented in detail rather than implied. Its sandboxed Bash tool documentation describes a boundary the operating system enforces around shell commands, built on the open source sandbox-runtime package. Four facts from that page deserve to be read together.
The sandbox is off by default. The docs state it plainly: "The sandbox is off by default." You turn it on with a command or a settings key. Until then, commands run with your user's full access.
Reads are barely restricted even when it is on. The default read scope is "most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials". Writes are confined to the working directory and a temp directory. Reads are not. That asymmetry is the whole story: the sandbox is built to stop a command wrecking your machine, not to stop it reading your secrets.
Network egress starts closed, which is the part that saves you. Sandboxed commands have "no direct route out", and connections pass through a local proxy that checks each host against an allowed-domain list which "start empty". An empty allow list is what makes the credential read harmless, because reading a key is only half an exfiltration. Add a broad allowed domain and you have re-opened the other half.
Environment variables come along. They are "inherited from Claude Code, including any secrets in its environment". If you export API keys in your shell profile, the agent's commands have them.
What runs outside the sandbox
This is the part that surprises people who turn sandboxing on and consider the job done. By the documentation's own list, the sandbox wraps shell commands only. Outside it: the built-in file and web tools, command hooks, local MCP servers, LSP servers, plugin monitors, and helper commands such as your status line and credential helper, all of which "run with your full access". Commands you type yourself at the shell prompt usually run unsandboxed too, and the agent can ask to retry a failed command outside the sandbox.
So a denyRead rule protecting ~/.ssh stops a cat in a sandboxed shell. It does not stop the file-reading tool, and it does not stop an MCP server you installed last week.
Layer | Inside the default sandbox | Can reach credentials |
|---|---|---|
Shell commands | Yes, once enabled | Yes, reads are allowed |
File read and edit tools | No | Yes, subject to permission rules |
Hooks and helper scripts | No | Yes |
Local MCP servers | No | Yes |
Network egress from shell | Proxied, empty allow list | Only if you allow a domain |
A threat model worth holding
The agent itself is not the adversary in the likely scenarios. The adversary is content the agent reads and then acts on. An issue description, a dependency's README, a web page fetched mid-task, a log line, any of these can carry instructions, and an agent that treats input as instruction will run them. That is prompt injection, and it converts "my agent runs commands" into "the internet runs commands on my machine".
This changes what a safety measure needs to do. Asking the agent to be careful does not help, because the agent believes it is being careful. Only the boundary helps.
The configuration that is actually defensible
Turn the sandbox on. It is a one-line setting and it is the difference between a boundary and none.
Deny reads on credential paths explicitly.
~/.ssh,~/.aws,~/.config/gcloud, password manager directories, and your browser profile. The default read scope includes all of them.Keep the allowed-domain list minimal. Your package registry and your own services. Every added domain is an egress path, and an egress path plus a readable key is the whole attack.
Scrub secrets from the environment. Use a per-project secret file the agent does not need, or the subprocess environment scrubbing the docs describe, rather than exporting keys globally.
Keep destructive commands behind a prompt. Even in the mode that auto-approves sandboxed commands, the docs note that explicit deny rules "are always respected" and that
rmtargeting a critical path still goes through the permission flow. Lean on that rather than replacing it.Audit what you installed. Every MCP server and hook sits outside the sandbox with full access. That is the gap most teams never look at.
For anything untrusted, use a container. The documentation's own advice for putting those outside-the-sandbox components behind one boundary is to run the whole agent process in a container or virtual machine. A dev container for your coding agent is the practical version of this, and it is the right answer when the agent is working on code you did not write.
So should you let an AI agent run shell commands
Letting an agent run shell commands inside a container with no credentials mounted and a narrow egress allow list is a reasonable risk, and it is how most of the productive use happens. Letting one run commands on your daily-driver laptop with your real keys in the environment and the sandbox off is not safe, regardless of which model is driving, because one injected instruction in one fetched page is enough.
The deciding question is the one in reviewing an agent plan before it runs: what can this do that I cannot undo. It sits inside the wider set of exposures in our guide to AI risks for builders, and it is the one where the gap between the perceived boundary and the real one is widest. Deleted files you can restore. A read key you must rotate, and you will not know you needed to. For the specific case of keys in a repo, can an AI coding agent leak your API keys goes further, and environment variables and secrets covers keeping them out of reach in the first place.
Frequently asked questions
Does a sandbox stop an AI agent reading my SSH key?
Not by default. The documented default read scope includes credential files such as ~/.ssh and ~/.aws/credentials. You have to deny those paths yourself.
If reads are allowed, why is a sandbox worth enabling?
Because egress is closed by default. Reading a secret is only dangerous when it can leave, and an empty allowed-domain list is what breaks that chain.
Is approving each command manually safer?
Modestly. People approve long command strings they have not parsed, and approval fatigue sets in within an hour. A narrow boundary outperforms careful reading, because it does not get tired.
Do MCP servers run inside the sandbox?
No. Local MCP servers, hooks, LSP servers and helper scripts run outside it with your full access, which makes auditing what you have installed part of the security posture.
What about Windows?
The documented sandbox runs on macOS, Linux and WSL2, and on native Windows commands run unsandboxed. On a Windows machine, run the agent inside WSL2 or a container.
How did this land?
About the author
Senior Editor, AI & Product
Cecilia leads the Swarmz editorial desk. She has spent a decade turning complex AI and product topics into writing people actually finish, and she owns the blog's quality bar.
