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?
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
- Before: AI suggests code. It writes, and a person decides what executes.
- Now: AI runs the code. A sandbox decides what it can read, run and reach.
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.
Series: Agent sandboxes, in diagrams (11 parts, 27 October – 3 December)
- Intro: Why is everyone suddenly putting AI agents in a box? (27 Oct, this post)
- 01: What your AI agent can reach without a sandbox (30 Oct)
- 02: Git worktrees don’t isolate your AI agents (3 Nov)
- 03: How strong is your AI agent’s sandbox? (6 Nov)
- 04: Your laptop already has a sandbox for AI agents (9 Nov)
- 05: How to stop AI agents leaking your data (12 Nov)
- 06: Keep API keys out of your AI agent’s reach (17 Nov)
- 07: Running many AI agents at once, without collisions (20 Nov)
- 08: Throwaway sandboxes: why AI agents should start fresh (24 Nov)
- 09: How cloud sandboxes for AI agents work (30 Nov)
- 10: A reference architecture for sandboxing AI agents (3 Dec)
Originally published on the Kiri Blog.
Top comments (1)
For the “many agents” and “throwaway sandboxes” installments, could you include cancellation and reuse? For example: agent A starts a background process, its task is cancelled, then agent B receives a fresh workspace. Does A retain credentials, an open connection, or access to B's files?
A diagram showing task cancellation → process termination → credential revocation → workspace disposal would make the lifecycle boundary concrete. The acceptance evidence should include what was actually revoked or denied, alongside the intended policy. That seems a useful complement to the initial container/worktree distinction.