A year ago, AI coding tools suggested code. You read it and decided whether to run it.
Now they run it. They install packages, execute tests, call APIs and open pull requests, while reading text from strangers: README files, GitHub issues, web pages. Usually with the same access as the engineer who started them.
What is an agent sandbox?
A boundary around an AI agent that controls what it can read, run and reach.
Inside the boundary, the agent can work freely: edit the project, run the tests, install what it needs. Outside it are the things it should never touch on its own: your SSH keys, your cloud credentials, other repositories, and most of the internet.
What changed
That shift is why agent sandboxes have gone from a niche security topic to something every team running agents needs to understand. A permission prompt on every command doesn’t scale: after the fortieth one, nobody reads them.
What this series covers
Starting Friday, two short parts a week. Each one stands on its own, with three diagrams:
- What an agent can reach without a sandbox, and how one poisoned README leaks your keys
- Why git worktrees aren’t isolation
- Containers, gVisor and microVMs, and what actually separates them
- The network wall, secrets, many agents at once, and a reference architecture to finish
No vendor pitches. Just how it works. If there’s something you want covered, tell us and we’ll fold it in.