When you give an agent a shell, you give it your permissions. The commands run as your user, in your home directory, with your network. Nothing in that setup knows the difference between a command you meant and one a web page talked the agent into running.

Consider what is within reach of a plain shell session. Your SSH keys and cloud credentials sit in dotfiles under your home directory. Environment variables carry API tokens. Every other project on the disk is readable and most are writable. And the network is open, so anything the agent can read it can also send to any address. Read access to secrets plus an outbound connection is the whole exfiltration path. No exploit is needed, only one bad instruction slipped into a file, an issue or a search result the agent reads.

Approval prompts are the usual answer, and they help less than they seem to. After the fiftieth "run this command?" the reader approves by reflex. A prompt also asks the human to judge a command in isolation, which is hard when the harm comes from where its output goes.

The smallest fix is to shrink the world the shell sees, so the prompts matter less. Three limits do most of the work:

First, a filesystem view that contains only the project directory, with everything else absent rather than merely forbidden. Second, an environment with no inherited secrets: pass in only the variables the task needs. Third, a network that is closed by default, with a short allowlist such as your package mirror. A container or a lightweight OS-level sandbox can give you all three without a full virtual machine.

Notice what this does not do. The agent can still wreck the project directory, so keep that under version control. It can still misuse any token you chose to hand it, so give it a narrow one. The sandbox does not make the agent trustworthy. It caps the damage when it is wrong or misled.

The takeaway: ask what the shell can reach, not what the agent intends. Whatever it can reach, assume an attacker who writes text the agent will read can reach too.

Pick any agent or tool you use that can run shell commands, or imagine one on your own laptop. On paper, answer four questions: which keys and credentials could it read, which tokens sit in its environment, which other projects could it open, and which addresses could it send data to. Any "yes" is reachable by whoever writes text the agent reads. If you build, open the terminal the agent uses and run env and ls ~/.ssh to see what it would see. Then name one thing you would remove from that view.